Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch
Newsgroups: comp.lang.c
Subject: Re: "A diagram of C23 basic types"
Date: Tue, 06 May 2025 06:56:43 -0700
Organization: A noiseless patient Spider
Lines: 41
Message-ID: <86a57p3kro.fsf@linuxsc.com>
References: <87y0wjaysg.fsf@gmail.com> <87h62ys4w5.fsf@nosuchdomain.example.com> <86ecy2c5o4.fsf@linuxsc.com> <87mscprhhe.fsf@nosuchdomain.example.com> <20250409105549.000037dd@yahoo.com> <86semhawhs.fsf@linuxsc.com> <20250410115004.00005276@yahoo.com> <86ikn79mlq.fsf@linuxsc.com> <20250414125529.00000673@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Tue, 06 May 2025 15:56:47 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="f84420402be78ce51ba0e8f0077f27e2";
logging-data="3247881"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+OX8e166A5iaEbBzjp+tzJul3Iyaqc+Jk="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:BcOHzDFR/eibnJE7Ga0nfi5MKbM=
sha1:ALdfwysiEg1Pa7j+f0uTBMzYcnk=
Bytes: 3409
Michael S writes:
> On Mon, 14 Apr 2025 01:24:49 -0700
> Tim Rentsch wrote:
>
>> about where they may or may not be used. Do you really have a
>> problem avoiding identifiers defined in this or that library
>> header, either for all headers or just those headers required for
>> freestanding implementations?
>
> I don't know. In order to know I'd have to include all
> standard headers into all of my C files
Let me ask the question differently. Have you ever run into an
actual problem due to inadvertent collision with a reserved
identifier?
> But I would guess that for headers required for freestanding
> implementations I would have no problems.
There are a few freestanding-required headers that I use often
enough that for practical purposes they can be considered as
always having been #include'd. Those headers are ,
, and .
For headers more generally, , , and
are the most prevalent; there are cases where these headers have
not been #include'd, but those cases are the exception rather than
the rule. All other headers I #include only on an as-needed basis,
although the threshold is higher for some than for others. A good
example is . I try to limit those .c files where
has been #include'd, because of the rule about preprocessor symbols
starting with E (which I treat as ruling out any macro starting with
the letter E, even though the rule in the C standard might be
somewhat different). For comparison, I'm okay with the rule that
function names that start str[a-z], mem[a-z], or wcs[a-s] should be
avoided everywhere (because of and ), and
similarly for function names that start either is[a-z] or to[a-z]
(because of ). A good resource for finding symbols to
avoid is the section on Future library directions, which offers a
nicely compact summary of the most significant reserved names.