terminal designed for C

[lawrence.jones]

[...]
I also raised a "please explain what you were smoking" to
the X3J11 committee

Does that committee still exist? It's mentioned nowhere
in or on ISO/IEC 9899:201x (admittedly not the actual Standard,
but reputed to be pretty close), and a search on ANSI's own
web site turns up "No Results." How did you contact them?

Yes, it still exists, it's just been renamed to INCITS PL22.11. INCITS
(the InterNational Committee for Information Technology Standards) is
the primary organization ANSI has designated to create IT standards.
PL22 is their Programming Languages technical committee and PL22.11 is
the subcommittee responsible for C. See <http://www.incits.org>.

 

[Tim Rentsch]

Actually, that's not something that's necessarily up to the OS, though
some OS's do make a C compiler one of the standard utilities.


No, that isn't the case. A C99 compiler need not conform to C90, and
need not even have a option to do so. It may even be impossible to
conform to both simultaneously, though I'd have to think about that for
a while to be sure.

Hmm. I think it would be possible for a compiler to conform to both C90
and C99, though it would be ugly. [snip elaboration]

Can't be done, because there are programs that are well-defined
in both languages but have different semantics in the two cases.

 

[Keith Thompson]

On 10/26/2012 09:30 PM, kerravon wrote:
I would expect a decent contemporary operating system to follow C99...

Actually, that's not something that's necessarily up to the OS, though
some OS's do make a C compiler one of the standard utilities.

In order to do C99, C90 has to be covered as well.

No, that isn't the case. A C99 compiler need not conform to C90, and
need not even have a option to do so. It may even be impossible to
conform to both simultaneously, though I'd have to think about that for
a while to be sure.

Hmm. I think it would be possible for a compiler to conform to both C90
and C99, though it would be ugly. [snip elaboration]

Can't be done, because there are programs that are well-defined
in both languages but have different semantics in the two cases.

I'd be interested in seeing an example.

 

[James Kuyper]

No, that isn't the case. A C99 compiler need not conform to C90, and
need not even have a option to do so. It may even be impossible to
conform to both simultaneously, though I'd have to think about that for
a while to be sure.

Hmm. I think it would be possible for a compiler to conform to both C90
and C99, though it would be ugly. [snip elaboration]

Can't be done, because there are programs that are well-defined
in both languages but have different semantics in the two cases.

I'd be interested in seeing an example.

Reviewing the list of changes from C90 in paragraph 5 of the Forward to
n1256.pdf, it seems as though most of the differences took the form of
giving defined behavior to code that was a syntax error, a constraint
violation, or had undefined behavior in C90. In a few cases the opposite
occurred. None of those cases is a barrier to simultaneous conformance:
give the constructs the meaning required by one version of the standard,
after generating the diagnostic (if any) required by the other version.

It requires more knowledge than I possess about C90 to determine whether
any of these cases would actually prevent simultaneous conformance:

Is there any context where UCNs are allowed in C99, where they would
also have been permitted in C90 with a conflicting interpretation?

It merely says that the integer constant type rules and the promotion
rules change. Is there any case where those changes could not be
rendered invisible by suitable choices for the values of *_MAX from
<limits.h>?

 

[Keith Thompson]

On 10/26/2012 09:30 PM, kerravon wrote:
I would expect a decent contemporary operating system to follow C99...

Actually, that's not something that's necessarily up to the OS, though
some OS's do make a C compiler one of the standard utilities.

In order to do C99, C90 has to be covered as well.

No, that isn't the case. A C99 compiler need not conform to C90, and
need not even have a option to do so. It may even be impossible to
conform to both simultaneously, though I'd have to think about that for
a while to be sure.

Hmm. I think it would be possible for a compiler to conform to both C90
and C99, though it would be ugly. [snip elaboration]

Can't be done, because there are programs that are well-defined
in both languages but have different semantics in the two cases.

I'd be interested in seeing an example.

After posting that, I realized one can find such examples by searching
for "QUIET CHANGE IN C99" in the C99 Rationale,
<http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf>.

Not all such changes preclude the possibility of a compiler making
careful implementation-defined choices to avoid running into them,
or by implementing the C99 semantics for cases of undefined behavior
in C90, but:

a = b //*divisor:*/ c
+ d;

means `a = b / c + d;` in C90, but `a = b + d;` in C99.

enum {a, b};
int different(void)
{
if (sizeof(enum {b, a}) != sizeof(int))
return a; /* a == 1 */
return b; /* which b? */
}

returns 0 in C90, 1 in C99.

strtod() behaves differently for an argument string such as
"0x12.34p-12", due to the introduction of hexadecimal floating-point
constants.

 

[Keith Thompson]

Is there any context where UCNs are allowed in C99, where they would
also have been permitted in C90 with a conflicting interpretation?

[...]

I think it's possible for a given implementation, but only for programs
whose behavior is undefined in C90.

C90 doesn't define \u and \U escapes, and says "If any other escape
sequence is encountered, the behavior is undefined".

("gcc -ansi -pedantic" uses C99 semantics for \u and \U.)

 

[James Kuyper]

Is there any context where UCNs are allowed in C99, where they would
also have been permitted in C90 with a conflicting interpretation?

[...]

I think it's possible for a given implementation, but only for programs
whose behavior is undefined in C90.

"undefined behavior" doesn't qualify as a "conflicting interpretation".
The fact that the behavior is undefined means that a fully conforming
implementation of C90 could provide the C99 behavior for such constructs.

 

[Tim Rentsch]

On 10/26/2012 09:30 PM, kerravon wrote:
I would expect a decent contemporary operating system to follow C99...

Actually, that's not something that's necessarily up to the OS, though
some OS's do make a C compiler one of the standard utilities.

In order to do C99, C90 has to be covered as well.

No, that isn't the case. A C99 compiler need not conform to C90, and
need not even have a option to do so. It may even be impossible to
conform to both simultaneously, though I'd have to think about that for
a while to be sure.

Hmm. I think it would be possible for a compiler to conform to both C90
and C99, though it would be ugly. [snip elaboration]

Can't be done, because there are programs that are well-defined
in both languages but have different semantics in the two cases.

I'd be interested in seeing an example.

I did indeed have an example ready, but thought it
would be more valuable, both for myself and others,
not to give one. (And that turned out to be right.)