Re: "A diagram of C23 basic types"

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.