bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Bruno Haible
Subject: Re: [PATCH 2/2] error: merge from glibc and with verror
Date: Thu, 15 Aug 2024 12:09:23 +0200

Paul Eggert wrote:
> I didn't find it simple in this case. ...
> 
> This is my usual experience, to be honest. I try to copy from existing 
> decls but I usually get it wrong.

In this case, it was because you wanted to tell the compiler's control
flow analysis about the STATUS != 0 case. This is very special.

> > 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.

Not me, this time. I'll need my energy for pushing getlocalename_l and
gettext_l into glibc.

> > 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?

Yes, that's what I thought as well, for many years. My thinking changed
  - after seeing that 6 packages had stopped using gnulib [1],
  - when realizing that my own CI jobs break each time gnulib makes a
    backwards-incompatible change, and I then typically face a CI failure,
    send a mail, and if the maintainer is unresponsive, I add a patch to
    the CI, to keep the CI working for the next months,
  - when noticing that I don't look at the NEWS file myself when upgrading
    gnulib in some packages (like gettext).

> 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.

Yes. It probably depends on the number of packages that would run into
compilation errors. In this case, for 5 packages, it doesn't seem worth
keeping a one-line lib/verror.h.

> the recently-added __attribute__ ((cold)), which wasn't my idea - 
> that came from Glibc.

I recently added a commit

  Use attribute [[nodiscard]] wherever glibc uses __wur.

Should we do the same thing, to mirror glibc attributes in gnulib's
function declarations, for all other attributes?

> 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.

I can do this.

> [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

Thanks for these changes!

Bruno

[1] https://lists.gnu.org/archive/html/bug-gnulib/2024-04/msg00233.html






reply via email to

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