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

Groups > comp.lang.c > #27559 > unrolled thread

terminal designed for C

Back to article view | Back to comp.lang.c

Contents

  terminal designed for C kerravon <kerravon@w3.to> - 2012-10-22 21:19 -0700
    Re: terminal designed for C Robert Wessel <robertwessel2@yahoo.com> - 2012-10-22 23:34 -0500
      Re: terminal designed for C kerravon <kerravon@w3.to> - 2012-10-22 21:56 -0700
    Re: terminal designed for C Sjouke Burry <s@b> - 2012-10-23 14:42 +0000
      Re: terminal designed for C Keith Thompson <kst-u@mib.org> - 2012-10-23 13:06 -0700
        Re: terminal designed for C kerravon <kerravon@w3.to> - 2012-10-23 15:46 -0700
          Re: terminal designed for C Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-10-23 20:29 -0400
            Re: terminal designed for C Lew Pitcher <lpitcher@teksavvy.com> - 2012-10-23 21:26 -0400
            Re: terminal designed for C kerravon <kerravon@w3.to> - 2012-10-24 02:59 -0700
              Re: terminal designed for C Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-10-24 14:15 -0400
              Re: terminal designed for C Lew Pitcher <lpitcher@teksavvy.com> - 2012-10-24 17:23 -0400
    Re: terminal designed for C Lew Pitcher <lpitcher@teksavvy.com> - 2012-10-23 18:55 -0400
      Re: terminal designed for C Keith Thompson <kst-u@mib.org> - 2012-10-23 19:56 -0700
      Re: terminal designed for C kerravon <kerravon@w3.to> - 2012-10-24 16:10 -0700
        Re: terminal designed for C Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-10-24 20:15 -0400
        Re: terminal designed for C Lew Pitcher <lpitcher@teksavvy.com> - 2012-10-24 21:13 -0400
          Re: terminal designed for C kerravon <kerravon@w3.to> - 2012-10-24 21:09 -0700
            Re: terminal designed for C "BartC" <bc@freeuk.com> - 2012-10-25 11:29 +0100
              Re: terminal designed for C kerravon <kerravon@w3.to> - 2012-10-25 03:51 -0700
            Re: terminal designed for C James Kuyper <jameskuyper@verizon.net> - 2012-10-25 08:49 -0400
            Re: terminal designed for C Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-10-25 09:04 -0400
              Re: terminal designed for C kerravon <kerravon@w3.to> - 2012-10-25 14:11 -0700
                Re: terminal designed for C Eric Sosman <esosman@comcast-dot-net.invalid> - 2012-10-25 17:29 -0400
                  Re: terminal designed for C kerravon <kerravon@w3.to> - 2012-10-26 03:33 -0700
                    Re: terminal designed for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-26 12:35 +0100
                      Re: terminal designed for C kerravon <kerravon@w3.to> - 2012-10-26 15:46 -0700
                        Re: terminal designed for C Keith Thompson <kst-u@mib.org> - 2012-10-26 17:11 -0700
                          Re: terminal designed for C kerravon <kerravon@w3.to> - 2012-10-26 17:27 -0700
                            Re: terminal designed for C Ian Collins <ian-news@hotmail.com> - 2012-10-27 13:39 +1300
                              Re: terminal designed for C kerravon <kerravon@w3.to> - 2012-10-26 18:30 -0700
                                Re: terminal designed for C James Kuyper <jameskuyper@verizon.net> - 2012-10-26 22:50 -0400
                                  Re: terminal designed for C Keith Thompson <kst-u@mib.org> - 2012-10-27 01:42 -0700
                                    Re: terminal designed for C James Kuyper <jameskuyper@verizon.net> - 2012-10-27 19:18 -0400
                                    Re: terminal designed for C Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-17 10:48 -0800
                                      Re: terminal designed for C Keith Thompson <kst-u@mib.org> - 2012-12-17 12:27 -0800
                                        Re: terminal designed for C James Kuyper <jameskuyper@verizon.net> - 2012-12-17 15:51 -0500
                                          Re: terminal designed for C Keith Thompson <kst-u@mib.org> - 2012-12-17 13:35 -0800
                                            Re: terminal designed for C James Kuyper <jameskuyper@verizon.net> - 2012-12-17 16:48 -0500
                                        Re: terminal designed for C Robert Wessel <robertwessel2@yahoo.com> - 2012-12-17 14:53 -0600
                                        Re: terminal designed for C Keith Thompson <kst-u@mib.org> - 2012-12-17 13:20 -0800
                                        Re: terminal designed for C Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-20 10:19 -0800
                        Re: terminal designed for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-27 02:35 +0100
                          Re: terminal designed for C kerravon <kerravon@w3.to> - 2012-10-26 18:58 -0700
                            Re: terminal designed for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-10-27 05:01 +0100
                          Re: terminal designed for C Robert Wessel <robertwessel2@yahoo.com> - 2012-10-27 00:56 -0500
                    Re: terminal designed for C James Kuyper <jameskuyper@verizon.net> - 2012-10-26 09:03 -0400
                    Re: terminal designed for C Keith Thompson <kst-u@mib.org> - 2012-10-26 11:13 -0700
                      Re: terminal designed for C kerravon <kerravon@w3.to> - 2012-10-26 15:15 -0700
              Re: terminal designed for C lawrence.jones@siemens.com - 2012-11-12 18:08 -0500
    Re: terminal designed for C falk@rahul.net (Edward A. Falk) - 2012-10-24 17:29 +0000
    Re: terminal designed for C Keith Thompson <kst-u@mib.org> - 2012-10-24 11:55 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#27675

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?
Was there a seance?

