Add g_memdup_n; un-deprecate g_memdup() with constant second argument
I am going through g_memdup uses and finding that the situation could have been handled better. And "better" here means asking less of glib users.
TLDR: want g_memdup3 and, perhaps, special-case macro g_memdup.
Most of my uses (say 75%) are of the form
return g_memdup (something, sizeof (struct_type));
These are copy methods for boxed types, mostly. This kind of g_memdup use was never a problem, so why do I have to change code? It should be possible to make a macro version of g_memdup that works for compile-time constant second argument.
Most of the rest of my uses of g_memdup look like
g_memdup (something, count * sizeof (some_type))
Depending on what "count" is, this may or may not be problematic. The advice seems to be to go through these, add error checks as needed and call g_memdup2 instead.
That is an error-prone process that glib should not offload onto users. I think it would be highly optimistic to assume that the number of bugs will actually go down during that process. In fact, by the time it hits StackOverflow the advice will probably just have become "use g_memdup2 instead".
Instead I suggest that g_memdup3 be introduced such that
g_memdup3 (something, count, sizeof (some_type))
can be used. This is a much simpler edit and glib can then do the necessary overflow check in one place instead of having $N developers edit $M places and getting it wrong a non-trivial fraction of the time.
I have a very few g_memdup uses not of either of the above kind. Obviously actual attention will be needed there.