Paul Eggert wrote:
> > GNU gettext uses the XMALLOC macro in more than 100 places. It's
> > just so convenient to do a memory allocation in 1 line of code:
>
> I find it more convenient to write this:
>
>context = xmalloc (sizeof *context);
>
> than this (taken from GNU gettext):
>
>con
Here are the URLs:
POSIX:2024 (= "Issue 8") https://pubs.opengroup.org/onlinepubs/9799919799/
POSIX:2018 (= "Issue 7") https://pubs.opengroup.org/onlinepubs/9699919799/
POSIX:2004 (= "Issue 6") https://pubs.opengroup.org/onlinepubs/009604599/
I pushed these two documentation changes:
20
Hi,
There are many changes in POSIX:2024 that can have an impact on Gnulib;
it is useful to keep track of which changes have been dealt with and which
are still open.
Also, we are several people who can contribute at any time. Therefore it
is useful to avoid duplicate work, that would only result
And another documentation change:
2024-07-20 Bruno Haible
doc: Update status of functions that are added in POSIX:2024.
* doc/posix-functions/_Fork.texi: Moved here from doc/glibc-functions/.
* doc/posix-functions/accept4.texi: Likewise.
* doc/posix-functions/a
Hi,
Currently, in the Gnulib manual [1], chapter 10 "ISO C and POSIX Function
Substitutes" lists all functions in alphabetical order. Whereas
chapter 13 "Glibc Function Substitutes" lists the function sorted by
header file, resulting in related function to sit close together.
I'm thinking that th
On 2024-07-20 06:41, Bruno Haible wrote:
I'm thinking that the same structure should also be applied to chapter 10.
Makes sense to me too, thanks. That's what the C standard does.
On 2024-07-20 03:27, Bruno Haible wrote:
This is where our opionions differ.
Yes, and I'm well aware of the advantages you listed for XMALLOC. In
practice, for me, they don't outweigh the disadvantages. (In that sense
they're like the advantages that C++ has over C)
Hi,
while testing glibc (master) against the gnulib (master) testsuite, I found new
object files being
built (compared to my glibc testing 6 months ago... but it's not a change in
glibc, I checked that):
getpayload.o
getpayloadf.o
getpayloadl.o
A look into config.log uncovered this snippet:
I did:
> 2024-07-20 Bruno Haible
>
> doc: Update status of functions that are added in POSIX:2024.
> * doc/posix-functions/_Fork.texi: Moved here from doc/glibc-functions/.
Followup:
2024-07-20 Bruno Haible
doc: Reference POSIX for functions that are added in POSIX:20
Hi,
Andreas K. Huettel wrote:
> while testing glibc (master) against the gnulib (master) testsuite, I found
> new object files being
> built (compared to my glibc testing 6 months ago... but it's not a change in
> glibc, I checked that):
>
> getpayload.o
> getpayloadf.o
> getpayloadl.o
>
> A
Paul Eggert wrote:
> > I'm thinking that the same structure should also be applied to chapter 10.
>
> Makes sense to me too, thanks. That's what the C standard does.
Done:
2024-07-20 Bruno Haible
doc: Sort the ISO C and POSIX Function Substitutes by header file.
* doc/gnulib
Two days ago, I did:
> 2024-07-17 Bruno Haible
>
> stack-trace: Use libasan as an alternative to libbacktrace.
> * m4/stack-trace.m4 (gl_STACK_TRACE_EARLY): As a second choice, use
> libasan.
It turns out that this does not work well:
1) When '-lasan' is added to LIBS, many
Hi Jeff,
You wrote on 2024-06-28:
> There are some proposed changes [1] to track finer-grained timestamps in
> the Linux kernel that will break the assumptions that nap() uses to
> gauge the delay. In particular, writing to a file will almost always
> show a change in the timestamp now, so usually
13 matches
Mail list logo
