[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH] string, wchar: avoid some namespace pollution
From: |
Bruno Haible |
Subject: |
Re: [PATCH] string, wchar: avoid some namespace pollution |
Date: |
Wed, 08 Sep 2021 17:14:24 +0200 |
Hi Paul,
> * lib/string.in.h, lib/wchar.in.h:
> (free): Declare by hand instead of including stdlib.h.
This does not look right to me. There are two cases:
(A) REPLACE_FREE is 0. Then it is OK to declare it by hand, because gnulib
uses the system's free() function.
(B) REPLACE_FREE is 1. (This is the case on most non-glibc systems.)
Then gnulib's <stdlib.h> overrides 'free', by doing
#define free rpl_free
This means that the system's free() function is no longer visible after
some user code does '#include <stdlib.h>'.
If the user code now does
#include <string.h>
#include <stdlib.h>
then Gnulib's <string.h> will have declared that the result of strdup()
(or rpl_strdup()) must be deallocated through the system's free()
function. But the user cannot access this function any more. So he will
get a GCC (≥ 11) warning always!
This would be avoided if the user code does the includes in the opposite
order:
#include <stdlib.h>
#include <string.h>
because then, strdup() gets associated with 'rpl_free', not the system's
'free'. But the user is free to arrange their #includes in the order
they want (except for <config.h> which must always come first).
> This avoids some namespace pollution.
Yes, avoiding namespace pollution is desirable. But so far I don't see how
to make it coexist with correct rpl_free handling.
Bruno