Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > terminal designed for C

Reply
Thread Tools

terminal designed for C

 
 
lawrence.jones@siemens.com
Guest
Posts: n/a
 
      11-12-2012
Eric Sosman <(E-Mail Removed)> wrote:
> On 10/25/2012 12:09 AM, kerravon wrote:
> > [...]
> > 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>.
--
Larry Jones

The problem with the future is that it keeps turning into the present.
-- Hobbes
 
Reply With Quote
 
 
 
 
Tim Rentsch
Guest
Posts: n/a
 
      12-17-2012
Keith Thompson <(E-Mail Removed)> writes:

> James Kuyper <(E-Mail Removed)> writes:
>> On 10/26/2012 09:30 PM, kerravon wrote:
>>> On Saturday, October 27, 2012 11:39:28 AM UTC+11, Ian Collins 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.
 
Reply With Quote
 
 
 
 
Keith Thompson
Guest
Posts: n/a
 
      12-17-2012
Tim Rentsch <(E-Mail Removed)> writes:
> Keith Thompson <(E-Mail Removed)> writes:
>> James Kuyper <(E-Mail Removed)> writes:
>>> On 10/26/2012 09:30 PM, kerravon wrote:
>>>> On Saturday, October 27, 2012 11:39:28 AM UTC+11, Ian Collins 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.

--
Keith Thompson (The_Other_Keith) http://www.velocityreviews.com/forums/(E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      12-17-2012
On 12/17/2012 03:27 PM, Keith Thompson wrote:
> Tim Rentsch <(E-Mail Removed)> writes:
>> Keith Thompson <(E-Mail Removed)> writes:
>>> James Kuyper <(E-Mail Removed)> writes:

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

 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      12-17-2012
Keith Thompson <(E-Mail Removed)> writes:
> Tim Rentsch <(E-Mail Removed)> writes:
>> Keith Thompson <(E-Mail Removed)> writes:
>>> James Kuyper <(E-Mail Removed)> writes:
>>>> On 10/26/2012 09:30 PM, kerravon wrote:
>>>>> On Saturday, October 27, 2012 11:39:28 AM UTC+11, Ian Collins 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 (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      12-17-2012
James Kuyper <(E-Mail Removed)> writes:
[...]
> 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.)

--
Keith Thompson (The_Other_Keith) (E-Mail Removed) <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
James Kuyper
Guest
Posts: n/a
 
      12-17-2012
On 12/17/2012 04:35 PM, Keith Thompson wrote:
> James Kuyper <(E-Mail Removed)> writes:
> [...]
>> 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.
 
Reply With Quote
 
Tim Rentsch
Guest
Posts: n/a
 
      12-20-2012
Keith Thompson <(E-Mail Removed)> writes:

> Tim Rentsch <(E-Mail Removed)> writes:
>> Keith Thompson <(E-Mail Removed)> writes:
>>> James Kuyper <(E-Mail Removed)> writes:
>>>> On 10/26/2012 09:30 PM, kerravon wrote:
>>>>> On Saturday, October 27, 2012 11:39:28 AM UTC+11, Ian Collins 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.)
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
v = vte.Terminal() AttributeError: 'module' object has no attribute 'Terminal' Steve Python 2 12-07-2010 05:48 PM
open a new terminal window from another terminal window in linux/unixsystem gaurav kashyap Python 3 10-31-2008 12:10 PM
Ok cpu designed now what ? ;) Skybuck Flying VHDL 1 08-02-2005 08:19 AM



Advertisments