Re: doc: Update for functions added in POSIX:2024

Collin Funk wrote: > Shouldn't this ChangeLog entry be doc/posix-functions instead of > doc/posix-headers? Just a minor thing I noticed. :) Oops. Corrected. Thanks. Bruno

Re: doc: Update for functions added in POSIX:2024

Hi Bruno, Bruno Haible writes: > doc: Update for ISO C functions added in POSIX:2024. > * doc/posix-headers/CMPLX*.texi: New files. > * doc/posix-headers/at_quick_exit.texi: New file. > * doc/posix-headers/atomic_*.texi: New files. > * doc/posix-headers/kill_depende

Re: doc: Update list of headers to use #include <...>.

Bruno Haible writes: > Looks good. You can also add a comment (@c in texinfo) with the > grep command: > > @c To find the list of files, use 'grep -l @INCLUDE_NEXT lib/*.in.h'. Thanks. Applied both with that comment added. Collin

Re: doc: Update list of headers to use #include <...>.

Hi Collin, > The grep should also include @INCLUDE_NEXT_AS_FIRST_DIRECTIVE@. Ah, right. > How do the attached patches look? Looks good. You can also add a comment (@c in texinfo) with the grep command: @c To find the list of files, use 'grep -l @INCLUDE_NEXT lib/*.in.h'. Thanks. Bruno

Re: doc: Update list of headers to use #include <...>.

Hi Bruno, Bruno Haible writes: > This is unnecessary. As noted in > > only those header files are needed that make use of #include_next. > Do a 'grep @INCLUDE_NEXT@ lib/*.in.h'. Right, I forgot that it only matters when #incl

Re: doc: Update list of headers to use #include <...>.

Hi Collin, > Now that sys/un.h might be replaced by Gnulib we have to keep in mind > the #include <...> vs. #include "..." issue. Yes, good point. > I also noticed some other files in lib/*.in.h were missing from the > lists so I added them too. This is unnecessary. As noted in

Re: doc: Update for glibc 2.39

