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
