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
