bug-gnulib
[Top][All Lists]
Advanced

[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






reply via email to

[Prev in Thread] Current Thread [Next in Thread]