Deutsch   English   Français   Italiano  
<86a57p3kro.fsf@linuxsc.com>

View for Bookmarking (what is this?)
Look up another Usenet article

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: 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> <vsj1m8$1f8h2$1@dont-email.me> <vsrqsh$qhuu$2@solani.org> <vt38i9$29prg$1@dont-email.me> <87h62ys4w5.fsf@nosuchdomain.example.com> <vt488v$35hh3$1@dont-email.me> <vt4n3d$3e8hi$1@dont-email.me> <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 <already5chosen@yahoo.com> writes:

> On Mon, 14 Apr 2025 01:24:49 -0700
> Tim Rentsch <tr.17687@z991.linuxsc.com> 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 <limits.h>,
<stdarg.h>, and <stddef.h>.

For headers more generally, <stdio.h>, <stdlib.h>, and <string.h>
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 <errno.h>.  I try to limit those .c files where <errno.h>
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 <stdlib.h> and <string.h>), and
similarly for function names that start either is[a-z] or to[a-z]
(because of <ctype.h>).  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.