Hyman Rosen <hymie@prolifics.com> writes:
> You said that implementors would be relying on outside information;
> that would generally preclude defining \t as \x7f.

Yes - *if* the standard were to say nothing more than "\t is \t".

> In any case, C++ shows how to define it minimally and correctly:
>
>  horizontal tab HT \t

That's not minimal.  The phrase "horizontal tab" suggests a certain
display effect, which is what Paul DeRocco wanted to avoid.


paul
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paul Jarc <prj@po.cwru.edu> writes:
> Actually, I wasn't asking you, I was asking Paul DeRocco.  He's the
> one who said that \t, etc., are overspecified.  But you would be
> satisfied with an implementation that made '\7f'=='\t', even on an
> ASCII platform?  It's a QoI issue, even with the present wording, but
> recommending a certain display action for \t makes it more likely to
> be implemented the way users expect.  We don't have to rely on market
> pressure alone; we can rely on implementors' laziness too.

You said that implementors would be relying on outside information;
that would generally preclude defining \t as \x7f. In any case, C++
shows how to define it minimally and correctly:

 horizontal tab HT \t
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paul Jarc <prj@po.cwru.edu> writes:
> But you do want the language to give you a way to say "this is a tab
> character" (i.e., '\t').  But you also want the language to have no
> concept of what that character is.  If the only thing the language
> says about \t is that it is \t, then implementors have to rely on
> information coming from outside the standard to find out what that
> means and how it should be implemented.  If that's unavailable, any
> arbitrary character could serve equally well as \t, as far as the
> implementor knows.  Is this what you want?

Yes! Now you understand!
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Paul D. DeRocco" <pderocco@ix.netcom.com> writes:
> Paul Jarc <prj@po.cwru.edu> wrote
> > So what would you have the standard say about \t?  If all you say is
> > that it's passed on to the host system, then you have no information
> > unique to \t - most all characters are passed on to the host system as
> > well, so this doesn't distinguish \t.  As far as you'd know, it could
> > be a yen sign.  OTOH, if you even so much as refer to \t as
> > "horizontal tab", then you are implicitly recommending a particular
> > display effect.  I don't see any middle ground for you to stand on.
>
> I don't see what the difficulty is. When I write code to generate, say, a
> Note On message to a MIDI device, I do so because _I_ know the bytes are
> going to a MIDI device. I don't expect the C++ language to know or care
> about it. When I write a tab character to something, it's because _I_ know
> that that character has a particular meaning to the thing I'm writing it to,
> and I don't expect the C++ language to have anything to do with it.

But you do want the language to give you a way to say "this is a tab
character" (i.e., '\t').  But you also want the language to have no
concept of what that character is.  If the only thing the language
says about \t is that it is \t, then implementors have to rely on
information coming from outside the standard to find out what that
means and how it should be implemented.  If that's unavailable, any
arbitrary character could serve equally well as \t, as far as the
implementor knows.  Is this what you want?

If, OTOH, the standard says anything at all beyond "\t is \t", then at
the very least it implicitly recommends a certain meaning for that
character.  One might argue that even \t alone is enough to do that.


paul
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paul Jarc <prj@po.cwru.edu> wrote

> So what would you have the standard say about \t?  If all you say is
> that it's passed on to the host system, then you have no information
> unique to \t - most all characters are passed on to the host system as
> well, so this doesn't distinguish \t.  As far as you'd know, it could
> be a yen sign.  OTOH, if you even so much as refer to \t as
> "horizontal tab", then you are implicitly recommending a particular
> display effect.  I don't see any middle ground for you to stand on.

I don't see what the difficulty is. When I write code to generate, say, a
Note On message to a MIDI device, I do so because _I_ know the bytes are
going to a MIDI device. I don't expect the C++ language to know or care
about it. When I write a tab character to something, it's because _I_ know
that that character has a particular meaning to the thing I'm writing it to,
and I don't expect the C++ language to have anything to do with it.

Newline, in my view, is different, because we need a completely portable
means of separating lines, for doing basic two-dimensional (rows and
columns) text-based processing. That makes it appropriate for the C or C++
standard to define that line separation shall be done (or appear to be done,
within the program) by a single \n character.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Clive D.W. Feather" <clive@on-the-train.demon.co.uk> writes:
> Depends what you mean by "is ASCII". It uses the same assignments for
> codes 32 to 126 that ASCII does. Is that "is ASCII" ?

