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

Groups > comp.lang.c > #380797

Re: Effect of CPP tags

Show all headers | View raw

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> On 1/21/24 12:55, Kaz Kylheku wrote:
>
>> On 2024-01-21, James Kuyper <jameskuyper@alumni.caltech.edu> wrote:
>>
>>> However, it seems more reasonable to me that whether or not
>>> something is an extension is not supposed to be up to the
>>> implementor to decide.  Instead, anything that is an extension
>>> must be listed.  This would be an easier interpretation to defend
>>> if there were any explicit definition of "extension" in the
>>> standard.
>>
>> The implication is that anything that works by accident must be
>> listed as an extension.  If function arguments happen to be
>> evaluated left to right, with all side effects complete between
>> them, this has to be listed as an extension.  Then in the future
>> when the vendor finds that inconvenient for further compiler work,
>> they have to take away the extension.
>
> No, that's unspecified behavior, if 4p9 were intended to be
> understood as mandating documentation of all unspecified behavior,
> it would make the category of implementation-defined behavior
> redundant.

Quite so.

> Since extensions are also explicitly prohibited from changing the
> behavior of strictly conforming code, I think that in order for
> something qualify as an extension, it has to define behavior that
> the standard leaves undefined.

The essential property of an extension is that it must specify a
language feature or library feature that is not specified in the C
standard.  Implementations are free to /define/ undefined behavior
any way they want, and doing so doesn't require an extension;  the
point of documenting an extension is to /specify what happens/ in
certain cases, which also means giving a guarantee that what is
documented is what will happen (with the understanding that the
guarantee is only that the implementation will make its best
efforts to do so, because some results are outside of an
implementation's ability to control).

(I note in passing that an odd consequence of how the C standard
uses certain terminology is that "defining" something doesn't stop
it from being "undefined".  The term "undefined behavior" is thus
something of a misnomer.  But I digress.)

Conversely, an extension can specify a feature that is not, or
might not be, undefined behavior, but still needs to be documented
as an extension.  For example

    #include <foo.h>

is not undefined behavior, but must be documented as an extension
if the header <foo.h> is part of the implementation, because what
is in the header <foo.h> is not specified in the C standard.
Similarly, a declaration like

    typedef __uint128_t U128;

is not necessarily undefined behavior, because implementations are
free to define reserved identifiers any way they wish.  But if it's
important that it work, then it must be documented as an extension,
as otherwise an implementation is free to reject it by virtue of
using a language feature not specified in the C standard (which
therefore means the program is not strictly conforming, and so can
be rejected).

> In a certain sense, every
> implementation implicitly defines that behavior - whatever it is
> that actually happens when the behavior is undefined is that
> definition.  However, I think an extension should have to be
> explicitly activated by some deliberate user choice, such as a
> compiler option or by defining the behavior of some kinds of
> syntax not allowed by the C standard.  That's just IMHO, of course
> - in the absence of a explicit definition in the standard, it's
> hard to be sure what the committee intended.

That's a QOI issue.  I'm not convinced that it's a good idea in
all cases.  For example, either of the two cases mentioned above:

    #include <foo.h>

    typedef __uint128_t U128;

do not IMO need an explicit user action to activate, because it's
obvious they are making use of extensions, and are pretty unlikely
to occur by accident.  I concede however that other people may
reasonably hold other views on that question.

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

Thread

Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-20 14:29 -0800
  Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-21 04:46 +0000
    Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-21 10:56 -0500
    Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-21 12:11 -0500
      Re: Effect of CPP tags Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-21 17:55 +0000
        Re: Effect of CPP tags James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-21 21:57 -0500
          Re: Effect of CPP tags Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-24 07:42 -0800

csiph-web