Re: update after gnulib changed

[Bruno Haible]

Paul Eggert wrote:
> > This patch is needed to avoid a compilation error due to today's change
> > in gnulib's 'dfa' module.
> 
> Thanks, I installed that, but isn't it incomplete? With it, 'grep' mixes 
> wchar_t with char32_t

Yes, sure it is incomplete. Before it is complete,
  1. The gnulib 'regex' module needs to make use of 'char32_t'.
     I plan to do this, but 'fnmatch' needs to come first.
  2. grep needs to pull that in.
  3. Other uses of 'wchar_t' in grep need to be revisited.
  4. Finally, the module 'uchar-c23' should be added to grep's imports,
     because (as far as I understand) parts of localeinfo.c depend on it.

The point of my mail was only a heads-up, so that users of the git checkout,
as well as the continuous integration, don't see compilation errors.

> Or does Gnulib replace wchar_t too on these platforms?

No, there's no way to do this, as wchar_t is used by plenty of APIs.
Overriding wint_t on some non-Windows platforms was already hairy enough.

> Come to think of it, is there any need for that instance of "L'_'" in 
> src/searchutils.c, or can we replace it with plain "'_'"? It's comparing 
> a wint_t to L'_'

For most graphic ASCII characters, including '_', x and Lx have the
same numeric value. POSIX guarantees this:
  
https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/basedefs/V1_chap06.html
section 6.3 says
  "The wide-character value for each member of the portable character set
   shall equal its value when used as the lone character in an integer
   character constant."

One reason for writing L'_' is probably portability to EBCDIC systems;
this is outside of gnulib's scope, as gnulib's z/OS port lives in an
ASCII-based subsystem.

Bruno