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 3 of 3 — ← Prev page 1 2 [3]

#29532

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.

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

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

#27746

kerravon <kerravon@w3.to> writes:

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

Right.  We are both reading the rationale the same way now.  This is not
the same as "there is no escape in EBCDIC".

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

That seems a little too specific to be classed as a similar usage, but I
don't have the knowledge to evaluate it properly.  If (and I think it's
a big if) this usage is almost universal among EBCDIC display devices
then I'd agree that the committee could have treated the two escapes as
having similar usage.
 
>> 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.

That's a very odd statement.  My notion of portable software is software
that does not require new hardware and re-written operating systems to
run.  In what sense would your editor be portable if I could not run it
without installing your changed OS and your newly invented hardware?

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

It isn't any kind of limit.  For one thing edlin is not universally
portable -- I doubt it would have been possible to get anything even
remotely similar to run on the IBM RAX system that I first used.

Portability is a relative property not an absolute one.  How portable do
you want your software to be[1] and to what systems?  Once you have that
pinned down you can investigate the lowest common denominator of those
systems to see what you have to work with.

As Keith has pointed out, C alone does not give you enough to get very
far at all.  Just getting un-buffered input requires more that C
provides, and controlling all the different terminal hardware out there
is well nigh impossible.

[1] By "how portable do you want your software to be" I mean, for
example, do you want exactly the same source to build and run on all
your targets, or will you accept some small effort of conversion?  Will
you accept different build systems provided the source is unchanged?
and so on.

-- 
Ben.

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

#27747

On Saturday, October 27, 2012 12:35:06 PM UTC+11, Ben Bacarisse wrote:
> > 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.
> 
> That's a very odd statement.  My notion of portable software is software
> that does not require new hardware and re-written operating systems to
> run.  In what sense would your editor be portable if I could not run it
> without installing your changed OS and your newly invented hardware?

Good question. I want to posit the existence of a
rectangular screen that follows the ANSI X3.64
specs, adjusted for character set differences. That
ties down the screen hardware. In order to follow
the ANSI X3.64 specs I need the operating system
to be able to address the terminal appropriately.
That ties down the operating system.

Other than that, the C90 language gives the flexibility
to address such a real/theoretical terminal. It does
indeed allow unbuffered input/output. I consider it to
be the operating system's job to respond to the C90
request for unbuffered input/output. I only expect my
software to be portable to hardware that meets the
X3.64 standard and operating systems that respond
logically to the unbuffered input/output requests.
I don't expect my source code to change.

Thankyou for helping me to pin down my unstated assumptions.

BFN.  Paul.

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

#27750

kerravon <kerravon@w3.to> writes:

> On Saturday, October 27, 2012 12:35:06 PM UTC+11, Ben Bacarisse wrote:
>> > 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.
>> 
>> That's a very odd statement.  My notion of portable software is software
>> that does not require new hardware and re-written operating systems to
>> run.  In what sense would your editor be portable if I could not run it
>> without installing your changed OS and your newly invented hardware?
>
> Good question. I want to posit the existence of a
> rectangular screen that follows the ANSI X3.64
> specs, adjusted for character set differences. That
> ties down the screen hardware. In order to follow
> the ANSI X3.64 specs I need the operating system
> to be able to address the terminal appropriately.
> That ties down the operating system.

That's got very little to do with the OS -- all it has to do is send a
character stream to the terminal.  You'll probably be *removing*
portability from MircoEmacs to do this since I imagine it can drive
other terminal types as well as ANSI X3.64 ones.

Will you consider terminal emulators?  These may have curious properties
such as the ability to change size during program execution.

> Other than that, the C90 language gives the flexibility
> to address such a real/theoretical terminal. It does
> indeed allow unbuffered input/output.

Not in the way you want.  You can set some stream-level buffering but
you can't get at the line-buffering that most OSes put between your
keyboard and the program.  How easy or hard it is to alter this will
vary from system to system.

Once you've done that you need to consider what the OS gives you.  It
might simply provide raw scan codes or it may give you something
higher-level like a stream of processed bytes (maybe even processed
characters -- e.g. turning dead-key combinations into accented
characters).  Whatever it does, MicroEmacs will probably need much more
than a plain character stream.  Full Emacs needs to be able to tell what
modifiers are pressed so you can distinguish between ctrl-x and
ctrl-alt-x and so on.  MicroEmacs is probably similar.

