Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #381412

Re: Effect of CPP tags

Show all headers | View raw

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

[...]

> 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, I don't see any
requirement in the standard that it must 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.)

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-31 12:43 -0800
  Re: Effect of CPP tags Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-31 13:41 -0800
    Re: Effect of CPP tags David Brown <david.brown@hesbynett.no> - 2024-02-01 09:19 +0100

csiph-web