That's disgusting. If it's important to know where it failed, that's
why you call the regular funciton, check the error and say something
intelligent. Then it's easy to look at the code and know it's doing
the right thing, rather than having to wade through some macro and
gccisms. bleah.
I'd far rather see it in the code, doing it right.
On Sun, Dec 16, 2012 at 5:43 PM, Martin Pelikan
<martin.peli...@gmail.com> wrote:
> On Sun, Dec 16, 2012 at 01:01:49PM -0700, Theo de Raadt wrote:
>> > know exactly where the memory allocation fails since the error messages
>>
>> I hate xstrdup() and xcalloc() for exactly that reason. You don't
>> know why it failed.
>
> Actually, you can make them macros using all that underscore gcc magic,
> like so:
>
> #define XMALLOC(where, howmany) do { \
> if (((where) = malloc(howmany)) == NULL) { \
> err(1, "%s: malloc %zu (%s:%d)\n", __FUNCTION__, \
> howmany, __FILE__, __LINE__); \
> } } while (0)
>
> Your error messages are exact, .data should be kept small (only one copy
> of the string + one string per each function + line numbers in .text),
> only thing worrying me is that it doesn't really look pretty in the code.
>
> If you wanted the value of 'howmany' in your error message, you should use
> %zu as malloc(3) eats size_t, but regular constants will be of type int
> and produce warnings. Playing with __builtin_constant() will get _really_
> ugly, though :-(
>
> Or, if you want to play user-friendly, you can pass a string to that
> macro, describing what is the software actually trying to do, in English.
> --
> Martin Pelikan
