Paul Eggert wrote: > > (a) ptr is unchanged. > > (b) ptr is set to NULL. > > (c) ptr is set to a non-NULL pointer that is not free()able. > > (d) ptr is set to a non-NULL pointer that is freshly allocated > > and thus meant to be freed. > > > > It is quite obvious that no reasonable implementation will do (c) nor > > (d). > > (c) because that would be an invitation for doing free(invalid_pointer). > > Actually (c) might be better, as that would be more likely to catch bugs > in programs. That is, asprintf could set ptr to ((void *) 42) so that > the resulting mistaken 'free' traps.
In the cited code, the free() was done through a _cleanup_free_ attribute. This is an instance of the "resource allocation is initialization" pattern, which comes from C++ but is also a good pattern in C (when the only considered compilers are gcc and clang). Behaviour (c) causes trouble when this pattern is used. (a) and (b) don't. I don't think it is useful to cause trouble when otherwise good coding patterns are used. > > As usual, we can have a *-gnu variant of the modules. The question is > > whether such a change in behaviour is worth all the implementation effort. > > I'm not quite following this. We already have vasprintf-gnu, and since > the glibc behavior is changing to set ptr to NULL it shouldn't be much > implementation effort to add that to the vasprintf-gnu module. Similarly > for Gnulib's own modules like c-vaszprintf-gnu. What am I missing here? We happen to have such a *-gnu module, yes, because of the %B directive. I was speaking in a more general context, considering all the other functions that take an [out] pointer as argument and that may fail. Bruno
