| 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.