> when I saw them write "there is no
> escape in EBCDIC",

     Where did X3J11, or any other C-involved Committee, write
any such thing?

> but I think the letter might have got
> lost as I still haven't received a reply.

     You'll probably wait a long time for a reply from the
Committee Afterlife, especially for a reply to someone who
starts from contrary-to-fact claims.

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#27695

On Friday, October 26, 2012 12:04:49 AM UTC+11, Eric Sosman wrote:
> On 10/25/2012 12:09 AM, kerravon wrote:
> 
> > when I saw them write "there is no
> > escape in EBCDIC",
> 
>      Where did X3J11, or any other C-involved Committee, write
> any such thing?

The C89 Committee considered proposals to add the character constant '\e' to represent the
ASCII ESC ('\033') character. This proposal was based upon the use of ESC as the initial
character of most control sequences in common terminal driving disciplines such as ANSI
X3.64. However, this usage has no obvious counterpart in other popular character codes such as
EBCDIC.


That's where they wrote it - in the ANSI rationale.

As to it actually being used to drive terminals - why
on earth would that be necessary? Just because a
PANSY terminal has not been created in real life
(because IBM quite correctly decided that there
would be less CPU impact if terminals operated in
block mode) doesn't mean that a PANSY terminal
couldn't have been created the following week.
This has nothing to do with EBCDIC not having an
escape. It was purely because only mainframes
were using EBCDIC, and it so happens that only
mainframes were serious enough machines that they
didn't drive terminals directly like that.

In addition, the standard full-screen TPUT begins 
with hex 02,27,ccw,wcc,orders/text...
where the 27 is an escape!


BFN.  Paul.

[toc] | [prev] | [next] | [standalone]

#27697

On 10/25/2012 5:11 PM, kerravon wrote:
> On Friday, October 26, 2012 12:04:49 AM UTC+11, Eric Sosman wrote:
>> On 10/25/2012 12:09 AM, kerravon wrote:
>>
>>> when I saw them write "there is no
>>> escape in EBCDIC",
>>
>>       Where did X3J11, or any other C-involved Committee, write
>> any such thing?
>
> The C89 Committee considered proposals to add the character constant '\e' to represent the
> ASCII ESC ('\033') character. This proposal was based upon the use of ESC as the initial
> character of most control sequences in common terminal driving disciplines such as ANSI
> X3.64. However, this usage has no obvious counterpart in other popular character codes such as
> EBCDIC.
>
> That's where they wrote it - in the ANSI rationale.

     Yes, I know about the Rationale: I quoted this exact same
passage in a reply to you a couple days ago.  But where does
this say "there is no escape in EBCDIC?"

-- 
Eric Sosman
esosman@comcast-dot-net.invalid

[toc] | [prev] | [next] | [standalone]

#27711

On Friday, October 26, 2012 8:29:49 AM UTC+11, Eric Sosman wrote:
> On 10/25/2012 5:11 PM, kerravon wrote:
> 
> > The C89 Committee considered proposals to add the character constant '\e' to represent the
> > ASCII ESC ('\033') character. This proposal was based upon the use of ESC as the initial
> > character of most control sequences in common terminal driving disciplines such as ANSI
> > X3.64. However, this usage has no obvious counterpart in other popular character codes such as
> > EBCDIC.
> 
> > That's where they wrote it - in the ANSI rationale.
> 
>      Yes, I know about the Rationale: I quoted this exact same
> passage in a reply to you a couple days ago.  But where does
> this say "there is no escape in EBCDIC?"

