> Date: Thu, 5 Sep 2024 11:49:19 -0700 > Cc: emacs-de...@gnu.org, luang...@yahoo.com > From: Paul Eggert <egg...@cs.ucla.edu> > > On 2024-09-05 11:02, Eli Zaretskii wrote: > > > I'm talking about what's in the sig2str.h header. The above URL says > > nothing about it. Why cannot Gnulib arrange for that header to > > declare these functions and that macro, if signal.h didn't? > > Because then callers might easily make the mistake of thinking that they > should include <sig2str.h> to declare sig2str. Callers shouldn't do > that. They are supposed to include <signal.h> to declare sig2str. > sig2str.h is for something else: it's for defining SIGNUM_BOUND, and it > includes signal.h only to be backwards-compatible with older Gnulib > versions.
Then document this and be done. I don't see how is this a big problem. > >> Instead, how about adjusting Emacs's MinGW shims to supply the missing > >> declarations? Something like the attached patch, say. (I don't use MinGW > >> so can't easily test this.) > > > > This might solve the Emacs problem (and is not very clean even in that > > case), but will not help other projects that use Gnulib. > > That's not something we need to worry about. That is strange to hear, since Gnulib is supposed to care about all GNU projects, not just about Emacs. > Gnulib's sig2str module depends on its signal-h module, so other > projects that use sig2str get the POSIX-compatible API with no fuss. The > MSVC port of Emacs is a special case There's no MSVC port of Emacs, not for many years. > I doubt whether any other project does anything similar. If there is > one, it will have its own special reasons and will need to accommodate > them. If that ever happens, we can then worry about whether its > accommodations can be shared via Gnulib with Emacs's; this will surely > affect many functions other than sig2str. In the meantime, as you > mentioned the Emacs patch I proposed is good enough to solve this > particular problem. > > > > Once again, assuming every program that needs sig2str should also use > > the Gnulib signal.h header is IMO wrong. > > The issue is not just sig2str; it's also sigaction and many other > functions. And the issue is not limited to signal.h; it's also present > in stdio.h and many other standard headers. Gnulib's design principle is > to make the API resemble the GNU API as best it can. Of course that > principle could be changed if needed, but any such change should be > discussed on bug-gnulib@gnu.org, as it's a much bigger issue than just > sig2str and Emacs. I have neither time nor energy for this Gnulib politics, so I went ahead and installed a workaround for this. (If I had more free time, which I don't, I'd stopped using the Gnulib sig2str.c altogether to avoid the issue in the first place, but things being as they are, I installed an easier cop-out.) If the Gnulib folks (CC'ed) are ready to reconsider, I will be happy to remove the workaround.
