Re: [PATCH 2/2] error: merge from glibc and with verror

[Paul Eggert]

On 2024-08-15 00:05, Bruno Haible wrote:

> Declaring Gnulib functions in general is just a matter of copying the
> same idiom that we have in hundreds of places in *.in.h files. Its
> history and genesis is not simple; but the result is simple to apply.

I didn't find it simple in this case. For example, verror_with_line is 
treated quite differently from error_with_line, because I couldn't 
easily decide the right way to adapt error_with_line's decl. The 
situation is not quite the same, because error_with_line might replace 
and verror_with_line doesn't. Also, error_with_line doesn't have the 
problem that verror_with_line does with that funny macro business in 
error.c (see below).

This is my usual experience, to be honest. I try to copy from existing 
decls but I usually get it wrong. It can be frustrating. I vaguely 
understand why everything is there (some of it to do with C++, 
unfortunately) but it's generally a tricky business.


> What I find to be an unusual complexity here is that verror and verror_at_line
> are defined by error.c; yet when I glance through error.c quickly I don't see
> verror and verror_at_line being defined there. Hiding function definitions
> behind macros...

Yes, that complexity comes from the desire to keep error.c the same in 
Gnulib and glibc.


> Is it planned that glibc exports verror and verror_at_line at some point?

I don't have plans in that direction. Would probably be a good idea if 
someone had the energy to do it.


> Also, since this was a breaking change, someone will need to send patches
> to coreutils, m4, man-db, patch, and libpipeline [1]. It is not nice if
> we leave it as a bad surprise to the maintainer of one of these packages.

First I've heard about sending email. I thought that the NEWS entries 
were designed for that sort of thing?

It's a judgment call as to whether Gnulib should keep around a one-line 
file lib/verror.h containing just "#include <error.h>" for backward 
compatibility. Gnulib is a source-code package, where minor glitches are 
to be expected, so I figured we might as well go without that shim.

To try this out I just now updated bleeding-edge coreutils and m4 to use 
the latest Gnulib[1][2]. Both needed to remove "#include <verror.h>" 
lines - the breakage you mentioned - but I found that a bigger hassle 
was the recently-added __attribute__ ((cold)), which wasn't my idea - 
that came from Glibc. Also m4 still has a bogus -Wnull-dereference 
diagnostic, unrelated to the verror.h changes, that somebody needs to 
investigate when they find the time. Looking at this slightly bigger 
picture, removing verror.h lines seems pretty minor.

[1]: 
https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=827186453707186a5c18f163dcc0b7a4d63427c2
[2]: 
https://git.savannah.gnu.org/cgit/m4.git/commit/?h=branch-1.4&id=b357b798b04053df437b2df2f4f42dca69fb764c