Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: "A diagram of C23 basic types"
Date: Thu, 08 May 2025 05:59:29 -0700
Organization: A noiseless patient Spider
Lines: 57
Message-ID: <86r00z1cni.fsf@linuxsc.com>
References: <87y0wjaysg.fsf@gmail.com> <vsj2l9$1j0as$1@dont-email.me> <vsjef3$1u4nk$1@dont-email.me> <vsjg6t$20pdb$1@dont-email.me> <vsjjd1$23ukt$1@dont-email.me> <vsjkvb$25mtg$1@dont-email.me> <vsjlkq$230a5$2@dont-email.me> <vsjs5k$2bfc5$2@dont-email.me> <vsjvgu$2fpp1$1@dont-email.me> <20250402113624.693@kylheku.com> <86o6xdhorr.fsf@linuxsc.com> <vsn0dm$2al86$1@paganini.bofh.team> <87ikngd7jg.fsf@nosuchdomain.example.com> <vt15l5$3e57a$1@paganini.bofh.team> <86y0vh7g3k.fsf@linuxsc.com> <5htQP.762158$D41.47359@fx45.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Thu, 08 May 2025 14:59:30 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="8ae053696287f1619c3fbdcfaf84f4fc";
	logging-data="1861917"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19iBYJuB63etmsNe7pL2gBN1sK62PNyF6M="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:uGCRL15duX1FQRyxBC6XyuDP1Ok=
	sha1:86Hmq4PdmfzAl2ltH+XlK2BVSDg=
Bytes: 4140

scott@slp53.sl.home (Scott Lurndal) writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> antispam@fricas.org (Waldek Hebisch) writes:
>
>
>> I believe that's not true, but certainly it is not /clearly/ true.
>> A lot of time passed between 1978, when K&R was published, and
>> 1989, when the first C standard was ratified.  No doubt the C
>> standard unified different practices among many existing C
>> implementations, but it is highly likely that some of them
>> anticipated the rules that would be ratified in the C standard.
>
> Looking at SVID 3rd edition (1989), size_t did not yet exist, so in
> that particular case, there was no need to implicitly define it in
> any header file.
>
> For interfaces that require custom typedefs (for example, stat(2)),
> the SVID requires the programmer include <sys/types.h> before
> including <sys/stat.h>.
>
> When size_t was added there were existing interfaces where the
> argument was changed to require size_t/ssize_t.  These interfaces
> did not, at the time, require the programmer to include
> <sys/types.h> or <stddef.h> in order to use the interface, for
> example in the SVID memory(BA_LIB) interface description, the
> programmer had been instructed that only <string.h> was required
> for the str* functions, and <memory.h> was required for the mem*
> functions - but the SVID noted at that time that the latter was
> deprecated - the pending ANSI C standard was to require only
> <string.h>.
>
> So, when the arguments of memcpy/strcpy were changed from int to
> size_t, they couldn't go back and require existing code to include
> e.g. <stddef.h> to get size_t;  POSIX chose to note in the
> interface description that additional typedefs may be visible
> when <string.h> is included.
>
>   "The <string.h> header shall define NULL and size_t as described
>    in <stddef.h>."

Thank you for this report.  I wasn't paying attention to any
standardization efforts in that time frame;  it's good to have
some actual data to look at.

After digging into the history, I have the impression that SVID
was hoping to be a leader in defining standard interfaces (which
I think included C proper but was not limited to that, which
makes sense as there was also Unix to consider).  So it isn't
surprising that size_t did not appear in SVID until the onoing
ANSI effort completed, and the ANSI C standard was ratified.  No
doubt there were other organizations closer to the then-current
C standardization effort (which had been going on for at least
five years IIANM), and it seems likely that in some cases there
were environments in use that anticipated the looming ANSI C
standard.