They didn't use those exact words, but that is what
is implied. Perhaps you can use your own words,
speaking on behalf of a sane X3J11, why \e was not
provided as part of C89?

Thanks.  Paul.

[toc] | [prev] | [next] | [standalone]

#27714

kerravon <kerravon@w3.to> writes:

> On Friday, October 26, 2012 8:29:49 AM UTC+11, Eric Sosman wrote:
>> On 10/25/2012 5:11 PM, kerravon wrote:
>> 
>> > The C89 Committee considered proposals to add the character constant '\e' to represent the
>> > ASCII ESC ('\033') character. This proposal was based upon the use of ESC as the initial
>> > character of most control sequences in common terminal driving disciplines such as ANSI
>> > X3.64. However, this usage has no obvious counterpart in other popular character codes such as
>> > EBCDIC.
>> 
>> > That's where they wrote it - in the ANSI rationale.
>> 
>>      Yes, I know about the Rationale: I quoted this exact same
>> passage in a reply to you a couple days ago.  But where does
>> this say "there is no escape in EBCDIC?"
>
> They didn't use those exact words, but that is what
> is implied.

Maybe, in the heat of your determination that something is very wrong
here, you just misread the paragraph?  It says that it is "this usage"
not "this character" that has not obvious counterpart in EBCDIC.

Now that may be wrong, but it is certainly consistent with what little I
remember about how IBM terminal equipment was driven.  Maybe there is a
document you can point to that shows EBCDIC ESC (or, indeed, some other
character) being used as a control sequence prefix?

If you read section 5.2.2 of the C standard, it's clear that the
committee wants to reserve \X sequences for characters that serve some
clearly definable purpose.  I am not sure that even ASCII ESC fits this
limited criterion since its role is rather vague, but that alone did not
seem to the main reason for rejecting \e.

> Perhaps you can use your own words,
> speaking on behalf of a sane X3J11, why \e was not
> provided as part of C89?

I don't see why this is such a big issue.  Porting a display editor from
one environment to another is going to involve a considerable amount
re-writing.  Having to define the value of ESC is going to be the most
trivial part of it, is it not?

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#27738

On Friday, October 26, 2012 10:35:09 PM UTC+11, Ben Bacarisse wrote:
> kerravon <kerravon@w3.to> writes:
> 
> 
> 
> > On Friday, October 26, 2012 8:29:49 AM UTC+11, Eric Sosman wrote:
> 
> >> On 10/25/2012 5:11 PM, kerravon wrote:
> 
> >> 
> 
> >> > The C89 Committee considered proposals to add the character constant '\e' to represent the
> >> > ASCII ESC ('\033') character. This proposal was based upon the use of ESC as the initial
> >> > character of most control sequences in common terminal driving disciplines such as ANSI
> >> > X3.64. However, this usage has no obvious counterpart in other popular character codes such as
> >> > EBCDIC.
> 
> >> > That's where they wrote it - in the ANSI rationale.
> 
> >>      Yes, I know about the Rationale: I quoted this exact same
> >> passage in a reply to you a couple days ago.  But where does
> >> this say "there is no escape in EBCDIC?"
> 
> > They didn't use those exact words, but that is what
> > is implied.
> 
> Maybe, in the heat of your determination that something is very wrong
> here, you just misread the paragraph?

I don't think so. I've read it multiple times and I'm
a native English speaker, and it implies to me that
they're looking for an escape character in EBCDIC that
would do the equivalent of the ASCII version.

> It says that it is "this usage"
> not "this character" that has not obvious counterpart in EBCDIC.
> 
> Now that may be wrong, but it is certainly consistent with what little I
> remember about how IBM terminal equipment was driven.  Maybe there is a
> document you can point to that shows EBCDIC ESC (or, indeed, some other
> character) being used as a control sequence prefix?

1. I don't think it should be necessary for equipment
marketted by IBM to actually *use* the clearly-defined
control character. The actual *use* of \e is determined
by some coincidental marketing factors such as:

A. Is EBCDIC used on mainframes or PCs?
B. Are character-mode terminals efficient use of scarce
mainframe cycles?

2. Here's what a mainframe expert said:

