Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: Effect of CPP tags
Date: Thu, 14 Mar 2024 23:11:27 -0700
Organization: A noiseless patient Spider
Lines: 128
Message-ID: <867ci4owhc.fsf@linuxsc.com>
References: <umet9d$3hir9$1@dont-email.me> <umk836$ehn5$1@dont-email.me> <4434vmp2fl.fsf@be-well.ilk.org> <87wmsyuj1l.fsf@nosuchdomain.example.com> <20231228134234.49@kylheku.com> <87sf3lvs43.fsf@nosuchdomain.example.com> <86y1cjiqpu.fsf@linuxsc.com> <20240120203343.615@kylheku.com> <d1d7ac1e-63ff-41a0-9e3d-78e878b56afc@alumni.caltech.edu> <a5f31f1747a49217b66c67f4deabd963@kylheku.com> <uojj7p$8crh$1@dont-email.me> <20240121094637.874@kylheku.com> <86wmrp9qt8.fsf@linuxsc.com> <87cythrxip.fsf@nosuchdomain.example.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: dont-email.me; posting-host="ebc16c50d4d7433bc8cd997a3211d402";
	logging-data="2261931"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX186hASSO1uOzPF8T87qL4Zj5knHWXndqx4="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:ucqCiUr0XucIXEtpR9orVbWiRUg=
	sha1:QRjBpmqDj6tvguuEn2Tmut2e0lw=
Bytes: 7583

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
>
>> Kaz Kylheku <433-929-6894@kylheku.com> writes:
>> It's important to understand what constitutes an extension.  And
>> there are different kinds of extensions.
>>
>> If an implementation chooses, say, to evaluate function arguments
>> always left-to-right, that is perfectly okay (and need not be an
>> extension).  But if an there is to be a /guarantee/ that function
>> arguments will always be evaluated left-to-right, that means
>> providing a guarantee that the C standard does not;  thus we have an
>> extension (to the requirements in the C standard), and the extension
>> must be documented.  This case is one kind of extension.
>
> If an implementation chooses to guarantee left-to-right evaluation, I
> don't see anything in the standard that requires that guarantee to be
> documented.  (Of course it can and should be.)
>
> It's not entirely clear to me exactly what must or must not be
> considered to be an "extension" as the C standard uses the term.  The
> standard doesn't show the word "extension" in italics or provide a
> definition in section 3.
>
> Unless your point is that it's not a guarantee unless it's documented?
> But I don't see that that documentation is required *by the standard*.

It seems likely that we have different notions of what "a guarantee"
is.  As I am using the term it does not mean a statement of what
does happen but a promise for what will happen.  Consulting some
online dictionaries, I find the following definitions (among others
that for the most part are not relevant).  Note that all of these
are for "guarantee" used as a noun (presented in the order of
shortest first):

    an assurance for the fulfillment of a condition

    Something that assures a particular outcome or condition.

    A pledge that something will be performed in a specified
    manner.

    an unconditional commitment that something will happen or
    that something is true

    a written assurance that some product or service will be
    provided or will meet certain specifications

    A promise or assurance, especially one given in writing, that
    attests to the quality or durability of a product or service.

    a promise or assurance, especially one in writing, that
    something is of specified quality, content, benefit, etc.,
    or that it will perform satisfactorily for a given length of
    time:  "a money-back guarantee".

In the context of a C implementation, for some condition to be a
guarantee I would say it must be written down (which is to say,
documented), as otherwise it doesn't qualify as a guarantee.  In
any case that is how I am using the term.

Incidentally, as best I can determine the C standard uses the
term "guarantee" as a noun in only one place in normative text
(6.5.2.3 p6) and in two places in informative text (5.1.2.4 p23
and a footnote to 7.22.2.1 p2).  Various forms of "guarantee"
used as a verb appear in the C standard in lots of places.  I am
specifically using the noun form in my comments here.

I think most people would agree that any documented guarantee of
behavior beyond what the C standard requires of all implementations
(and is not part of the documentation for implementation-defined
behaviors) qualifies as an extension to the C language, and thus
should be considered an extension as the ISO C standard uses the
term, given that the C standard itself does not define the term
but (one assumes) uses the word in its ordinary English sense.
   

> [...]
>
>> If an implementation chooses to define, for example, __uint128_t to
>> be the name of an integer type, that represents a third kind of
>> extension.  (Annex J.5 also mentions such definitions as an example
>> on its list of "Common extensions".)  Such cases must be documented
>> as extensions because, one, the expected default is that there be no
>> definition (which normally would cause a diagnostic because of some
>> constraint violation), and two, only the implementation is in a
>> position to know if the symbol in question was defined by the
>> implementation or by something else.  Clearly any definition the
>> implementation provides signals a change from the expected default,
>> which by any reasonable definition of the word constitutes an
>> extension, and hence must be documented.
>
> Again, that can and should be documented, but since any use of the
> identifer __uint128_t has undefined behavior,

That isn't right.  The C standard says that declaring or defining a
reserved identifier is undefined behavior.  The C standard does NOT
say that using a reserved identifier is undefined behavior.  If an
implementation does not define an identifier like __uint128_t, then
any use in ordinary code (that is, not part of a pre-processor
directive) should produce a diagnostic due to a syntax or constraint
violation.  If we don't get a diagnostic we know that the identifier
/must/ have been defined by the implementation, and because it is a
change in behavior over standard C it must be documented as an
extension.

(Note added during editing:  "any use in ordinary code" is meant in
the sense of "a use that is not a declaration or definition".)

> I don't see any
> requirement in the standard that it must be documented.

It must be documented because it represents a change in behavior
over what the C standard requires, and any such change constitutes
an extension to the language, and the C standard requires extensions
to be documented.

> (Aside: gcc has an extension adding __int128 as a keyword, supporting
> types "__int128" and "unsigned __int128", but only on some target
> systems.  These do not qualify as extended integer types.  I understand
> that "__uint128_t" was a hypothetical example.)

On the systems I use the identifiers __int128_t and __uint128_t are
both predefined type names (and not keywords), under both gcc and
clang.  I see some support for __int128 as a keyword, but the
predefined type names seem to be more reliable (at least in my
environments).