Path: csiph.com!eternal-september.org!feeder.eternal-september.org!nntp.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: _BitInt(N)
Date: Sun, 21 Dec 2025 23:07:55 -0800
Organization: A noiseless patient Spider
Lines: 79
Message-ID: <86h5tjro38.fsf@linuxsc.com>
References: <10dajlh$ko3c$1@dont-email.me> <10g7oqf$ojir$1@dont-email.me> <10g7ue4$r47b$1@dont-email.me> <10g9a0r$1a895$1@dont-email.me> <10g9fmh$1crf0$1@dont-email.me> <10g9i5e$1dpa3$1@dont-email.me> <10ga0sd$1jb9e$1@dont-email.me> <slrn10ih33q.bhp.ike@iceland.freeshell.org> <10ga3hn$1kv34$1@dont-email.me> <10gb1md$203ao$2@dont-email.me> <10gc28l$2c8jt$1@dont-email.me> <875xatbv2s.fsf@example.invalid> <10gddie$2tgu4$1@dont-email.me> <10gf3ci$1pe2v$1@dont-email.me> <861pkpt0rz.fsf@linuxsc.com> <10i7ec6$3s49j$1@paganini.bofh.team>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Mon, 22 Dec 2025 07:07:58 +0000 (UTC)
Injection-Info: dont-email.me; posting-host="a7f5d1e51a9a8827e6b0e0c25bf5c54b"; logging-data="3477400"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19YFM4/MEcX7C1q7/UOMpgJtFtaVMIiSew="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:+ARtj3UD9EYiGth9uYR+xY3nAW0= sha1:qw8k+q5ZnoGF8tzLJ0xia51AnHM=
Xref: csiph.com comp.lang.c:395877

antispam@fricas.org (Waldek Hebisch) writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>>
>>> bart <bc@freeuk.com> wrote:
>>>
>>>> On 28/11/2025 23:23, Keith Thompson wrote:
>>>>
>>>>> bart <bc@freeuk.com> writes:
>>>>>
>>>>>> On 28/11/2025 02:33, Janis Papanagnou wrote:
>>>>>
>>>>> [...]
>>>>>
>>>>>>>>>> You can of course add as many commodity features to "your
>>>>>>>
>>>>>>> language" as you like.  I seem to recall that one of the design
>>>>>>> principles of "C" was to not add too many keywords.  (Not sure
>>>>>>> whether 'A.odd' is a function or keyword above [in "your
>>>>>>> language"].)
>>>>>>
>>>>>> It is a reserved word, which means it can't be used as either a
>>>>>> top-level user identifier, or a member name.  With extra effort,
>>>>>> it could be used for both, but that needs some special syntax,
>>>>>> such as Ada-style "A'odd";  I've never got around to it.
>>>>>>
>>>>>> In Pascal (where I copied it from) it is a reserved word.
>>>>>
>>>>> <OT>In Pascal, "odd" is not a reserved word.  It's the name of a
>>>>> predefined function.</OT>
>>>>
>>>> So what's a 'reserved word' then?  To me it is something not
>>>> available as a user-identifier because it has a special meaning in
>>>> the language,
>>>
>>> That's a general description, but at least in C, there's several
>>> different kinds of reserved identifiers, each kind specifies
>>> different restrictions on user code use of that identifier.
>>>
>>> Note: in C2023, the [predefined macro names] section says:  "Any other
>>> predefined macro names:  shall begin with a leading underscore
>>> followed by an uppercase letter;  or, a second underscore...".  For
>>> earlier versions of the standard, user code should avoid using such
>>> identifiers because they were reserved for all purposes, but that's no
>>> longer the case.  Now, they should be avoided because they may be
>>> pre-defined by the implementation, which means that any attempt to use
>>> them might have unpredictable results.
>>
>> That's right in the sense that if the implementation is unknown then
>> unexpected results may occur.  However, if the implementation is
>> known, then we can find out what results are expected by consulting
>> the implementation's documentation for extensions, since any such
>> macro name must qualify as an extension, and so much be documented.
>
> Hmm, looking at '/usr/include/string.h' on my machine I see definitions
> of things like
>
> __GLIBC_INTERNAL_STARTING_HEADER_IMPLEMENTATION
> __need_size_t
>
> and lot of similar things.  I do not recall seeing any user
> documentation listing them.  Does this mean that gcc+glibc
> is noncompilant in this aspect?

I think it's reasonable to say that the appearance of a macro
name being #define'd in a standard header qualifies as
documenting the name being #define'd.  As long as the #define is
readable in an ordinary source file, there isn't any mystery
about the name being used or what its definition is.  I suppose
that to satisfy the letter of the C standard, the accompanying
document would need to incorporate the system header files by
reference, but surely the header files satisfy the spirit of
providing the required documentation.  Implementation-defined
values for things like CHAR_BIT and INT_MAX fall under the same
rule for documentation as do extensions, yet as far as I know
these values are defined only in system header files, and not in
any separate document.