The definition of \e on a given platform should be unsurprising to
users of that platform. This is because the compiler is a tool that
people use to get their work done, not a clever adversary which
thwarts them at every turn.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"T.E.Dickey" <dickey@shell.clark.net> writes:
> a dumb printing terminal does this (backspace, tab, bell, carriage return,
> line feed - even form feed for some of the fancier models in the 60's and
> early 70's).  did I leave one out?

\v


paul
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Larry Jones wrote:
>
> Clive D.W. Feather (clive@on-the-train.demon.co.uk) wrote:
> >
> > I don't have any parts of ISO 8859 to hand, but I seem to recall
> > that it didn't have any control codes in at all.
>
> That's because it's explicitly a *graphic* character set standard --
> it notes that control characters are out of its scope and are
> specified by other standards such as 646 and 6429.

That's how I remember it.  Assuming that ISO-8859-1 is meant to
extend ASCII with 8-bit characters, it would seem reasonable to
assume that the control codes (specifically, codes 0x00-0x1F, 0x7F,
and 0x80-0x9F) are unaffected.

Speaking of ISO-8859-n, I've pointed out in the past that C
implementations that treat plain 'char' as 'signed char' have a
problem with character codes beyond '\x7F' due to sign extension.

-- David R. Tribble, david@tribble.com, http://www.david.tribble.com --
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <Rn8L3.1258$N64.35957@dfw-read.news.verio.net>,
T.E.Dickey <dickey@shell.clark.net> wrote:
>In comp.std.c Paul D. DeRocco <pderocco@ix.netcom.com> wrote:
>
>> To be fair, how am I incorrect? I responded as you did, that all those
>> character sets are variants of ASCII. I'm still itching for someone to
>> inform me of some character set, that is in actual use, on a machine for
>> which one might realistically implement C++, that has no concept of an
>> escape character, yet that has all the other control characters for which
>> there are backslash constructs.
>
>a dumb printing terminal does this (backspace, tab, bell, carriage return,
>line feed - even form feed for some of the fancier models in the 60's and
>early 70's).  did I leave one out?
>
>escape characters in that sort of device didn't show up until vendors
>started adding things like variable pitch.

The set of characters implemented by paper tape and serial line
devices was extremely variable.  Carriage return and line feed
(or occasionally a composite newline character) were the only
invariants.  Most had tab and bell, some had form feed, and quite
a lot had a vertical tab or an escape character of some form.

Please note that the character that I am referring to as A vertical
tab did not always have the ASCII semantics - in particular, many
such devices did not have the concept of vertical tab stops, but
sometimes had oddball forms of line feeding (e.g. 3 line feeds, or
half spacing.)

When the vendors started to produce ASCII serial line devices (aka
terminals), many of them implemented only the ASCII characters
they wanted - which subset was at least as likely to include
escape as a vertical tab.  Then, as now, escape meant that you had
in the particular model's handbook for the effect.



Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email:  nmm1@cam.ac.uk
Tel.:  +44 1223 334761    Fax:  +44 1223 334679


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hyman Rosen <hymie@prolifics.com> writes:
> Paul Jarc <prj@po.cwru.edu> writes:
> > So what would you have the standard say about \t?  If all you say is
> > that it's passed on to the host system, then you have no information
> > unique to \t - most all characters are passed on to the host system as
> > well, so this doesn't distinguish \t.  As far as you'd know, it could
> > be a yen sign.  OTOH, if you even so much as refer to \t as
> > "horizontal tab", then you are implicitly recommending a particular
> > display effect.  I don't see any middle ground for you to stand on.
>
> The C++ standard says, in a table,
>
>  horizontal tab HT \t
>
> and that's it. C++ compiler implementors have been able to use this
> minimal specification to decide what to do with \t. When we add
>
>  escape  ESC \e
>
> they'll probably be able to handle that too.

Yes, I'm sure.  But I was responding to Paul DeRocco's saying that the
standard overspecifies the behavior of these control characters.  By
calling \t "horizontal tab", you implicitly recommend a certain
interpretation for it, which is what he wanted to avoid.


paul


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Clive D.W. Feather (clive@on-the-train.demon.co.uk) wrote:
>
> I don't have any parts of ISO 8859 to hand, but I seem to recall that it
> didn't have any control codes in at all.

That's because it's explicitly a *graphic* character set standard -- it
notes that control characters are out of its scope and are specified by
other standards such as 646 and 6429.

-Larry Jones

Any game without push-ups, hits, burns or noogies is a sissy game. -- Calvin


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37F12606.CE8D5879@tribble.com>, David R Tribble
<david@tribble.com> writes
>> That's funny: I must have imagined ISO 8859 part 1, part 2, part 3,
[...]
>Paul is incorrect, but to be fair, all of the character sets you
>mentioned are based on 7-bit ASCII, and all use the same codes for
>the first 33 control codes (including ESC, 0x1B).

I don't have any parts of ISO 8859 to hand, but I seem to recall that it
didn't have any control codes in at all.

--
Clive D.W. Feather    | Internet Expert      | Work: <clive@demon.net>
Tel: +44 20 8371 1138 | Demon Internet Ltd.  | Home: <clive@davros.org>
Fax: +44 20 8371 1037 |                      | Web:  <http://www.davros.org>
Written on my laptop; please observe the Reply-To address
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <t7yadorzzw.fsf@calumny.jyacc.com>, Hyman Rosen
<hymie@prolifics.com> writes
>> On such a system, 31 is arguably the correct value for \e given the
>> descriptions some people have proposed. I doubt that such an
>> implementation would be acceptable to those people, however.
>If the character set used by the system is ASCII, then the usual values
>should be assigned to the character escape sequences, including ESC for
>\e. If it isn't, then given the description, 31 would be the right choice.

Depends what you mean by "is ASCII". It uses the same assignments for
codes 32 to 126 that ASCII does. Is that "is ASCII" ?

--
Clive D.W. Feather    | Internet Expert      | Work: <clive@demon.net>
Tel: +44 20 8371 1138 | Demon Internet Ltd.  | Home: <clive@davros.org>
Fax: +44 20 8371 1037 |                      | Web:  <http://www.davros.org>
Written on my laptop; please observe the Reply-To address
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37F4E0F6.25B00169@physik.tu-muenchen.de>, Christopher
Eltschka <celtschk@physik.tu-muenchen.de> writes
>In the example above, 31 obviously _is_ the escape character.
>Therefore on that system, \e should translate to 31.
[...]
>I would also expect the imaginary system to translate
>the character 31 to the character 27 in the printer driver.

hy ? The printer driver doesn't translate anything else.

>And on systems with more than one escape character, people
>surely would also be happy with those control characters being
>spelled "\e1", "\e2", ...

Oh ? So is "\e1" one character or two (plus the terminating zero) ?

>Yes, those are two characters in the program which would be
>output as one character on the display device (or in text files).
>I don't see a problem with this.

What about all those "portable" programs that expect \e1 to send two
characters to the printer device ?

--
Clive D.W. Feather    | Internet Expert      | Work: <clive@demon.net>
Tel: +44 20 8371 1138 | Demon Internet Ltd.  | Home: <clive@davros.org>
Fax: +44 20 8371 1037 |                      | Web:  <http://www.davros.org>
Written on my laptop; please observe the Reply-To address
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37F1270D.EE9C32A9@tribble.com>, David R Tribble
<david@tribble.com> writes
>But if there exists a conforming C compiler for it, it must allocate
>at least 8 bits for each 'char' object; since ISO C only prescribes
>99 characters, there are at least 157 codes left to choose from.

Nitpick, you mean 28 codes (the members of the basic character set,
which \e would be, must be positive).

--
Clive D.W. Feather    | Internet Expert      | Work: <clive@demon.net>
Tel: +44 20 8371 1138 | Demon Internet Ltd.  | Home: <clive@davros.org>
Fax: +44 20 8371 1037 |                      | Web:  <http://www.davros.org>
Written on my laptop; please observe the Reply-To address
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37F925FD.173A3646@tribble.com>, David R Tribble
<david@tribble.com> writes
>What if most of the existing C compilers supported a \e sequence?
>Would the ISO committee consider adopting it into C9X for the reason
>of standardizing "existing practice"?  Or would they continue to
>ignore it, simply because it has been so difficult to devise
>"appropriate" wording in section 5.2.2?

If most existing compilers supported it, this would be an argument in
favour of adding it to the next revision of C.

--
Clive D.W. Feather    | Internet Expert      | Work: <clive@demon.net>
Tel: +44 20 8371 1138 | Demon Internet Ltd.  | Home: <clive@davros.org>
Fax: +44 20 8371 1037 |                      | Web:  <http://www.davros.org>
Written on my laptop; please observe the Reply-To address
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paul Jarc <prj@po.cwru.edu> writes:
> So what would you have the standard say about \t?  If all you say is
> that it's passed on to the host system, then you have no information
> unique to \t - most all characters are passed on to the host system as
> well, so this doesn't distinguish \t.  As far as you'd know, it could
> be a yen sign.  OTOH, if you even so much as refer to \t as
> "horizontal tab", then you are implicitly recommending a particular
> display effect.  I don't see any middle ground for you to stand on.

The C++ standard says, in a table,

 horizontal tab HT \t

and that's it. C++ compiler implementors have been able to use this
minimal specification to decide what to do with \t. When we add

 escape  ESC \e

they'll probably be able to handle that too.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Clive D.W. Feather" wrote:
>
> Pete Becker <petebecker@acm.org> writes
>> I disagree.  Having \e in the standard would give you a stick with
>> which to beat uncooperative vendors.
>
> >It's a rather short stick if it all it says is that it's
> >implementation-defined. It's even shorter, because no compiler vendor
> >will specify in detail what effect \e has
>
> It suddenly strikes me that the ASCII code "DLE" (16) probably has as
> good, if not better, claim to be "escape" than "ESC" (27). Certainly
> it matches every description I've seen posted so far.
>
> Can the pro-\e people explain why not ?

I won't answer that question, but instead I will ask another question:

What if most of the existing C compilers supported a \e sequence?
Would the ISO committee consider adopting it into C9X for the reason
of standardizing "existing practice"?  Or would they continue to
ignore it, simply because it has been so difficult to devise
"appropriate" wording in section 5.2.2?

-- David R. Tribble, david@tribble.com, http://www.david.tribble.com --
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Paul D. DeRocco" <pderocco@ix.netcom.com> writes:
> This is why I feel that control codes (other than newline) _should_ be
> passed on unchanged, leaving it to some other piece of code unspecified by
> the device driver to interpret them. The C or C++ standard, in my view, has
> no business defining _any_ control functions other than the ability to move
> to the beginning of the next line (and possibly to the beginning of the
> first line on the next page, although that's my own wish, not standard
> practice).

So what would you have the standard say about \t?  If all you say is
that it's passed on to the host system, then you have no information
unique to \t - most all characters are passed on to the host system as
well, so this doesn't distinguish \t.  As far as you'd know, it could
be a yen sign.  OTOH, if you even so much as refer to \t as
"horizontal tab", then you are implicitly recommending a particular
display effect.  I don't see any middle ground for you to stand on.


paul
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble <david@tribble.com> wrote in message
news:37F12606.CE8D5879@tribble.com...
>
> Clive D.W. Feather wrote:
> >
> > Paul D. DeRocco <pderocco@ix.netcom.com> writes:
> >> But I see no reason to bother with such hair-splitting, since there
> >> really are only two character sets (that use one-byte values, and for
> >> which anyone will attempt to write a standard-conforming C++
> >> compiler), and they both have escape characters.
> >
> > That's funny: I must have imagined ISO 8859 part 1, part 2, part 3,
> > part 4, part 5, part 6, part 7, part 8, part 9, part 10, and part 11,
> > all of which look like character sets using one-byte values and that
> > have conforming implementations written for them. Not to mention ISO
> > 2022 and ISO 646. Oh, and UCS-2 on systems with 16 bit bytes.
> >
> > This is a standards group. Be precise.
>
> Paul is incorrect, but to be fair, all of the character sets you
> mentioned are based on 7-bit ASCII, and all use the same codes for
> the first 33 control codes (including ESC, 0x1B).  Paul at least was
> making reference to another character set (EBCDIC) that uses
> different codes for control characters (ESC is 0x27).

To be fair, how am I incorrect? I responded as you did, that all those
character sets are variants of ASCII. I'm still itching for someone to
inform me of some character set, that is in actual use, on a machine for
which one might realistically implement C++, that has no concept of an
escape character, yet that has all the other control characters for which
there are backslash constructs.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Paul D. DeRocco" <pderocco@ix.netcom.com> writes:
> This is why I feel that control codes (other than newline)

You are wrong to think that \n should be an exception to your general
principle that control codes are passed through unchanged. Remember
that the standard will continue to specify that the external format
of characters written to a text file doesn't have to match the internal
one. The special \n processing that takes place in DOS when writing to
the display is a consequence of text file translation, not of display
behavior specification.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Paul D. DeRocco" wrote:
>
> James Kuyper <kuyper@wizard.net> wrote in message
> news:37EFEFDA.BB88D7F8@wizard.net...
> > "Paul D. DeRocco" wrote:
> > ...
> > > These characters have specific codes both in ASCII (and all its
> > > derivatives) and EBCDIC, and there don't appear to be any other
> > > character sets in public use that have different encodings for these
> > > things.
> >
> > How many have you checked? Which ones?
>
> I've checked two, ASCII and EBCDIC. To check any others, I'd first have to
> know of their existence, in which case I would have mentioned them. So far,

If you don't know of their existence, then I don't think you count as
the kind of character-set Guru who's word on this issue should be taken
as useful evidence. When you say "there don't appear to be any other
character sets in public use that have different encodings for these
things", all you're doing is describing your lack of expertise with
character sets - you're not saying anything relevant to the question of
whether or not there are any such character sets.

I'm not a character-set guru either, but I've seen a long list of
character sets used in various implementations of C, and I'd be
surprised if every single one was a variant of either ASCII or EBCDIC.
And to forestall your obvious question - if I could remember where I'd
seen that list, I'd have posted it. I'm not citing this list as
evidence, merely explaining my position.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Paul D. DeRocco" wrote:
>
> Clive D.W. Feather <clive@on-the-train.demon.co.uk> wrote in message
> news:5$Yon6BXkG83EwgS@romana.davros.org...
> > Suppose that I am implementing a compiler for a system where *all*
> > cursor movement is done via a single "move cursor" command with code 31
> > followed by either absolute or relative offsets. Then:
> >
> >     \n   ->  31  '0'  ','  '+'  '1'  '.'
> >     \r   ->  31  '0'  ','  '+'  '0'  '.'
> >     \b   ->  31  '-'  '1'  ','  '+'  '0'  '.'
> >     \t   ->  31  '%'  '8'  ','  '+'  '0'  '.'   (tabs every 8 columns)
> >     \v   ->  31  '+'  '0'  ','  '%'  '6'  '.'   (tabs every 6 rows)
> >     \f   ->  31  '0'  ','  '0'  '.'
> >
> > You're thinking in ASCII/EBCDIC terms again, where there happen to be
> > single codes for all these things.
>
> The point isn't whether single characters (other than \n) can actually be
> counted on to do this or that in all environments. The point is that
> whatever obscure multi-character language is used to control some specific
> device in some particular environment, the programmer who has to deal with
> that stuff will know what that language is, and will write the appropriate
> code. In real life, that involves the frequent use of certain well-known
> control characters, but not of others.
>
> And "escape" is a commonly used one. The code 31, in your example above,
> _isn't_ a commonly used one--it's just a mythical example you invented. The
> standard defines constructs that are likely to be useful in real life, and
> shouldn't concern itself with possibilities that are known to be extremely
> unlikely in practice.

In the example above, 31 obviously _is_ the escape character.
Therefore on that system, \e should translate to 31.
Maybe the system doesn't call that character "ESC",
but it obviously treats is as escape character.
If I were to work at that system, and if \e were a standard
sequence for escape, then I would complain to the vendor
(or maybe just look for another compiler) if my compiler
didn't define \e as 31.

>
> For instance, even though an HP printer and an Epson printer have different
> control languages, they both use the "escape" character. It isn't
> appropriate to expect the standard to provide, say, a universal "tab"
> function--or for that matter, a "set font" function--that frees the
> programmer from needing to know what printer is connected. That's a device
> driver function. But in the absence of that, it does need to provide a way
> of generating an escape character (perhaps for the benefit of device driver
> writers), because that's the usual character used to prefix such controls.
> What's more, to allow such code to be portable between ASCII and EBCDIC, the
> escape character (just like any other commonly used control character)
> should have a character-set-independent representation in the language
> standard.

I would also expect the imaginary system to translate
the character 31 to the character 27 in the printer driver.
Otherwise I would complain to the driver vendor (or just
silently disagree, and look for a workaround for that
ugly behaviour).

>
> > >If things were
> > >specified as described above, then \e would fit perfect well into the
> > >standard, representing the character set's "escape" character.
> >
> > You're still assuming there *is* an "escape" character.

Yes, there is an escape character, and in your imaginary
system, it's code point is 31.

And on systems with more than one escape character, people
surely would also be happy with those control characters being
spelled "\e1", "\e2", ...
Yes, those are two characters in the program which would be
output as one character on the display device (or in text files).
I don't see a problem with this.

[...]


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Paul D. DeRocco" wrote:
...
> inform me of some character set, that is in actual use, on a machine for
> which one might realistically implement C++, that has no concept of an
> escape character, yet that has all the other control characters for which
> there are backslash constructs.

... or ways in which the runtime library can implement their effects.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Kevin Bracey <kevin.bracey@pacemicro.com> wrote in message
news:a0252c4949%kbracey@kbracey.acorn.co.uk...

> Unfortunately, at the moment 9 is just passed through to the tty, moving
> the cursor right one position. I would argue that this was a bad
> implementation decision. It's technically correct if you argue that our
> tab stops are at 1 character intervals, but it would have been more
> helpful to output the appropriate number of spaces or 9s to move to an 8
> character boundary. This would save a lot of hassle with ported Unix code.
>
> It's no good saying "just pass the control codes through". A lot of
> systems tty equivalents don't have the necessary functions - the C library
> has to interpret the escape sequences in terms of their desired effects.
> And what is the desired effect of \e? God knows. Just passing it through
> as \x1B could be fatal; but as it happens code 27 does nothing on our
> system. Lucky it wan't 21 - that shuts down the tty altogether until 6 is
> sent...

This is where we disagree. You obviously see the difficulty of interpreting
tab in a coherent manner--for instance, you can't expand tabs unless you
know what the tab stops are, and there is no standard way of specifying
that. Thus, arguing that tab should be converted into a certain number of
blanks by the _language_ (i.e., the standard library), as opposed to some
device driver that's not required or defined by the language standard, opens
a huge can of worms that can never be recanned.

This is why I feel that control codes (other than newline) _should_ be
passed on unchanged, leaving it to some other piece of code unspecified by
the device driver to interpret them. The C or C++ standard, in my view, has
no business defining _any_ control functions other than the ability to move
to the beginning of the next line (and possibly to the beginning of the
first line on the next page, although that's my own wish, not standard
practice). Horizontal tabs, vertical tabs, backspaces, returns without line
feeds, bells, whistles, colors, fonts, etc. are (or should be considered)
beyond the scope of a mere programming language standard. The backslash
escapes used to represent these control characters are not (or should not
be) there to provide a standard means of obtaining certain output effects,
but are (or should be) there only to provide a character-set-independent
shorthand for situations where the programmer knows how the device will
interpret these characters.




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper <kuyper@wizard.net> wrote in message
news:37EFEFDA.BB88D7F8@wizard.net...
> "Paul D. DeRocco" wrote:
> ...
> > These characters have specific codes both in ASCII (and all its
> > derivatives) and EBCDIC, and there don't appear to be any other
> > character sets in public use that have different encodings for these
> > things.
>
> How many have you checked? Which ones?

I've checked two, ASCII and EBCDIC. To check any others, I'd first have to
know of their existence, in which case I would have mentioned them. So far,
all the other "character sets" people have pointed me to have turned out to
be variants of ASCII.




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Clive D.W. Feather <clive@on-the-train.demon.co.uk> wrote in message
news:5$Yon6BXkG83EwgS@romana.davros.org...
> Suppose that I am implementing a compiler for a system where *all*
> cursor movement is done via a single "move cursor" command with code 31
> followed by either absolute or relative offsets. Then:
>
>     \n   ->  31  '0'  ','  '+'  '1'  '.'
>     \r   ->  31  '0'  ','  '+'  '0'  '.'
>     \b   ->  31  '-'  '1'  ','  '+'  '0'  '.'
>     \t   ->  31  '%'  '8'  ','  '+'  '0'  '.'   (tabs every 8 columns)
>     \v   ->  31  '+'  '0'  ','  '%'  '6'  '.'   (tabs every 6 rows)
>     \f   ->  31  '0'  ','  '0'  '.'
>
> You're thinking in ASCII/EBCDIC terms again, where there happen to be
> single codes for all these things.

The point isn't whether single characters (other than \n) can actually be
counted on to do this or that in all environments. The point is that
whatever obscure multi-character language is used to control some specific
device in some particular environment, the programmer who has to deal with
that stuff will know what that language is, and will write the appropriate
code. In real life, that involves the frequent use of certain well-known
control characters, but not of others.

And "escape" is a commonly used one. The code 31, in your example above,
_isn't_ a commonly used one--it's just a mythical example you invented. The
standard defines constructs that are likely to be useful in real life, and
shouldn't concern itself with possibilities that are known to be extremely
unlikely in practice.

For instance, even though an HP printer and an Epson printer have different
control languages, they both use the "escape" character. It isn't
appropriate to expect the standard to provide, say, a universal "tab"
function--or for that matter, a "set font" function--that frees the
programmer from needing to know what printer is connected. That's a device
driver function. But in the absence of that, it does need to provide a way
of generating an escape character (perhaps for the benefit of device driver
writers), because that's the usual character used to prefix such controls.
What's more, to allow such code to be portable between ASCII and EBCDIC, the
escape character (just like any other commonly used control character)
should have a character-set-independent representation in the language
standard.

> >If things were
> >specified as described above, then \e would fit perfect well into the
> >standard, representing the character set's "escape" character.
>
> You're still assuming there *is* an "escape" character.

Yes I am. That's because there _is_ an oft-used escape character in every
system I've ever heard of, for which anyone is likely to write a
standard-conforming C++ compiler. I've yet to hear of a counterexample.




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Russell Bornschlegel <kaleja@rahul.net> writes:
> Paul Jarc wrote:
> > The idea that \z, for any z, represents a single character is
> > incompatible with the idea that \d123 represents a single character.
>
> The idea that \z, for any z, represents a single character is
> incompatible with \x, is it not?

Yes.  Someone suggested making \z, for any z, syntactically legal.  I
hadn't interpreted the suggestion as affecting existing constructs, so
I just explained the problem Clive raised for possible future escape
sequences.


paul


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper <kuyper@wizard.net> writes:
> On such a system, 31 is arguably the correct value for \e given the
> descriptions some people have proposed. I doubt that such an
> implementation would be acceptable to those people, however.

If the character set used by the system is ASCII, then the usual values
should be assigned to the character escape sequences, including ESC for
\e. If it isn't, then given the description, 31 would be the right choice.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Pete Becker <petebecker@acm.org> writes:
> Valentin Bonnard wrote:
> > Having '\e' doesn't have anything to do w/ portability,
> > it's just about typing ease and readability.
> Perhaps, but most of the folks who are asking for \e seem to want more
> than that from it.

No, most of us folks just want it for typing and readability, since
we don't expect to be working on non-ASCII platforms. Some people
also realized that \e would have the added benefit of being a more
portable representation than \x1B on non-ASCII platforms which have
their own version of an escape character and a well-defined mapping
to ASCII.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Kevin Bracey <kevin.bracey@pacemicro.com> writes:
> It's no good saying "just pass the control codes through". A lot of systems
> tty equivalents don't have the necessary functions - the C library has to
> interpret the escape sequences in terms of their desired effects. And what
> is the desired effect of \e? God knows. Just passing it through as \x1B could
> be fatal; but as it happens code 27 does nothing on our system. Lucky it
> wan't 21 - that shuts down the tty altogether until 6 is sent...

Any fatality potential is already present, since I can write the
following code:

 unsigned char c = 0;
 do putchar(c++) while (c != 0);

Defining \e to be some character only affects the source code.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Clive D.W. Feather" wrote:
...
> That's not the point.
>
> Suppose that I am implementing a compiler for a system where *all*
> cursor movement is done via a single "move cursor" command with code 31
> followed by either absolute or relative offsets. Then:
>
>     \n   ->  31  '0'  ','  '+'  '1'  '.'
>     \r   ->  31  '0'  ','  '+'  '0'  '.'
>     \b   ->  31  '-'  '1'  ','  '+'  '0'  '.'
>     \t   ->  31  '%'  '8'  ','  '+'  '0'  '.'   (tabs every 8 columns)
>     \v   ->  31  '+'  '0'  ','  '%'  '6'  '.'   (tabs every 6 rows)
>     \f   ->  31  '0'  ','  '0'  '.'
>
> You're thinking in ASCII/EBCDIC terms again, where there happen to be
> single codes for all these things.
>
> >Fourth, since the "newline" function implies the possibility of doing some
> >translation, the library must provide a means for opening files in either
> >text mode, with translation, or binary mode, without translation.
>
> It already does.
>
> >If things were
> >specified as described above, then \e would fit perfect well into the
> >standard, representing the character set's "escape" character.
>
> You're still assuming there *is* an "escape" character.

Not to disagree with you, but to emphasize your point:

On such a system, 31 is arguably the correct value for \e given the
descriptions some people have proposed. I doubt that such an
implementation would be acceptable to those people, however.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paul Jarc wrote:
> The idea that \z, for any z, represents a single character is
> incompatible with the idea that \d123 represents a single character.

The idea that \z, for any z, represents a single character is
incompatible with \x, is it not?

-Russell Bornschlegel
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble wrote:
>
> Pete Becker wrote:
> >
> > If the character set that the OS uses does not contain a character
> > that can serve as alert, the runtime library produces an alert by
> > some other mechanism.
>
> No, if the character set does not contain a character that can serve
> as alert, an arbitrary character must be chosen by the compiler
> implementor for '\a'.  Otherwise, the compiler won't be conforming,
> since it won't properly translate:
>
>      char  c = '\a';   // something gets stored in c
>

Change "No," above to "Yes, and". Otherwise the compiler won't be
conforming, since it won't produce the correct behavior for puts("\a");.

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble wrote:
> Currently (as I've said before), we have neither guarantee today;
> using '\e' is completely unportable today, precisely because it's
> not in the standard.

If it were in the standard, it would still be nonportable.
Do you really think that in a radically different environment
(EBCDIC for example) you would be sending output to the same
terminal that you already hard-coded the escape sequence for?
There has been a decent solution to terminal-code-independent
programming for a couple of decades now, namely termcap/curses/
terminfo.  Of course, bitmap display programming, mouse
interaction, etc. require a completely different approach.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Pete Becker <petebecker@acm.org> writes:
> But that's about how to express it, not about the substance. The problem
> is that saying "\t maps to TAB" when the target system's character set
> is ASCII doesn't tell you much about what to expect when \t is written
> to a display device, because it says nothing about how TAB affects the
> display device. So the effect may well be to write a single small
> diamond on the display device, because the device doesn't expand tabs.
> Putting the reqirement in the standard means that for such a system, the
> compiler's runtime library should expand tabs. Requiring \t to expand to
> TAB makes its effect less predictable than describing what it should do.

But that's not what anyone wants. C gave people a way of writing
certain characters that they wanted to use in their source code that
was more convenient than having to look up a number. I think the
language in the C standard is back formation. Everyone knew what the
characters should be, but they thought they had to write a description
that was neutral with respect to character sets, so they came up with
the notion of describing effects.

People writing programs for your hypothetical device probably *want*
to see a single small diamond.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hyman Rosen wrote:
>
> People writing programs for your hypothetical device probably *want*
> to see a single small diamond.
>

No, I quickly changed the output code to expand tabs. (In case it isn't
clear, the small diamond is the character that this particular device
displayed when sent the ASCII TAB character).

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Paul D. DeRocco" wrote:
...
> First, all backslash escapes should be defined by the C and C++ standards
> as representing certain standard control characters, i.e., bell or alert
> (\a), backspace (\b), form feed (\f), line feed (\n), carriage return (\r),
> horizontal tab (\t) and vertical tab (\v). These characters have specific
> codes both in ASCII (and all its derivatives) and EBCDIC, and there don't
> appear to be any other character sets in public use that have different
> encodings for these things.

How many have you checked? Which ones?
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paul D. DeRocco wrote in message <37EE7A83.5A084D5C@ix.netcom.com>...
>
>I spelled out what I want pretty clearly in another long message, which no
>one seemed to notice.

Only because it was so obviously correct it needed no comment. Or maybe it
got lost in the noise.

>First, all backslash escapes should be defined by the C and C++ standards
>as representing certain standard control characters, i.e., bell or alert
>(\a), backspace (\b), form feed (\f), line feed (\n), carriage return (\r),
>horizontal tab (\t) and vertical tab (\v). These characters have specific
>codes both in ASCII (and all its derivatives) and EBCDIC, and there don't
>appear to be any other character sets in public use that have different
>encodings for these things.

Yes. Note that these all have both the informal names you've listed and
standard names (BEL, TAB, ESC). C++ does the right thing by specifying both.

>Second, the line feed character should be treated as special, and defined
>to mean "newline" when it appears in a program.

Not when it appears in a program: when it appears as input to a library
routine that is required to implement display semantics. This is important:
there are lots of "standard conforming" things a program can do nowadays in
addition to printing. C doesn't talk about the other standards (e.g.
ISO-2022), but some of us need to write to other standards as well. What we
need in our constants is a notation for writing to those other standards,
not just printf().

> That is, outputting a
>"newline" character should move to the first column of the next line, and
>moving to the first column of the next line in input should return a single
>"newline" character to the program. If the surrounding environment uses
>some other character sequence (e.g., \r\n or just \r) for this purpose, the
>standard library must translate between \n in the program and the necessary
>control sequence outside the program. This translation is necessary because
>in order to have a portable communication or representation protocol for
>two-dimensional text (i.e., rows and columns), a newline function is
>necessary.

Again, this is a requirement on certain parts of the standard library and
nothing else. And needs to be written as such, carefully.

>Third, the standard library must not do any analogous translation for any
>other control character. This is because a portable text protocol doesn't
>need any other control functions besides newline. Thus, the remaining
>control characters should be assumed to be for device control, where the
>programmer assumes responsibility for knowing how the external device
>interprets these characters. (A possible exception would be form feed,
>because a portable way of representing three-dimensional text could be
>useful, and form feed could be called "newpage", but this is beyond current
>standard practice.)
>
>Fourth, since the "newline" function implies the possibility of doing some
>translation, the library must provide a means for opening files in either
>text mode, with translation, or binary mode, without translation.
>
>If that was how the standard was written it would in fact describe current
>practice. The C standard, as written, overspecifies things, by defining
>what the other control character are supposed to do, even though the
>standard library doesn't and can't enforce such behavior. If things were
>specified as described above, then \e would fit perfect well into the
>standard, representing the character set's "escape" character.


I might say it differently*, but sure. It's broken and a defect report is
needed.

*: The problem is (IMHO) more a matter that it tries to describe the
behavior of constructs that are notations for data values, and (1) data
doesn't have behavior until something interprets it, and (2) the only
"behavior" these particular syntactic constructs can have is to be
translated into particular data values.

David J. Littleboy
Tokyo, Japan
davidjl <at> gol <dot> com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Pete Becker wrote:
> Requiring \t to expand to TAB makes its effect less predictable
> than describing what it should do.

I don't think there is any operational difference between C and C++
standards in this respect, just a difference in expression.  '\t'
is supposed to map to a constant control character, whose semantics
are intentional rather than normative.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble <david@tribble.com> writes:
> Pete Becker wrote:
> > If the character set that the OS uses does not contain a character
> > that can serve as alert, the runtime library produces an alert by
> > some other mechanism.
>
> No, if the character set does not contain a character that can serve
> as alert, an arbitrary character must be chosen by the compiler
> implementor for '\a'.

That doesn't conflict with Pete's statement.  The compiler uses some
arbitrary value for \a, and the library recognizes that value and
produces an alert somehow.


paul
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Clive D.W. Feather wrote:
>
> Paul D. DeRocco <pderocco@ix.netcom.com> writes:
>> But I see no reason to bother with such hair-splitting, since there
>> really are only two character sets (that use one-byte values, and for
>> which anyone will attempt to write a standard-conforming C++
>> compiler), and they both have escape characters.
>
> That's funny: I must have imagined ISO 8859 part 1, part 2, part 3,
> part 4, part 5, part 6, part 7, part 8, part 9, part 10, and part 11,
> all of which look like character sets using one-byte values and that
> have conforming implementations written for them. Not to mention ISO
> 2022 and ISO 646. Oh, and UCS-2 on systems with 16 bit bytes.
>
> This is a standards group. Be precise.

Paul is incorrect, but to be fair, all of the character sets you
mentioned are based on 7-bit ASCII, and all use the same codes for
the first 33 control codes (including ESC, 0x1B).  Paul at least was
making reference to another character set (EBCDIC) that uses
different codes for control characters (ESC is 0x27).

-- David R. Tribble, david@tribble.com --


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Francis Glassborow wrote:
>
> Pete Becker <petebecker@acm.org> writes:
>> No, the standard imposes no such requirement. What it says is that
>> each of the escape character sequences "shall produce a unique
>> implementation-defined value." (Hmm, since \ introduces an escape
>> character sequence, shouldn't it be regarded as "the escape
>> character"? It has the advantage of being platform-independent...)
>
> I think C already ascribes meanings to too many \ sequences.  Every
> specified sequence imposes a requirement on the source character set
> because it requires the unique use of a precious resource (at most 256
> character codes).  Instead of putting \e in I would argue for taking
> such things as \v out.

And what do we do about all that code that currently uses '\v'?

Assuming you have an answer for that, what about removing all of
the \ escape sequences altogether?

-- David R. Tribble, david@tribble.com --


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37EE40EB.D9DB9704@ihug.co.nz>, Ross Smith
<ross.s@ihug.co.nz> writes
>>>Would you and the rest of the pro-'\e' people be satisfied if the
>>>standard changed the behaviour of *all* non-standard escape sequences
>>>from "diagnostic required" to "implementation defined"

>> No good: it would stop anyone adding a multi-character escape (such as
>> \d123 for decimal code 123).
>
>I don't follow you. How would it stop that? Wouldn't it just turn it
>from an extension into implementation defined?

No. As you've phrased it, '\d' would be an implementation-defined escape
sequence, which means that "\d123" is a 5 byte string (containing '\d',
'0'+1, '0'+2, '0'+3, and 0 in that order). Different implementations
could have different values for \d, but they would all have to produce a
5 byte string.

If C0X then decided that we *really* need \d as decimal escape, then
it's a Quiet Change.

>Come to think of it, it's
>an illegal extension anyway -- as I read C9X, escape sequence extensions
>must start with a capital letter.

I wasn't thinking of an extension but rather a change in C0X.

--
Clive D.W. Feather    | Internet Expert      | Work: <clive@demon.net>
Tel: +44 20 8371 1138 | Demon Internet Ltd.  | Home: <clive@davros.org>
Fax: +44 20 8371 1037 |                      | Web:  <http://www.davros.org>
Written on my laptop; please observe the Reply-To address
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37EE7A83.5A084D5C@ix.netcom.com>, Paul D. DeRocco
<pderocco@ix.netcom.com> writes
>Third, the standard library must not do any analogous translation for any
>other control character. This is because a portable text protocol doesn't
>need any other control functions besides newline.

That's not the point.

Suppose that I am implementing a compiler for a system where *all*
cursor movement is done via a single "move cursor" command with code 31
followed by either absolute or relative offsets. Then:

    \n   ->  31  '0'  ','  '+'  '1'  '.'
    \r   ->  31  '0'  ','  '+'  '0'  '.'
    \b   ->  31  '-'  '1'  ','  '+'  '0'  '.'
    \t   ->  31  '%'  '8'  ','  '+'  '0'  '.'   (tabs every 8 columns)
    \v   ->  31  '+'  '0'  ','  '%'  '6'  '.'   (tabs every 6 rows)
    \f   ->  31  '0'  ','  '0'  '.'

You're thinking in ASCII/EBCDIC terms again, where there happen to be
single codes for all these things.

>Fourth, since the "newline" function implies the possibility of doing some
>translation, the library must provide a means for opening files in either
>text mode, with translation, or binary mode, without translation.

It already does.

>If things were
>specified as described above, then \e would fit perfect well into the
>standard, representing the character set's "escape" character.

You're still assuming there *is* an "escape" character.

--
Clive D.W. Feather    | Internet Expert      | Work: <clive@demon.net>
Tel: +44 20 8371 1138 | Demon Internet Ltd.  | Home: <clive@davros.org>
Fax: +44 20 8371 1037 |                      | Web:  <http://www.davros.org>
Written on my laptop; please observe the Reply-To address
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ross Smith <ross.s@ihug.co.nz> writes:
> "Clive D.W. Feather" wrote:
> > In article <37ECC6AE.46D8921C@ihug.co.nz>, Ross Smith
> > <ross.s@ihug.co.nz> writes
> > >Would you and the rest of the pro-'\e' people be satisfied if the
> > >standard changed the behaviour of *all* non-standard escape sequences
> > >from "diagnostic required" to "implementation defined" (without
> > >explicitly mentioning '\e')? How would the anti-'\e' people feel about
> > >that?
> >
> > No good: it would stop anyone adding a multi-character escape (such as
> > \d123 for decimal code 123).
>
> I don't follow you. How would it stop that? Wouldn't it just turn it
> from an extension into implementation defined?

The idea that \z, for any z, represents a single character is
incompatible with the idea that \d123 represents a single character.

> Come to think of it, it's an illegal extension anyway -- as I read
> C9X, escape sequence extensions must start with a capital letter.

True, but then \d123 couldn't be added to the standard either.


paul
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Pete Becker wrote:
>
> Hyman Rosen wrote:
>> If the execution character set does not contain a character that can
>> reasonably be interpreted as escape, the compiler will deal with
>> just in the way it would if the execution character set did not
>> contain a character that could reasonably be interpreted as alert.
>> That would be to pick a translation that would be least surprising
>> to users of that character set. Lacking any such examples, I can't
>> specify this better.
>
> If the character set that the OS uses does not contain a character
> that can serve as alert, the runtime library produces an alert by
> some other mechanism.

No, if the character set does not contain a character that can serve
as alert, an arbitrary character must be chosen by the compiler
implementor for '\a'.  Otherwise, the compiler won't be conforming,
since it won't properly translate:

     char  c = '\a';   // something gets stored in c

-- David R. Tribble, david@tribble.com --
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Clive D.W. Feather" wrote:
>
> Greg Brewer <nospam.greg@brewer.net> writes:
>> All everyone wants is for the string "XYZ\eB" to be portable among
>> compilers.  On an ASCII system, we want the compiler to substitute
>> x1b for \e, period.  On an EBCDIC system, we want the compiler to
>> substitite the EBCDIC code for ESC which I don't remember right now
>> for the \e.
>
> What does it substitute on my Torch Unicorn or my Psion 3a? There's
> no ESC in the character set. There are codes to clear screen, move the
> cursor, change the colour of output text, and so on, but no ESC.

But if there exists a conforming C compiler for it, it must allocate
at least 8 bits for each 'char' object; since ISO C only prescribes
99 characters, there are at least 157 codes left to choose from.

The standard doesn't say that the code chosen for '\a', for example,
cannot also be known as "lowercase red greek alpha", for example, in
the execution character set.

-- David R. Tribble, david@tribble.com --
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Pete Becker wrote:
>
> Christopher Eltschka wrote:
[...]
> > However, the behaviour is _not_ simply undefined, just the
> > output on std::cout may be anything, but neither the
> > compilation nor the program run may abort, nor may the
> > program return EXIT_FAILURE.
>
> So how is '\e' different, if it is, from '\033'?

Well, for one thing, '\e' is not the same as '\033' on EBCDIC systems.

> Or is all this heat only about wanting a two-letter abbreviation for
> a four-character constant?

No.  It's about wanting a standard, portable way to specify an "escape"
character.

-- David R. Tribble, david@tribble.com --
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In message <37F14BB3.574392F0@acm.org>
          Pete Becker <petebecker@acm.org> wrote:

>
> Hyman Rosen wrote:
> >
> > People writing programs for your hypothetical device probably *want*
> > to see a single small diamond.
> >
>
> No, I quickly changed the output code to expand tabs. (In case it isn't
> clear, the small diamond is the character that this particular device
> displayed when sent the ASCII TAB character).
>

As another real-life example, my platform's standard output stream does not
have a character that moves the cursor to the next tab stop - it doesn't
have tab stops. Control code 9 just moves the cursor right one position
(just as 8 moves it left, 10 moves it down and 11 moves it up). Also, code
13 is a carriage return _only_, it doesn't move the cursor down a line.

So, with our C compiler and library, '\n' is 10 and '\t' is 9. If 10
is output to a text file, just 10 is output, as our standard text file line
ending is LF only, as per Unix. If 10 is output to a tty stream, then 13,10
is output to perform a carriage return and move to a new line.

Unfortunately, at the moment 9 is just passed through to the tty, moving the
cursor right one position. I would argue that this was a bad implementation
decision. It's technically correct if you argue that our tab stops are at 1
character intervals, but it would have been more helpful to output the
appropriate number of spaces or 9s to move to an 8 character boundary. This
would save a lot of hassle with ported Unix code.

It's no good saying "just pass the control codes through". A lot of systems
tty equivalents don't have the necessary functions - the C library has to
interpret the escape sequences in terms of their desired effects. And what
is the desired effect of \e? God knows. Just passing it through as \x1B could
be fatal; but as it happens code 27 does nothing on our system. Lucky it
wan't 21 - that shuts down the tty altogether until 6 is sent...

--
Kevin Bracey, Senior Software Engineer
Pace Micro Technology plc                     Tel: +44 (0) 1223 518566
645 Newmarket Road                            Fax: +44 (0) 1223 518526
Cambridge, CB5 8PB, United Kingdom            WWW: http://www.acorn.co.uk/
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Valentin Bonnard wrote:
>
> Pete Becker wrote:
>
> > David R Tribble wrote:
>
> > > I and others have argued that the definition of '\e' should be:
> > >
> > >     \e (escape)  produces an implementation-defined action.
> >
> > So, once again, how is this better than the current state of affairs,
> > where the effect of '\033' is undefined? In both cases, in order to use
> > such a character in a non-trivial way, you must consult the compiler's
> > documentation. If the documentation tells you that it does what you need
> > you can use it. If not, you can't.
>
> Typing "foo\ebar" is a bit faster than "foo\033bar" or
> "foo" ESC "bar" (w/ #define ESC "\033").
>
> Having '\e' doesn't have anything to do w/ portability,
> it's just about typing ease and readability.
>

Perhaps, but most of the folks who are asking for \e seem to want more
than that from it.

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Valentin Bonnard wrote:
>
> Typing "foo\ebar" is a bit faster than "foo\033bar" or
> "foo" ESC "bar" (w/ #define ESC "\033").
>
> Having '\e' doesn't have anything to do w/ portability,
> it's just about typing ease and readability.

Sure it does, because the EBCDIC escape character has a different numeric
code.

--

Ciao,                       Paul D. DeRocco
Paul                        mailto:pderocco@ix.netcom.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Clive D.W. Feather" wrote:
>
> In article <37ECC6AE.46D8921C@ihug.co.nz>, Ross Smith
> <ross.s@ihug.co.nz> writes
> >Would you and the rest of the pro-'\e' people be satisfied if the
> >standard changed the behaviour of *all* non-standard escape sequences
> >from "diagnostic required" to "implementation defined" (without
> >explicitly mentioning '\e')? How would the anti-'\e' people feel about
> >that?
>
> No good: it would stop anyone adding a multi-character escape (such as
> \d123 for decimal code 123).

I don't follow you. How would it stop that? Wouldn't it just turn it
from an extension into implementation defined? Come to think of it, it's
an illegal extension anyway -- as I read C9X, escape sequence extensions
must start with a capital letter.

--
Ross Smith <ross.s@ihug.co.nz> The Internet Group, Auckland, New Zealand
========================================================================
  "There are many technical details that make Linux attractive to the
  sort of people to whom technical details are attractive."   -- Suck
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Pete Becker wrote:

> David R Tribble wrote:

> > I and others have argued that the definition of '\e' should be:
> >
> >     \e (escape)  produces an implementation-defined action.
>
> So, once again, how is this better than the current state of affairs,
> where the effect of '\033' is undefined? In both cases, in order to use
> such a character in a non-trivial way, you must consult the compiler's
> documentation. If the documentation tells you that it does what you need
> you can use it. If not, you can't.

Typing "foo\ebar" is a bit faster than "foo\033bar" or
"foo" ESC "bar" (w/ #define ESC "\033").

Having '\e' doesn't have anything to do w/ portability,
it's just about typing ease and readability.

--

Valentin Bonnard
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ross Smith wrote:
>
> David R Tribble wrote:
> >
> > I and others have argued that the definition of '\e' should be:
> >
> >     \e (escape)  produces an implementation-defined action.
> >
> > Therefore, the choice of character code for '\e' is up to the
> > implementor.  The name "escape" should serve as a hint, though,
> > that ESC is a reasonable choice for ASCII and EBCDIC (and other)
> > implementations.
>
> Would you and the rest of the pro-'\e' people be satisfied if the
> standard changed the behaviour of *all* non-standard escape sequences
> from "diagnostic required" to "implementation defined" (without
> explicitly mentioning '\e')?

No, because ISO reserves all \-lowercase-letter sequences; thus the
need for a diagnostic.  (Consider porting a non-conforming program
using '\z' to a conforming compiler.)

Also, if we left \e (and the rest) only implementation-defined,
my use of \e in a "portable" program is useless; I have no gurantees
at all that \e means anything resembling "escape" or "ESC".

What I'm arguing for is the addition of a standard \e sequence to
ISO, and to give it a meaning that, at the very least, strongly
implies "escape".

> How would the anti-'\e' people feel about that?

They'd probably say "no", too.

-- David R. Tribble, david@tribble.com --


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Ross Smith wrote:
>
> Would you and the rest of the pro-'\e' people be satisfied if the
> standard changed the behaviour of *all* non-standard escape sequences
> from "diagnostic required" to "implementation defined" (without
> explicitly mentioning '\e')? How would the anti-'\e' people feel about
> that?

I spelled out what I want pretty clearly in another long message, which no
one seemed to notice.

First, all backslash escapes should be defined by the C and C++ standards
as representing certain standard control characters, i.e., bell or alert
(\a), backspace (\b), form feed (\f), line feed (\n), carriage return (\r),
horizontal tab (\t) and vertical tab (\v). These characters have specific
codes both in ASCII (and all its derivatives) and EBCDIC, and there don't
appear to be any other character sets in public use that have different
encodings for these things.

Second, the line feed character should be treated as special, and defined
to mean "newline" when it appears in a program. That is, outputting a
"newline" character should move to the first column of the next line, and
moving to the first column of the next line in input should return a single
"newline" character to the program. If the surrounding environment uses
some other character sequence (e.g., \r\n or just \r) for this purpose, the
standard library must translate between \n in the program and the necessary
control sequence outside the program. This translation is necessary because
in order to have a portable communication or representation protocol for
two-dimensional text (i.e., rows and columns), a newline function is
necessary.

Third, the standard library must not do any analogous translation for any
other control character. This is because a portable text protocol doesn't
need any other control functions besides newline. Thus, the remaining
control characters should be assumed to be for device control, where the
programmer assumes responsibility for knowing how the external device
interprets these characters. (A possible exception would be form feed,
because a portable way of representing three-dimensional text could be
useful, and form feed could be called "newpage", but this is beyond current
standard practice.)

Fourth, since the "newline" function implies the possibility of doing some
translation, the library must provide a means for opening files in either
text mode, with translation, or binary mode, without translation.

If that was how the standard was wruttebm it would in fact describe current
practice. The C standard, as written, overspecifies things, by defining
what the other control character are supposed to do, even though the
standard library doesn't and can't enforce such behavior. If things were
specified as described above, then \e would fit perfect well into the
standard, representing the character set's "escape" character.

--

Ciao,                       Paul D. DeRocco
Paul                        mailto:pderocco@ix.netcom.com


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Valentin Bonnard wrote:
>
> Pete Becker wrote:
>
> > David R Tribble wrote:
>
> > > I and others have argued that the definition of '\e' should be:
> > >
> > >     \e (escape)  produces an implementation-defined action.
> >
> > So, once again, how is this better than the current state of
> > affairs, where the effect of '\033' is undefined? In both cases,
> > in order to use such a character in a non-trivial way, you must
> > consult the compiler's documentation. If the documentation tells
> > you that it does what you need you can use it. If not, you can't.
>
> Typing "foo\ebar" is a bit faster than "foo\033bar" or
> "foo" ESC "bar" (w/ #define ESC "\033").
>
> Having '\e' doesn't have anything to do w/ portability,
> it's just about typing ease and readability.

On the contrary, I think a standard \e sequence would have an
positive impact on portability.  Programmers would be able to use
'\e' knowing that
 1) all conforming compilers would accept it, and
 2) replace it with the "escape" character that is appropriate for
    the platform at hand (which might not be \033).

Currently (as I've said before), we have neither guarantee today;
using '\e' is completely unportable today, precisely because it's
not in the standard.

-- David R. Tribble, david@tribble.com --


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Pete Becker <petebecker@acm.org> writes:
> The real issue is whether alphabetic escape sequences should be
> specified in terms of the character values which they produce, or in
> terms of the effects they produce on a display device. The latter is the
> approach taken by the C standard. The former is taken by the C++
> standard, although I think that was a historical accident and not a
> deliberate decision. I don't recall any discussion in the standards
> committee about the implications of this rule.

The C++ approach is the vastly superior one, because the number of
execution character sets is much smaller than the number of display
devices. By describing the escape sequences as it does, the C++
standard handles the overwhelming majority of execution environments
in the world, and doesn't suffer from having to describe things like
"vertical tabulation position".


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Hyman Rosen wrote:
>
> Pete Becker <petebecker@acm.org> writes:
> > The real issue is whether alphabetic escape sequences should be
> > specified in terms of the character values which they produce, or in
> > terms of the effects they produce on a display device. The latter is the
> > approach taken by the C standard. The former is taken by the C++
> > standard, although I think that was a historical accident and not a
> > deliberate decision. I don't recall any discussion in the standards
> > committee about the implications of this rule.
>
> The C++ approach is the vastly superior one, because the number of
> execution character sets is much smaller than the number of display
> devices. By describing the escape sequences as it does, the C++
> standard handles the overwhelming majority of execution environments
> in the world, and doesn't suffer from having to describe things like
> "vertical tabulation position".
>

First, please don't use the term "execution character set" in this way.
That's not what it means. The execution character set is simply the set
of values that characters used in quoted strings will be translated
into. It has no independent existence. The target platform has a
character set that it interprets, and it's convenient to map characters
contained in quoted stirngs into the corresponding values for the target
platform, but that is not required by the C standard.

But that's about how to express it, not about the substance. The problem
is that saying "\t maps to TAB" when the target system's character set
is ASCII doesn't tell you much about what to expect when \t is written
to a display device, because it says nothing about how TAB affects the
display device. So the effect may well be to write a single small
diamond on the display device, because the device doesn't expand tabs.
Putting the reqirement in the standard means that for such a system, the
compiler's runtime library should expand tabs. Requiring \t to expand to
TAB makes its effect less predictable than describing what it should do.

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <37ECC6AE.46D8921C@ihug.co.nz>, Ross Smith
<ross.s@ihug.co.nz> writes
>Would you and the rest of the pro-'\e' people be satisfied if the
>standard changed the behaviour of *all* non-standard escape sequences
>from "diagnostic required" to "implementation defined" (without
>explicitly mentioning '\e')? How would the anti-'\e' people feel about
>that?

No good: it would stop anyone adding a multi-character escape (such as
\d123 for decimal code 123).

--
Clive D.W. Feather    | Internet Expert      | Work: <clive@demon.net>
Tel: +44 20 8371 1138 | Demon Internet Ltd.  | Home: <clive@davros.org>
Fax: +44 20 8371 1037 |                      | Web:  <http://www.davros.org>
Written on my laptop; please observe the Reply-To address


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

[Subject line changed to something more meaningful. -drt]

Pete Becker wrote:
>
> David R Tribble wrote:
>>
>> Pete Becker wrote:
>> >
>> > Hyman Rosen wrote:
>> >> In addition, 2.2#3 would need to have "escape" added to the list
>> >> of control characters present in the execution character sets.
>> >> Since many people claim to find this useful, and its only effect
>> >> is to make a currently undefined usage defined, I see no reason
>> >> not to add it.
>> >
>> > Defined as what? That is, what should the implementation do if
>> > there is no character whose name is ESC?
>>
>> Um, something similar to what they would do of if there is no
>> character named NL?
>
> Exactly. So, on DOS, we translate \n into a character sequence that
> moves the active position to the beginning of the next line, that is,
> we send the ASCII characters CR and LF to the BIOS.

That has very little to do with what character code is used to
represent '\n' (or any of the other escape sequences).  The standard
merely defines the semantics for each character chosen for each
escape sequence; what's important here is that each escape sequence
must be represented by a unique value that fits into a 'char' object.
(The standard states that the external encodings of the escape
sequences are outside its jurisdiction [*].)  ASCII has no NL
character code, so most ASCII implementations choose LF.  Most EBCDIC
implementations choose either NL (since EBCDIC does have a NL
character) or LF (presumably to be more compatible with ASCII
implementations).

> Now, what characters should be sent to the display device, if ESC
> doesn't exist, in order to produce the effect that it was intended
> to have?

I and others have argued that the definition of '\e' should be:

    \e (escape)  produces an implementation-defined action.

Therefore, the choice of character code for '\e' is up to the
implementor.  The name "escape" should serve as a hint, though,
that ESC is a reasonable choice for ASCII and EBCDIC (and other)
implementations.

--
[*]
  5.2.2
  3  Each of these escape sequences shall produce a unique
  implementation-defined value which can be stored in a single
  'char' object.  The external representations in a text file
  need not be identical to the internal representations, and are
  outside the scope of this International Standard.

-- David R. Tribble, david@tribble.com --
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]