![]() |
|
Message-ID: <uuphjxy7aa5ma6absklxvoi3eyjqtfifqpgnph7htbeqwxqbot@cnfrjzer3fuu> Date: Wed, 23 Jul 2025 17:03:58 -0500 From: Eric Blake <eblake@...hat.com> To: Alejandro Colomar <alx@...nel.org> Cc: Rich Felker <dalias@...c.org>, enh <enh@...gle.com>, Florian Weimer <fweimer@...hat.com>, Adhemerval Zanella Netto <adhemerval.zanella@...aro.org>, musl@...ts.openwall.com, libc-alpha@...rceware.org, Joseph Myers <josmyers@...hat.com>, наб <nabijaczleweli@...ijaczleweli.xyz>, Paul Eggert <eggert@...ucla.edu>, Robert Seacord <rcseacord@...il.com>, Bruno Haible <bruno@...sp.org>, bug-gnulib@....org, JeanHeyd Meneide <phdofthehouse@...il.com>, Thorsten Glaser <tg@...bsd.de> Subject: Re: Re: BUG: realloc(p,0) should be consistent with malloc(0) Sorry for the delayed response; I've been offline for a couple of weeks. On Sat, Jul 05, 2025 at 01:31:22AM +0200, Alejandro Colomar wrote: > Hi Eric, > > On Fri, Jun 20, 2025 at 01:38:14AM +0200, Alejandro Colomar wrote: > > > > - POSIX.1-2001 > > > > > > This one defers to C89 anywhere that it is not explicitly documenting > > > with CX shading. > > > > Ahh, I had thought it would defer to C99 because it's older, but I guess > > it's like POSIX.1-2024 that doesn't defer to C23. Thanks! Then I stand > > corrected, and glibc conforms to POSIX.1-2001. > > I was reading the memccpy(3) specification in POSIX.1-2004, and found > this: > > Issue 6 > > The restrict keyword is added to the memccpy() prototype > for alignment with the ISO/IEC 9899:1999 standard. > > So, Issue 6 aligned with ISO C99? Is this exceptional, or does then > POSIX.1-2001 not defer to ISO C89? Hmm - I may have been too hasty in my original research, so I'm redoing it now. Disclaimer - my contributions to POSIX started after 2004, so anything pre-dating that is based on what documents I can access and not first-hand knowledge. I have access to a document P1003.1b-1993.pdf; with the title including "(POSIX@)-Part1: System Application Program Interface (MI)-Amendment 1: Realtime Extension [C Language]", and it clearly calls out (page xiii line 131) "This standard is written in terms of the standard C language as specified in the C Standard {2)"; chasing that reference finds section 1.2 (page 3 line 56) "ISOIIEC 9899: 1990, Programming languages--C’." which is clearly C90 (and it pre-dates C99, so that makes sense). The next revision appears to be online at [1] which clearly states "The Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004 Edition" in its preface; chasing links finds [2] which lists "ISO C (1999) ISO/IEC 9899:1999, Programming Languages - C, including Technical Corrigendum 1.", very obviously C99. And wikipedia confirms that POSIX.1-2004 is merely a TC revision to POSIX.1-2001 (no way a TC would have changed normative references to the C standard). So I stand corrected - Issue 6 defers to C99, not C90. [1] https://pubs.opengroup.org/onlinepubs/009696699/frontmatter/preface.html [2] https://pubs.opengroup.org/onlinepubs/009696699/basedefs/xbd_chap01.html#tag_01_03 > > BTW, I was trying to find out the history of memccpy(3), and why it was > introduced in 4.4BSD. Does anyone know the history? I find it a weird > function that doesn't have any good use case, or I don't seem to see it. POSIX says "First released in Issue 1. Derived from Issue 1 of the SVID."; I agree that I haven't seen it in much use, but it was probably standardized merely because it was easy alongside all the other mem* interfaces. > Every use case I see, such as a poor-man's strlcpy(3), seems to be prone > to off-by-one errors, or have other APIs that would be more ergonomic. > What were the original uses in 4.4BSD? > -- Eric Blake, Principal Software Engineer Red Hat, Inc. Virtualization: qemu.org | libguestfs.org
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.