If you look at BTAM, TCAM, or VTAM, you'll note that 
many terminal types use escape. In particular, the standard 
full-screen TPUT begins with hex 02,27,ccw,wcc,orders/text... 
where the 27 is an escape!

3. Here's what the IBM manual says:

http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/IKJ2B703/10.2?SHELF=&DT=19930804072754&CASE=

1.  If the first character in your message is an escape control
character (X'27'), the two characters following it are treated as
a command code and as a write control character by the 3270.  Note
that the command code should always be for a remote 3270.  If
necessary, TPUT will convert the code to that for a local 3270.
If the first character is not an escape character, a default write
command and a write control character are added to the beginning
of the message.  Any attachment-dependent characters required for
correct transmission of the data stream are provided by the access
method.

> I don't see why this is such a big issue.  Porting a display editor from
> one environment to another is going to involve a considerable amount
> re-writing.  Having to define the value of ESC is going to be the most
> trivial part of it, is it not?

If micro-emacs cannot be written portably, for some
yet-to-be-explained technical reason, then my Plan
B is to write a replacement for micro-emacs that can
theoretically be ported, even if I need to change/
invent new hardware and change every operating system
to cope with my use of the C language.

I note that the MSDOS "edlin" program appears to be
the sort of thing that is portable. So why not an
editor that is better that edlin? Why is edlin the
limit?

BFN.  Paul.

[toc] | [prev] | [next] | [standalone]

#27740

kerravon <kerravon@w3.to> writes:
[...]
> If micro-emacs cannot be written portably, for some
> yet-to-be-explained technical reason, then my Plan
> B is to write a replacement for micro-emacs that can
> theoretically be ported, even if I need to change/
> invent new hardware and change every operating system
> to cope with my use of the C language.

Or you can write your C code so that it can be configured to use
either the ASCII escape character or the EBCDIC escape character.
It may not be an ideal solution, but I'm at a loss to understand
why you think inventing new hardware is better.

> I note that the MSDOS "edlin" program appears to be
> the sort of thing that is portable. So why not an
> editor that is better that edlin? Why is edlin the
> limit?

Micro-emacs requires the ability to read single characters from
the keyboard without waiting for an end-of-line character (unless
you radically change the user experience).  That cannot be done
in 100% portable C (though it's typically straightforward to do in
non-portable C).

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <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"

[toc] | [prev] | [next] | [standalone]

#27742

On Saturday, October 27, 2012 11:11:31 AM UTC+11, Keith Thompson wrote:
> kerravon <kerravon@w3.to> writes:
> 
> Or you can write your C code so that it can be configured to use
> either the ASCII escape character or the EBCDIC escape character.
> It may not be an ideal solution, but I'm at a loss to understand
> why you think inventing new hardware is better.

I am transfixed with the C90 standard, and expect the
world to revolve around that, than vice-versa.

> > I note that the MSDOS "edlin" program appears to be
> > the sort of thing that is portable. So why not an
> > editor that is better that edlin? Why is edlin the
> > limit?
> 
> Micro-emacs requires the ability to read single characters from
> the keyboard without waiting for an end-of-line character (unless
> you radically change the user experience).  That cannot be done
> in 100% portable C (though it's typically straightforward to do in
> non-portable C).

Instead of getting carried away with saying that the
C90 standard can be interpreted differently by different
operating systems, let's instead posit that the
operating systems will instead interpret the C90
standard the same way - with everyone interested in
the purity of the C90 standard.

Under those circumstances, I am quite happy to define
stdin and stdout as _IONBF which should get the
desired character-at-a-time return.

The fact that existing terminal hardware needs to be
replaced in order for this to work is to me a minor
concern. My major concern is whether I can code
according to the C90 specs and have a DECENT operating
system do something DECENT.

BFN.  Paul.

[toc] | [prev] | [next] | [standalone]

#27744

On 10/27/12 13:27, kerravon wrote:
>
> The fact that existing terminal hardware needs to be
> replaced in order for this to work is to me a minor
> concern. My major concern is whether I can code
> according to the C90 specs and have a DECENT operating
> system do something DECENT.

I would expect a decent contemporary operating system to follow C99...

-- 
Ian Collins

[toc] | [prev] | [next] | [standalone]

#27745

On Saturday, October 27, 2012 11:39:28 AM UTC+11, Ian Collins wrote:
> On 10/27/12 13:27, kerravon wrote:
> 
> > concern. My major concern is whether I can code
> > according to the C90 specs and have a DECENT operating
> > system do something DECENT.
> 
> I would expect a decent contemporary operating system to follow C99...

