[PATCH libgpg-error] build: Be more consistent with memory management.
ericonr at disroot.org
Tue Apr 27 21:09:13 CEST 2021
Em 27/04/2021 15:34, Werner Koch escreveu:
> On Tue, 27 Apr 2021 12:02, Érico Nogueira said:
>> * src/mkheader.c: remove xfree wrapper (free(NULL) is well-defined),
> It is weel defined but there SunOS bails out on it. Further on Windows
> you need to use a matching free from the same CRT; in particular for
> inter-DLL use malloc and free. Thuis having a warpper is a good idea.
There were some free() calls in the code already. In that case, wouldn't
it be best to use a consistent function here (even if xfree())? Someone
testing only on modern *nix could miss the need to use xfree() in a
>> use xmalloc instead of malloc+check return value, use macros to block
>> malloc and strdup from being used in the program.
> Nope. xmalloc is a shortcut to make things easier for short living
> programs; replacing existing code by its inferior variant is a Bad
This is a build tool that doesn't really have much to do except fail
with an error if it can't allocate enough memory. Furthermore, the error
message + exit(1) or return 1; (in main()) code is needlessly duplicated
in the two spots where malloc() is used. Any further addition to the
tool would then have to either remember to use xmalloc() or copy the
error handling again. Blocking malloc() from being used means the
programmer (and reviewers) won't have to worry about remembering all the
rules. I agree that xmalloc doesn't fit in a library, but it definitely
fits in a build tool.
> If you have a need for changes in libgpg-error, it is best to
> communicate your reasons and not just to toss some patches.
I'm not tossing some patches, I just found a place to slightly improve
code terseness and overall consistency while I investigated a build
failure (for which I sent another patch).
More information about the Gnupg-devel