Re: Effect of CPP tags

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