> I consider it to
> be the operating system's job to respond to the C90
> request for unbuffered input/output. I only expect my
> software to be portable to hardware that meets the
> X3.64 standard and operating systems that respond
> logically to the unbuffered input/output requests.

X3.64 does not address the input side.

> I don't expect my source code to change.
> Thankyou for helping me to pin down my unstated assumptions.

There are some file system issues as well.  C's file handling is very
basic so most editors will use OS features directly.

-- 
Ben.

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

#27751

On Sat, 27 Oct 2012 02:35:05 +0100, Ben Bacarisse
<ben.usenet@bsb.me.uk> wrote:

>kerravon <kerravon@w3.to> writes:
>
>> 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.
>
>Right.  We are both reading the rationale the same way now.  This is not
>the same as "there is no escape in EBCDIC".
>
>>> 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.
>
>That seems a little too specific to be classed as a similar usage, but I
>don't have the knowledge to evaluate it properly.  If (and I think it's
>a big if) this usage is almost universal among EBCDIC display devices
>then I'd agree that the committee could have treated the two escapes as
>having similar usage.
> 
>>> 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.
>
>That's a very odd statement.  My notion of portable software is software
>that does not require new hardware and re-written operating systems to
>run.  In what sense would your editor be portable if I could not run it
>without installing your changed OS and your newly invented hardware?


It's not.  It's strictly an artifact of the TPUT/TGET API for talking
to a terminal in TSO (and not in other environments).  The ESC never
shows up on the line - it basically tells TPUT that the calling
program has supplied the required write command and write control
character (which is only applicable for a 3270 device), and TSO should
not deal with the message generically.

TSO, for example, pretty much assumes either a line mode or block mode
terminal, and has approximately no support for a character mode
terminal, except via some emulation further down in the stack which
can emulate a line mode terminal with a character mode terminal.

Other traditional mainframe environments are broadly similar.


>> 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?
>
>It isn't any kind of limit.  For one thing edlin is not universally
>portable -- I doubt it would have been possible to get anything even
>remotely similar to run on the IBM RAX system that I first used.


You could do an edlin-style editor in TSO, in fact TSO EDIT is just
that.  A session might look like this:

edit 'a0370cf.project.source(file)'  (note: TSO command starts EDIT)
top  (note: commands issued to EDIT)
down 3
insert NEW LINE TO BE INSERTED
exit save

The problem with doing better than that is that TSO doesn't have any
real support for driving a character mode terminal.

Even block mode terminals are a bit of a hack, witness the ESC
silliness needed when talking to one.  TSO will run a block mode
terminal in line mode until an application switches it to block mode,
and there are oddities with that - for example, a 3270 doesn't scroll,
so when TSO gets to the bottom of the screen, he'll toss up a "***",
at which point you need to hit enter so that he'll clear the screen
and start writing additional lines from the top of the (now empty)
screen.


>Portability is a relative property not an absolute one.  How portable do
>you want your software to be[1] and to what systems?  Once you have that
>pinned down you can investigate the lowest common denominator of those
>systems to see what you have to work with.
>
>As Keith has pointed out, C alone does not give you enough to get very
>far at all.  Just getting un-buffered input requires more that C
>provides, and controlling all the different terminal hardware out there
>is well nigh impossible.


Indeed, line oriented systems line TSO make the notion of a unbuffered
terminal with characters necessary to write a emacs-like editor almost
impossible.


>[1] By "how portable do you want your software to be" I mean, for
>example, do you want exactly the same source to build and run on all
>your targets, or will you accept some small effort of conversion?  Will
>you accept different build systems provided the source is unchanged?
>and so on.

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

#27723

On 10/26/2012 06:33 AM, kerravon wrote:
> 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.

No, that is not what is implied. They did not say that there is no
escape in EBCDIC. They were talking about "this usage", referring to
"use of ESC as the initial character of most control sequences in common
terminal driving disciplines", when they said that it "has no obvious
counterpart in ... EBCDIC."

Everyone here who has claimed more experience than I have in EBCDIC
(which is a trivial requirement to meet) has said that the EBCDIC ESC
character is NOT so used.  Could you prove them wrong by identifying any
"common terminal driving discipline" where  "most control sequences"
have EBCDIC ESC as "the initial character"? You've talked about a
discipline for a hypothetical terminal which doesn't actually exist yet,
but a non-existent one could hardly qualify as "common", could it?
Standards are written primarily to standardize existing practice, so
whether or not a practice is "common", or even "existing" is certainly
one of the things the committee is supposed to take into consideration
when making its decisions.
-- 
James Kuyper

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