In order to do C99, C90 has to be covered as well. I'll
settle for the universality of decent interpretations
of C90.

BFN.  Paul.

[toc] | [prev] | [next] | [standalone]

#27748

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.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#27752

James Kuyper <jameskuyper@verizon.net> 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.  (The following is of no particular
practical use or relevance to the current discussion.)

For example, this:

    int main(void) {
        int restrict;
        return 0;
    }

is a strictly conforming C90 program, but a syntax error in C99.
But the standard only requires a diagnostic for a syntax error
or constraint violation; the compiler could issue a diagnostic
and then translate the program as if it were a C90 compiler.
(Extra diagnostics are permitted.)  It could behave similarly in
the other direction for things like implicit int.

It would have to define __STDC_VERSION__ as 199901L for C99
conformance; C90 doesn't explicitly forbid that, since it doesn't
mention __STDC_VERSION__.  (This makes a compiler that conforms to both
C99 and C11 impossible, I think.)

I hope nobody actually does this.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <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"

[toc] | [prev] | [next] | [standalone]

#27782

On 10/27/2012 04:42 AM, Keith Thompson wrote:
> James Kuyper <jameskuyper@verizon.net> 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.  (The following is of no particular
> practical use or relevance to the current discussion.)
> 
> For example, this:
> 
>     int main(void) {
>         int restrict;
>         return 0;
>     }
> 
> is a strictly conforming C90 program, but a syntax error in C99.
> But the standard only requires a diagnostic for a syntax error
> or constraint violation; the compiler could issue a diagnostic
> and then translate the program as if it were a C90 compiler.
> (Extra diagnostics are permitted.)  It could behave similarly in
> the other direction for things like implicit int.

For each version of the standard, you can say one of the following about
any particular piece of code:
1. The range of permitted behavior for the code is specified by the
standard; as a special case of this, there might be only one permitted
behavior.
2. The standard mandates the issuance of at least one diagnostic.
3. The behavior of the code is undefined by the standard.
4. The standard prohibits successful translation of the program.

As far as I can remember (never having had an official copy of the C90
standard), most of the differences between C90 and C99 shifted code from
one of those categories to another. Most of those categories are
compatible with each other, except that category 1 is incompatible with
category 4. There's only one construct in category 4: a #error directive
that survives conditional compilation. That was not in category 1 for
C90, so the fact that it's in category 4 for C99 does not prevent
simultaneous conformance.

There's only one other thing that could prevent simultaneous
conformance: behavior that is in category 1 according to both standards,
but where the range of behavior permitted by C90 doesn't overlap the
range permitted by C99. For C99 and C2011, one such case is the one you
mentioned, involving the value of __STDC_VERSION__. I couldn't come up
with any examples of such a difference between C90 and C99 - but I don't
feel confident in claiming that there are no such differences.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#29414

Keith Thompson <kst-u@mib.org> writes:

> James Kuyper <jameskuyper@verizon.net> 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.

[toc] | [prev] | [next] | [standalone]

#29421

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> James Kuyper <jameskuyper@verizon.net> 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) kst-u@mib.org  <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"

[toc] | [prev] | [next] | [standalone]

#29422

On 12/17/2012 03:27 PM, Keith Thompson wrote:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> James Kuyper <jameskuyper@verizon.net> 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>?

[toc] | [prev] | [next] | [standalone]

#29428

James Kuyper <jameskuyper@verizon.net> 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) kst-u@mib.org  <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"

[toc] | [prev] | [next] | [standalone]

#29430

On 12/17/2012 04:35 PM, Keith Thompson wrote:
> James Kuyper <jameskuyper@verizon.net> 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.

[toc] | [prev] | [next] | [standalone]

#29423

On Mon, 17 Dec 2012 12:27:11 -0800, Keith Thompson <kst-u@mib.org>
wrote:

>Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> James Kuyper <jameskuyper@verizon.net> 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.


The classic single-line comment problem from C++ works for C99 as
well:

a = b //* comment */
-c;

In C90, that subtracts c from b, in C++ and C99 it divides b by the
negative of c;

[toc] | [prev] | [next] | [standalone]

#29425

Keith Thompson <kst-u@mib.org> writes:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> Keith Thompson <kst-u@mib.org> writes:
>>> James Kuyper <jameskuyper@verizon.net> 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) kst-u@mib.org  <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"

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web