And some more updates: 2024-06-15 Bruno Haible doc: Update for glibc 2.39. * doc/posix-functions/*scanf.texi: Update. diff --git a/doc/posix-functions/fscanf.texi b/doc/posix-functions/fscanf.texi index 2b07c1cdb8..240007be8d 100644 --- a/doc/posix-functions/fscanf.texi +++ b

Re: doc: Update macro list in gnulib-cache.m4 documentation.

Collin Funk wrote: > I've applied the attached patch updating the macro list in the > gnulib-cache.m4 documentation. Thanks! Appreciated.

Re: doc: Update regarding NetBSD

And here's the second attachment. To: gnats-b...@netbsd.org Subject: sigprocmask return value wrong when libpthread is in use From: br...@clisp.org Reply-To: br...@clisp.org X-send-pr-version: 3.95 >Submitter-Id: net >Originator: >Organization: GNU >Confidential: no >Synopsis: The ret

Re: doc: Update for glibc 2.32

On 8/7/20 2:08 PM, Bruno Haible wrote: I'm not sure whether the problem mentioned in lchown.texi and fchmodat.texi for glibc 2.31 is still open, or fixed, or partially fixed in glibc 2.32. I added some doc for that by installing the attached, which also adds doc for the longstanding faccessat

Re: doc: update for Solaris 11.4

Bruno Haible wrote: - They added 'timegm' and 'timelocal', but since gnulib does not have a unit test for them, I have no idea how buggy they are. Paul, do you have a unit test for these functions in some corner? I'm afraid not, and it's low priority. timelocal is merely a nonstand

Re: doc: update for recent Solaris release

Simon Josefsson wrote: > All the marketing materials seems to label it as "Solaris 11 11/11". > Where is "Solaris 11 2011-11" used? I took the freedom of transforming the month designation to ISO 8601 format. Two-letter year abbreviations are terrible. Bruno

Re: doc: update for recent Solaris release

Bruno Haible writes: > Oracle released a new version of Solaris 11, in November 2011. The > codename is "Solaris 11 2011-11". Oracle no longer labels it as > "Solaris 11 Express", merely "Solaris 11". All the marketing materials seems to label it as "Solaris 11 11/11". Where is "Solaris 11 2011-

Re: doc update

Bruno Haible writes: > Simon Josefsson wrote: >> The problem with this approach is that people will have only negative >> information to decide when it would make sense to use a >> gnulib-replacement module for a function, to deal with the platform that >> doesn't yet implement it. >> >> Persona

Re: doc update

Eric Blake writes: > Simon Josefsson josefsson.org> writes: > >> Personally, I think that if glibc, Mac OS X, cygwin and maybe Solaris > > Any of the BSDs? For example, FreeBSD is finally starting to provide all of > the POSIX *at interfaces, even faster than Solaris (even though it was > Sol

Re: doc update

Simon Josefsson wrote: > The problem with this approach is that people will have only negative > information to decide when it would make sense to use a > gnulib-replacement module for a function, to deal with the platform that > doesn't yet implement it. > > Personally, I think that if glibc, Mac

Re: doc update

Simon Josefsson josefsson.org> writes: > Personally, I think that if glibc, Mac OS X, cygwin and maybe Solaris Any of the BSDs? For example, FreeBSD is finally starting to provide all of the POSIX *at interfaces, even faster than Solaris (even though it was Solaris that even started the idea

Re: doc update

Ben Pfaff writes: > Simon Josefsson writes: > >> --- a/doc/glibc-functions/strtof_l.texi >> +++ b/doc/glibc-functions/strtof_l.texi >> @@ -11,6 +11,9 @@ Portability problems fixed by Gnulib: >> Portability problems not fixed by Gnulib: >> @itemize >> @item >> +This function is known to be pre

Re: doc update

Eric Blake writes: > Simon Josefsson josefsson.org> writes: > >> >> My patch didn't illustrate my point correctly: my point was that, >> according to Bruno (and my checks), we do know that at least Mac OS X >> 10.5 implements the *_l functions, so arguable our documentation should >> say that.

Re: doc update

Simon Josefsson writes: > --- a/doc/glibc-functions/strtof_l.texi > +++ b/doc/glibc-functions/strtof_l.texi > @@ -11,6 +11,9 @@ Portability problems fixed by Gnulib: > Portability problems not fixed by Gnulib: > @itemize > @item > +This function is known to be present on all glibc platforms an

Re: doc update

Simon Josefsson josefsson.org> writes: > > My patch didn't illustrate my point correctly: my point was that, > according to Bruno (and my checks), we do know that at least Mac OS X > 10.5 implements the *_l functions, so arguable our documentation should > say that. I still think that's overkil

Re: doc update

Simon Josefsson writes: > I'm thinking of patches like this: That patch was against an old gnulib, this is what I am really thinking of: diff --git a/doc/glibc-functions/strtof_l.texi b/doc/glibc-functions/strtof_l.texi index 00e74c4..dab09a0 100644 --- a/doc/glibc-functions/strtof_l.texi +++

Re: doc update

Eric Blake writes: > According to Simon Josefsson on 11/25/2009 2:43 AM: >> Bruno Haible writes: >> >>> This doc update considers that MacOS X 10.5 has most of the *_l functions >>> that >>> take a locale_t argument. >> ... >>> -This function is missing on all non-glibc platforms: >>> +This fu

Re: doc update

Bruno Haible writes: > Simon Josefsson wrote: >> That is a bit open-ended, isn't it? > > Well, the list of remaining files with this wording is not too long. > And we will certainly be interested to know when some other platforms > implements the same function, because that means that the particu

Re: doc update

Simon Josefsson wrote: > That is a bit open-ended, isn't it? Well, the list of remaining files with this wording is not too long. And we will certainly be interested to know when some other platforms implements the same function, because that means that the particular function becomes more mainstr

Re: doc update

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Simon Josefsson on 11/25/2009 2:43 AM: > Bruno Haible writes: > >> This doc update considers that MacOS X 10.5 has most of the *_l functions >> that >> take a locale_t argument. > ... >> -This function is missing on all non-glibc platfo

Re: doc update

Bruno Haible writes: > This doc update considers that MacOS X 10.5 has most of the *_l functions that > take a locale_t argument. ... > -This function is missing on all non-glibc platforms: > +This function is missing on many platforms: > MacOS X 10.3, FreeBSD 6.0, NetBSD 3.0, OpenBSD 3.8, AIX 5