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: Thu, 08 May 2025 08:49:58 -0700
Organization: A noiseless patient Spider
Lines: 61
Message-ID: <8634df14rd.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> <86a57p3kro.fsf@linuxsc.com> <vvidv5$7r6u$1@paganini.bofh.team>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Thu, 08 May 2025 17:49:59 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="8ae053696287f1619c3fbdcfaf84f4fc";
	logging-data="2018023"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19QDaGVEvR3QEtvhtWw6tUFjyksnily4BE="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:ryAg9730xiZ0T68W8phBcer5ixU=
	sha1:DERNnyLLbw4Na7mqKVbhlep4TZY=
Bytes: 3584

antispam@fricas.org (Waldek Hebisch) writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> 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?
>
> Not in my own code.  But I remember an old piece of code whose
> author apparently thought that 'inline' is a perfect name for
> input line.

Yeah.  That falls into a different category, because 'inline' is a
keyword rather than being defined in a standard header.  In any case
the problem is essentially impossible to miss, and straightforward
to fix.

> Few days ago I had trouble compiling with gcc-15
> code which declares its own 'bool' type.  The code is supposed to
> compile using a wide range of compilers, so I am still looking
> for "best" solution.

When I had to deal with a similar problem in the past, my
approach was something along these lines (obviously more
cases can be added if needed to deal with unusual compilers
or compilation options):


#if defined bool
#undef bool
#endif

#if !defined __STDC_VERSION__  ||  __STDC_VERSION__ < 199901L
                                        typedef unsigned char   bool;

#elif __STDC_VERSION__ < 201112L
                                        typedef _Bool           bool;

#elif __STDC_VERSION__ < 201710L
                                        typedef _Bool           bool;

#elif __STDC_VERSION__ < 202300L
                                        typedef _Bool           bool;

#else
                                        /* 'bool' is keyword in C23+ ... */

#endif