#27734

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. Perhaps you can use your own words,
> speaking on behalf of a sane X3J11, why \e was not
> provided as part of C89?

Ben and James have already pointed out that that's not what the
rationale says or implies.

I understand you'd like the language to support '\e' (I wouldn't
mind it myself, and there's precedent in Perl).  But the fact is that
it doesn't.  The reasons have already been explained to some extent.
Would understanding the reasons in a bit more detail really help
you in any way?

My suggestion: Consider the amount of effort that would be
required to add a '\e' escape to the C standard, for *all* compiler
implementers to implement it, and for the change to be tested and
deployed widely enough for you to use it.  Compare this to the
amount of effort required to write:

    #ifdef EBCDIC
    #define ESCAPE '\x27'
    #else
    #define ESCAPE '\x1b'
    #endif

Ok, I know that the difficulty of typing those lines is not really
the issue; you're more concerned with being able to express the
escape character portably.  But IMHO it's really not that big a deal.
If you want a language in which all concepts can be expressed 100%
portably, you're looking for something other than 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]

#27737

On Saturday, October 27, 2012 5:13:26 AM UTC+11, Keith Thompson wrote:
> kerravon <kerravon@w3.to> writes:
> 
> If you want a language in which all concepts can be expressed 100%
> portably, you're looking for something other than C.

It's more I'm asking the question - what concepts are
inherently portable, and given that, can I express
that in C? E.g. one of the things that drove me to
work on GCCMVS for years was the basic principle that
at its heart, GCC took in a bunch of text files (C
code), and output another text file (assembler code),
and something is very wrong if text file to text file
is not portable, ie won't run on an EBCDIC mainframe.

BFN.  Paul.

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

#28237

Eric Sosman <esosman@comcast-dot-net.invalid> 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

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

#27637

In article <90bcf5bb-f8e9-4ea2-9cbe-82110bfd059c@googlegroups.com>,
kerravon  <kerravon@w3.to> wrote:
>Hello folks.
>
>According to the 1990 C standard (which is what I wish to code to), there is no "escape"
>character. So the only way to produce an escape character is to harcode its ASCII or
>EBCDIC value (x'1b'/x'27' respectively). I don't like doing that. I want to be able to
>write an editor like micro-emacs without having to have an #ifdef EBCDIC.

The 60's just called, and they want their technology back.  Wait, no,
they say you can keep it.

Seriously?  I could hardly follow that, but it looked like you want
to redefine the ASCII control characters to support some sort of
EBCDIC compatibility.

-- 
	-Ed Falk, falk@despams.r.us.com
	http://thespamdiaries.blogspot.com/

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

#27643

kerravon <kerravon@w3.to> writes:
> According to the 1990 C standard (which is what I wish to code to),
> there is no "escape" character. So the only way to produce an escape
> character is to harcode its ASCII or EBCDIC value (x'1b'/x'27'
> respectively). I don't like doing that. I want to be able to write an
> editor like micro-emacs without having to have an #ifdef EBCDIC.
[...]

One of C's greatest strengths it the ability to use it to write
*non-portable* code.

If you need to use the ASCII Escape character, just write:

    #define ESCAPE '\x1b'

If you need the EBCDIC Escape character (assuming that it's actually
useful, and that EBCDIC defines it usefully):

    #define EBCDIC_ESCAPE '\x27'

If you need one or the other, depending on the environment, this might
work:

    #if '0' == 48
    #define ESCAPE '\x1b' /* ASCII */
    #else
    #define ESCAPE '\x27' /* EBCDIC */
    #endif

except that, according to N1370 6.10.1p4:

    Whether the numeric value for these character constants matches
    the value obtained when an identical character constant occurs
    in an expression (other than within a #if or #elif directive)
    is implementation-defined.

If it works for the compiler(s) you're using, that's probably good
enough.  If not, you'll need to find some other way to determine whether
the target uses ASCII or EBCDIC.

>                I don't like doing that. I want to be able to write an
> editor like micro-emacs without having to have an #ifdef EBCDIC.

My advice: grit your teeth and write "#ifdef EBCDIC".  Portable code is
good, all else being equal -- but in this case all else is not equal.

-- 
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] | [standalone]

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

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

csiph-web