Groups | Search | Server Info | Keyboard shortcuts | Login | Register

Groups > comp.lang.c > #393208

Re: "A diagram of C23 basic types"

Show key headers only | View raw

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.

Back to comp.lang.c | Previous | Next — Next in thread | Find similar

Thread

Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-06 06:56 -0700
  Re: "A diagram of C23 basic types" Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-06 13:25 -0700
    Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-08 08:37 -0700
      Re: "A diagram of C23 basic types" scott@slp53.sl.home (Scott Lurndal) - 2025-05-08 15:48 +0000
        Re: "A diagram of C23 basic types" Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-08 16:32 +0000
        Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-08 22:53 -0700
  Re: "A diagram of C23 basic types" antispam@fricas.org (Waldek Hebisch) - 2025-05-08 14:09 +0000
    Re: "A diagram of C23 basic types" David Brown <david.brown@hesbynett.no> - 2025-05-08 16:52 +0200
    Re: "A diagram of C23 basic types" Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-08 08:49 -0700

csiph-web