[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: XMALLOC() et al
From: |
Bruno Haible |
Subject: |
Re: XMALLOC() et al |
Date: |
Sat, 20 Jul 2024 12:27:07 +0200 |
Paul Eggert wrote:
> > GNU gettext uses the XMALLOC macro in more than 100 places. It's
> > just so convenient to do a memory allocation in 1 line of code:
>
> I find it more convenient to write this:
>
> context = xmalloc (sizeof *context);
>
> than this (taken from GNU gettext):
>
> context = XMALLOC (markup_parse_context_ty);
This is where our opionions differ. The first style has three drawbacks:
* In order to understand what the statement really does, the reader
has to look up the definition of 'context', to see its type.
* Typically, right after allocating an object, comes the initialization
of its members. To make it easy for the reader to verify that this
initialization is complete, he needs to look up the definition of the
type quickly. Again, this is harder if the type is not stated explicitly.
* When there is a copy-and-paste mistake, the first style does not warn,
but the second style does. For example, suppose we have types
fun_context, var_context, tag_context and associated local variables, then
fcontext = xmalloc (sizeof *fcontext);
vcontext = xmalloc (sizeof *vcontext);
tcontext = xmalloc (sizeof *vcontext);
will not warn, whereas
fcontext = XMALLOC (fun_context);
vcontext = XMALLOC (var_context);
tcontext = XMALLOC (var_context);
will warn.
Which is why I encourage the use of XMALLOC.
Bruno
- Re: [PATCH v1] xstrtol: 1 is not a valid base, (continued)
- Re: [PATCH v1] xstrtol: 1 is not a valid base, Bruno Haible, 2024/07/18
- Re: [PATCH v1] xstrtol: 1 is not a valid base, Alejandro Colomar, 2024/07/18
- Re: [PATCH v1] xstrtol: 1 is not a valid base, Bruno Haible, 2024/07/19
- XMALLOC() et al (was: [PATCH v1] xstrtol: 1 is not a valid base), Alejandro Colomar, 2024/07/19
- Re: XMALLOC() et al, Paul Eggert, 2024/07/19
- Re: XMALLOC() et al, Bruno Haible, 2024/07/19
- Re: XMALLOC() et al, Paul Eggert, 2024/07/20
- Re: XMALLOC() et al,
Bruno Haible <=
- Re: XMALLOC() et al, Paul Eggert, 2024/07/20