Re: [PATCH 0/3] Use gnulib c-ctype module, not <ctype.h>

[Simon Marchi <simark@simark.ca>]

On 8/7/25 4:39 PM, Tom Tromey wrote:
>>>>>> "Simon" == Simon Marchi <simark@simark.ca> writes:
> 
> Simon> My understanding is that poisoning using macros doesn't work, because it
> Simon> interferes with identifiers of the same name in other headers.  But
> Simon> would it be possible to do it using "#pragma GCC poison"?  Like:
> 
> I didn't try it but that's because I believe it won't work.
> 
> The pragma is better than the preprocessor approach, the manual says:
> 
>      If a poisoned identifier appears as part of the expansion of a
>      macro which was defined before the identifier was poisoned, it will
>      _not_ cause an error.  This lets you poison an identifier without
>      worrying about system headers defining macros that use it.
> 
> However in our case the poisoning would likely occur before the
> inclusion of the offending header.  The workaround would be to include
> the locale (and maybe iostream?) headers everywhere, but I think we
> definitely should not do that.
> 
> FTR the failure I saw (with cpp-style poisoning, a la safe-ctype.h) came
> from source-cache.c which includes some locale stuff via <sstream>.

Indeed, it doesn't work:

  CXX      agent.o
In file included from ../gnulib/import/ctype.h:35,
                 from /usr/include/c++/15.2.1/cctype:47,
                 from /usr/include/c++/15.2.1/bits/localefwd.h:44,
                 from /usr/include/c++/15.2.1/string:47,
                 from /home/smarchi/src/binutils-gdb/gdbsupport/ptid.h:36,
                 from /home/smarchi/src/binutils-gdb/gdbsupport/common-defs.h:214,
                 from <command-line>:
/usr/include/ctype.h:108:12: error: attempt to use poisoned ‘isalnum’
  108 | __exctype (isalnum);
      |            ^
/home/smarchi/src/binutils-gdb/gdbsupport/common-defs.h:208:20: note: poisoned here
  208 | #pragma GCC poison isalnum
      |                    ^~~~~~~

> The main issue here is that the pragma works on an identifier basis but
> really we'd like to be more selective and only exclude some particular
> functions.

As far as I'm concerned, this patch series LGTM, I'm not aware of better
alternatives.

Approved-By: Simon Marchi <simon.marchi@efficios.com>

Simon