Russell Bornschlegel <kaleja@rahul.net> wrote:

> On the other hand, at least gcc doesn't have much moral ground on which
> to object to '\e'.

Indeed, it already implements `\e'.

-- [mdw]
---
[ 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:
>> ...  there is nothing you can say about the effect of a string
>> containing \e from reading the standard.
>
> So what? The point has always been that people want \e to just send an
> escape character. But some people are insisting that \e must be given
> a description in the style of the other alphabetic escape sequences. I
> proposed one, which essentially says that its effect is unspecified.
> The other descriptions allow the behavior to be unspecified in various
> circumstances. Once \e is in the standard, vendors will implement it
> in a logical and sane manner, just as their customers want, just like
> they do for \t, \f, and the others.

Hyman and I both proposed simple wording for \e, along the lines of:

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

I had assumed that the "(escape)" in such a definition would have
provided a sufficient clue to implementors for the "logical"
choice for '\e', but I guess it's not enough.  Perhaps it would
be wise to also supply a helpful footnote to guide implementors,
such as:

    [*]  Typically, the \e sequence can be implemented in ASCII as
         the ESC character '\x1B', and in EBCDIC as '\x27'.

This shouldn't ruffle any feathers, since footnotes are not normative.

-- 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 <jsKK3.25$IV3.2189@ptah.visi.com>,
Peter Seebach <seebs@plethora.net> wrote:
>In article <7tbcdr$l4d@dfw-ixnews4.ix.netcom.com>,
>David E. Wallace <wallace@netcom.com> wrote:
>>The only situation?  What English word appears on the display after
>>puts("ca e\b\bp")?
>
>Tom Lehrer wrote a wonderful song about this for Sesame Street.
>
>>Is \b a destructive or non-destructive backspace?
>
>Yes.

No :-)

Seriously.  It could be a constructive backspace, such as a few
languages dabbled with some 30 years back.


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              ]

In article <7tbcdr$l4d@dfw-ixnews4.ix.netcom.com>,
David E. Wallace <wallace@netcom.com> wrote:
>The only situation?  What English word appears on the display after
>puts("ca e\b\bp")?

Tom Lehrer wrote a wonderful song about this for Sesame Street.

>Is \b a destructive or non-destructive backspace?

Yes.

-s
--
Copyright 1999, All rights reserved.  Peter Seebach / seebs@plethora.net
C/Unix wizard, Pro-commerce radical, Spam fighter.  Boycott Spamazon!
Will work for interesting hardware.  http://www.plethora.net/~seebs/
Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam!
---
[ 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:
> Hyman Rosen wrote:
> > Pete Becker <petebecker@acm.org> writes:
> > > However, their meanings are clearly specified. That's in sharp contrast
> > > to the meaning of a character sequence that begins with \e.
> > What is the meaning of puts("\n\b")? Why is that any more or less
> > satisfactory than the (proposed) meaning of puts("\e[7m")?
> Because that is the only situation in which the intended effect of a
> stirng that contains \b cannot be determined from the standard. Assuming
> the "(proposed) meaning" of \e is "send an ESCAPE character," there is
> nothing you can say about the effect of a string containing \e from
> reading the standard.

So what? The point has always been that people want \e to just send an
escape character. But some people are insisting that \e must be given
a description in the style of the other alphabetic escape sequences. I
proposed one, which essentially says that its effect is unspecified.
The other descriptions allow the behavior to be unspecified in various
circumstances. Once \e is in the standard, vendors will implement it in
a logical and sane manner, just as their customers want, just like they
do for \t, \f, and the others.


[ 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 <37F638F5.4AEEACA9@acm.org>,
Pete Becker  <petebecker@acm.org> wrote:
>Hyman Rosen wrote:
>>
>> Pete Becker <petebecker@acm.org> writes:
>> > However, their meanings are clearly specified. That's in sharp contrast
>> > to the meaning of a character sequence that begins with \e.
>>
>> What is the meaning of puts("\n\b")? Why is that any more or less
>> satisfactory than the (proposed) meaning of puts("\e[7m")?
>
>Because that is the only situation in which the intended effect of a
>stirng that contains \b cannot be determined from the standard. Assuming
>the "(proposed) meaning" of \e is "send an ESCAPE character," there is
>nothing you can say about the effect of a string containing \e from
>reading the standard.

The only situation?  What English word appears on the display after
puts("ca e\b\bp")?  Is \b a destructive or non-destructive backspace?
Is it an African or European swallow? :-)

--
Dave Wallace  (wallace@netcom.com)
It is quite humbling to realize that the storage occupied by the longest
line from a typical Usenet posting is sufficient to provide a state space
so vast that all the computation power in the world can not conquer it.


[ 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 <37F297AE.9DE7E4FE@acm.org>, Pete Becker <petebecker@acm.org> writes:
|> Paul Jarc wrote:
|> >
|> > Pete Becker <petebecker@acm.org> writes:
|> > > And here's the followup question, which nobody has answered: given this
|> > > definition, what can you do that uses \e in a non-trivial way?
|> >
|> > register, inline, getenv, fopen, and many other features can have
|> > trivial implementations.
|>
|> However, their meanings are clearly specified. That's in sharp contrast
|> to the meaning of a character sequence that begins with \e.

To quote the standard:

       [#2] The  getenv  function  searches  an  environment  list,
       provided  by the host environment, for a string that matches
       the string pointed to by name.  The set of environment names
       and  the  method  for  altering  the  environment  list  are
       implementation-defined.

which should be compared with something like:

       \e (escape) Indicates that an implementation-defined action
       will be performed.  The set of actions and the number of
       characters preceding or following the escape character that
       form an escape sequence describing the action are
       implementation-defined.

You clearly have never implemented getenv on a system which has no
concept of a Unix-like environment list, but does have the concept
of an environment.


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              ]

Paul Jarc wrote:
>
> Pete Becker <petebecker@acm.org> writes:
> > Paul Jarc wrote:
> > > register, inline, getenv, fopen, and many other features can have
> > > trivial implementations.
> >
> > However, their meanings are clearly specified.
>
> If you want to call that "meaning".  register and inline are ignorable
> suggestions that the compiler do something it could do anyway, and
> getenv and fopen really don't say anything more than "give me whatever
> you wish to give me".
>
> > That's in sharp contrast to the meaning of a character sequence that
> > begins with \e.
>
> What about a token sequence that begins with #pragma?  Is it any more
> well-defined than a \e character sequence?

The effect of a #pragma directive is implementation-defined. Some folks
have suggested that the effect of every character sequence that begins
with \e should be implemenation-defined. That gives the same degree of
information, but is impractical.

> Does it belong in the
> standard any more?

Some folks think that #pragma should not be in the standard. Was it GNU
C that used to start a game of nethack when it encountered a #pragma?

--
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 J. Littleboy" wrote:
...
> Exactly. The standard is broken; however, it's only broken under the
> interpretation that "execution character set" does _not_ mean target
> platform character set (or more precisely: subset of the target platform
> character set specifically mentioned in the C standard). I find that
> interpretation completely weird. If the standard had intended that C talk
> internally in a character set other than the target character set it would
> have talked about three, not two, character sets.

Implicitly, it does. That's one of the reason why most I/O is
implementation  defined (or worse). You should be able to read back what
you write out, but it's outside the scope of the standard to say what
the output looks like on disk.
Among (many) other things, C is meant to be implementable even on
machines where "platform character set" is a meaningless concept.
---
[ 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:
> And where in the standard does it say that this is not allowed?
> >
> > It's understood, by compiler makers and compiler users, that on ASCII
> > platforms '\a' is 7, '\b' is 8, \t is 9, and so forth.
>
> It is commonly done, of course. But you seem to be suggesting that it is
> required, which it is not.

This is exactly my point. It is *not* required by the C standard, yet
any other implementation would be considered so seriously broken that
it would never see the light of day. Every implementor looks at the C
standard, goes "uh-huh" and then implements alphabetic escape sequences
as specified by the C++ standard.


[ 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:
>
> Paul Jarc wrote:
> > What about a token sequence that begins with #pragma?  Is it any more
> > well-defined than a \e character sequence?
>
> The effect of a #pragma directive is implementation-defined. Some folks
> have suggested that the effect of every character sequence that begins
> with \e should be implemenation-defined. That gives the same degree of
> information, but is impractical.
>
> > Does it belong in the
> > standard any more?
>
> Some folks think that #pragma should not be in the standard. Was it GNU
> C that used to start a game of nethack when it encountered a #pragma?

I think that's only when -fsurprising-user-is-good and
-fpragma-starts-nethack are both on the command line.

Objecting to #pragma on theoretical/theological grounds while supporting
"computed goto", nested functions, "x?:y", and the like seems, at best,
inconsistent, doesn't it?

On the other hand, at least gcc doesn't have much moral ground on which
to object to '\e'.

- Russell "Come on, people, laugh" 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              ]

Pete Becker <petebecker@acm.org> writes:
> That's one way to spin it. I'd prefer "it gives a portable way to get a
> non-portable result." Which, of course, is a contradiction.

But from your point of view, no use of a character escape sequence
is portable! That is, suppose the compiler decided to represent \n
as the character of value 1, and on output did the isatty test and
wrote CR-LF for that value only to displays, and wrote 1 otherwise.
That seems perfectly acceptable according to the standard, but text
files written in this way would be completely incompatible with the
rest of the system.

It's understood, by compiler makers and compiler users, that on ASCII
platforms '\a' is 7, '\b' is 8, \t is 9, and so forth. Any compiler
that chose not to conform to this would not be used. The attempt by
the C standard to describe character escape sequences by their effect
is quixotic. C++ got it exactly right.
---
[ 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:
> Paul Jarc wrote:
> > register, inline, getenv, fopen, and many other features can have
> > trivial implementations.
>
> However, their meanings are clearly specified.

If you want to call that "meaning".  register and inline are ignorable
suggestions that the compiler do something it could do anyway, and
getenv and fopen really don't say anything more than "give me whatever
you wish to give me".

> That's in sharp contrast to the meaning of a character sequence that
> begins with \e.

What about a token sequence that begins with #pragma?  Is it any more
well-defined than a \e character sequence?  Does it belong in the
standard any more?


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              ]

Hyman Rosen wrote:
>
> Pete Becker <petebecker@acm.org> writes:
> > That's one way to spin it. I'd prefer "it gives a portable way to get a
> > non-portable result." Which, of course, is a contradiction.
>
> But from your point of view, no use of a character escape sequence
> is portable! That is, suppose the compiler decided to represent \n
> as the character of value 1, and on output did the isatty test and
> wrote CR-LF for that value only to displays, and wrote 1 otherwise.
> That seems perfectly acceptable according to the standard, but text
> files written in this way would be completely incompatible with the
> rest of the system.

And where in the standard does it say that this is not allowed?

>
> It's understood, by compiler makers and compiler users, that on ASCII
> platforms '\a' is 7, '\b' is 8, \t is 9, and so forth.

It is commonly done, of course. But you seem to be suggesting that it is
required, which it is not.

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

Pete Becker <petebecker@acm.org> writes:
> However, their meanings are clearly specified. That's in sharp contrast
> to the meaning of a character sequence that begins with \e.

What is the meaning of puts("\n\b")? Why is that any more or less
satisfactory than the (proposed) meaning of puts("\e[7m")?


[ 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 in message <37F41D55.CE37616C@acm.org>...
>
>Hyman Rosen wrote:
>> But from your point of view, no use of a character escape sequence
>> is portable! That is, suppose the compiler decided to represent \n
>> as the character of value 1, and on output did the isatty test and
>> wrote CR-LF for that value only to displays, and wrote 1 otherwise.
>> That seems perfectly acceptable according to the standard, but text
>> files written in this way would be completely incompatible with the
>> rest of the system.
>
>And where in the standard does it say that this is not allowed?

Exactly. The standard is broken; however, it's only broken under the
interpretation that "execution character set" does _not_ mean target
platform character set (or more precisely: subset of the target platform
character set specifically mentioned in the C standard). I find that
interpretation completely weird. If the standard had intended that C talk
internally in a character set other than the target character set it would
have talked about three, not two, character sets.

>> It's understood, by compiler makers and compiler users, that on ASCII
>> platforms '\a' is 7, '\b' is 8, \t is 9, and so forth.
>
>It is commonly done, of course. But you seem to be suggesting that it is
>required, which it is not.

As others have pointed out: it is if you want to sell the compiler.

David J. Littleboy
Tokyo, Japan
davidjl <at> gol <dot> com
@glowing.in.the.dark.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              ]

Nick Maclaren wrote:
>
> You clearly have never implemented getenv on a system which has no
> concept of a Unix-like environment list, but does have the concept
> of an environment.
>

I fail to see how an offhand statement about the meaning of a library
function could lead anyone to such a conclusion, nor do I see the
relevance of that conclusion, even if it were correct. The discussion is
about what the standard means, and that can be understood without having
implemented everything that is discusses. On the other hand, having
implemented a C library does not necessarily make someone infallible.

--
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 <37F50694.BADCB618@rahul.net>,
Russell Bornschlegel  <kaleja@rahul.net> wrote:
>Pete Becker wrote:
>> Some folks think that #pragma should not be in the standard. Was it GNU
>> C that used to start a game of nethack when it encountered a #pragma?

>I think that's only when -fsurprising-user-is-good and
>-fpragma-starts-nethack are both on the command line.

Maybe.  It used to be a default.  :)

>Objecting to #pragma on theoretical/theological grounds while supporting
>"computed goto", nested functions, "x?:y", and the like seems, at best,
>inconsistent, doesn't it?

Ahh, but all of those are *usable* extensions; if a compiler supports them,
they add functionality to the language itself.  (Well, actually, I'm really
unsure about nested functions personally, but I *would* use their ?: if
it were available to me.)

>On the other hand, at least gcc doesn't have much moral ground on which
>to object to '\e'.

Heh.  Well, consider that it's also a C++ compiler; I can't see *any* C++
compiler vendor complaining about a "gratuitous" language feature.

>- Russell "Come on, people, laugh" Bornschlegel

Hee hee.

-s
--
Copyright 1999, All rights reserved.  Peter Seebach / seebs@plethora.net
C/Unix wizard, Pro-commerce radical, Spam fighter.  Boycott Spamazon!
Will work for interesting hardware.  http://www.plethora.net/~seebs/
Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam!
---
[ 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 J. Littleboy" wrote:
>
> Pete Becker wrote in message <37F41D55.CE37616C@acm.org>...
> >
> >Hyman Rosen wrote:
> >> But from your point of view, no use of a character escape sequence
> >> is portable! That is, suppose the compiler decided to represent \n
> >> as the character of value 1, and on output did the isatty test and
> >> wrote CR-LF for that value only to displays, and wrote 1 otherwise.
> >> That seems perfectly acceptable according to the standard, but text
> >> files written in this way would be completely incompatible with the
> >> rest of the system.
> >
> >And where in the standard does it say that this is not allowed?
>
> Exactly. The standard is broken; however, it's only broken under the
> interpretation that "execution character set" does _not_ mean target
> platform character set (or more precisely: subset of the target platform
> character set specifically mentioned in the C standard). I find that
> interpretation completely weird. If the standard had intended that C talk
> internally in a character set other than the target character set it would
> have talked about three, not two, character sets.

That would be one way to do it. Another way would be to talk about the
effects of writing source code strings to devices, which is the approach
that the standard takes.

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

Hyman Rosen wrote:
>
> Pete Becker <petebecker@acm.org> writes:
> > However, their meanings are clearly specified. That's in sharp contrast
> > to the meaning of a character sequence that begins with \e.
>
> What is the meaning of puts("\n\b")? Why is that any more or less
> satisfactory than the (proposed) meaning of puts("\e[7m")?

Because that is the only situation in which the intended effect of a
stirng that contains \b cannot be determined from the standard. Assuming
the "(proposed) meaning" of \e is "send an ESCAPE character," there is
nothing you can say about the effect of a string containing \e from
reading the standard.

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

James Dennett wrote:
>
> I should have been more precise.  I meant that of those who are arguing for the
> inclusion of \e in the Standard, none are doing so because they want the Standard
> to dictate the effect it will have on a display device.  Therefore, I see no
> reason for the Standard to impose any requirement on what the implementation
> should do if \e is sent to a display device.

Then \e will be the only character for which this is true. That is, it's
a big wart.

> > But that's exactly the problem: they're outside the scope of the
> > standard. Saying that \e produces some character whose value and meaning
> > are outside of the standard doesn't look to me like it accomplishes much
> > of anything.
>
> It does two things:
> It gives a portable way to get a not-completely-portable result,

That's one way to spin it. I'd prefer "it gives a portable way to get a
non-portable result." Which, of course, is a contradiction.

--
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 Jarc wrote:
>
> Pete Becker <petebecker@acm.org> writes:
> > And here's the followup question, which nobody has answered: given this
> > definition, what can you do that uses \e in a non-trivial way?
>
> register, inline, getenv, fopen, and many other features can have
> trivial implementations.

However, their meanings are clearly specified. That's in sharp contrast
to the meaning of a character sequence that begins with \e.

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

Pete Becker wrote:

> James Dennett wrote:
> >
> > Pete Becker wrote:
> >
> > > David R Tribble wrote:
> >
> > > > I've gotten a little lost in these diversions talking about CR/LF
> > > > and device drivers and DOS and \v and \a and on and on, none of which
> > > > has any real bearing on the issue at hand.  Just exactly what is your
> > > > reason for objecting to adding \e to ISO C?
> > > >
> > >
> > > I haven't gotten a satisfactory explanation of what it is expected to
> > > do.
> >
> > How about:  The effect of writing \e to a stream is implementation-defined.
> > (With a note to the effect that sensible behavior would be to write a
> > natural ESC character to the target, or a no-op if this is not applicable.)
>
> And here's the followup question, which nobody has answered: given this
> definition, what can you do that uses \e in a non-trivial way?
>

Send it to a known device, possibly through a driver which maps from the host's
natural character set to that of the device, to perform a device-specific
action.  There are quite a few of those, I believe.

> > AFAIK, nobody wants the C/C++ Standards to prescribe the effect of \e on a
> > display device
>
> I do, if \e is going to be defined in the standard. That's the way all
> the escape character sequences are specified in the C standard.

I should have been more precise.  I meant that of those who are arguing for the
inclusion of \e in the Standard, none are doing so because they want the Standard
to dictate the effect it will have on a display device.  Therefore, I see no
reason for the Standard to impose any requirement on what the implementation
should do if \e is sent to a display device.

>
> > -- just to allow them to send it to a device if they have
> > some other way of knowing the effect.  So long as you ask what the effect on
> > the display should be, you are avoiding the issue; the whole point of this
> > is the ability to access, in a portable manner, devices whose behavior is
> > outside the scope of the Standard.
>
> But that's exactly the problem: they're outside the scope of the
> standard. Saying that \e produces some character whose value and meaning
> are outside of the standard doesn't look to me like it accomplishes much
> of anything.

It does two things:
It gives a portable way to get a not-completely-portable result, by giving access
to the ESC character of the execution environment (if such a character exists).
It makes code which uses the ESC character easier to write and (more importantly)
easier to read.

> > On a wide range of platforms, the
> > specification above is quite clear enough to allow an implementor to write
> > code, and should be adequate to satisfy the needs of users.
> >
> > Is there scope in a language standard to define behavior as above which is
> > _intended_ behavior across a wide range of machines but cannot apply to
> > all?  I hope so.  If not, maybe this is an issue which bodies such as POSIX
> > need to address.
> >
>
> The C standard does just that:
>
>         \t (horizontal tab) Moves the active position to the next
>                 horizontal tabulation position on the current line.
>

Then what's so bad about expressing intent only for the case where the stream is
passing through to a file/device managed by the host OS, except that the Standard
tends not to distinguish between the language support environment and the
OS which underlies it?

-- James Dennett <jdennett@acm.org>



[ 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:
> And here's the followup question, which nobody has answered: given this
> definition, what can you do that uses \e in a non-trivial way?

register, inline, getenv, fopen, and many other features can have
trivial implementations.  Do you think they should be removed from the
standard?  There is much in the standard that is not specified fully
enough to be practically useable without extra knowledge of the
implementation.  \e would not be a serious wart in comparison.

> > AFAIK, nobody wants the C/C++ Standards to prescribe the effect of \e on a
> > display device
>
> I do, if \e is going to be defined in the standard. That's the way all
> the escape character sequences are specified in the C standard.

Another option would be to specify its effect on some other kind of
device.  There's no need for display devices to be special.  They just
happen to be very common.


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 Dennett wrote:
>
> Pete Becker wrote:
>
> > David R Tribble wrote:
>
> > > I've gotten a little lost in these diversions talking about CR/LF
> > > and device drivers and DOS and \v and \a and on and on, none of which
> > > has any real bearing on the issue at hand.  Just exactly what is your
> > > reason for objecting to adding \e to ISO C?
> > >
> >
> > I haven't gotten a satisfactory explanation of what it is expected to
> > do.
>
> How about:  The effect of writing \e to a stream is implementation-defined.
> (With a note to the effect that sensible behavior would be to write a
> natural ESC character to the target, or a no-op if this is not applicable.)

And here's the followup question, which nobody has answered: given this
definition, what can you do that uses \e in a non-trivial way?

>
> AFAIK, nobody wants the C/C++ Standards to prescribe the effect of \e on a
> display device

I do, if \e is going to be defined in the standard. That's the way all
the escape character sequences are specified in the C standard.

> -- just to allow them to send it to a device if they have
> some other way of knowing the effect.  So long as you ask what the effect on
> the display should be, you are avoiding the issue; the whole point of this
> is the ability to access, in a portable manner, devices whose behavior is
> outside the scope of the Standard.

But that's exactly the problem: they're outside the scope of the
standard. Saying that \e produces some character whose value and meaning
are outside of the standard doesn't look to me like it accomplishes much
of anything.

> On a wide range of platforms, the
> specification above is quite clear enough to allow an implementor to write
> code, and should be adequate to satisfy the needs of users.
>
> Is there scope in a language standard to define behavior as above which is
> _intended_ behavior across a wide range of machines but cannot apply to
> all?  I hope so.  If not, maybe this is an issue which bodies such as POSIX
> need to address.
>

The C standard does just that:

 \t (horizontal tab) Moves the active position to the next
  horizontal tabulation position on the current line.

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

James Dennett <jdennett@acm.org> writes:
> How about:  The effect of writing \e to a stream is implementation-defined.
> (With a note to the effect that sensible behavior would be to write a
> natural ESC character to the target, or a no-op if this is not applicable.)

That note is no good.  The whole approach "we'll just pass it on to
the next level" is no good, because the level that does the passing
*isn't* the level that the standard is talking about.  The standard
recommends certain behavior of display devices, and *something*,
*somewhere*, catches the \n's, \t's, \a's, etc. (regardless of how
they are represented at that point), and handles them intelligently,
usually more or less the way the standard describes.  That same
something also typically already handles the escape character, and the
behavior in that instance is what should be described in the standard.
(The behavior in that instance varies widely, so `implementation-
defined' is about all we can say.)

> So long as you ask what the effect on the display should be, you are
> avoiding the issue; the whole point of this is the ability to
> access, in a portable manner, devices whose behavior is outside the
> scope of the Standard.

In which case, the behavior of the device (or an approximation of it)
is *exactly* what needs to be decribed in the standard.  Otherwise,
you don't have any guarantee, recommendation, or even suggestion that
a control character will do what you want it to do.

> Is there scope in a language standard to define behavior as above which is
> _intended_ behavior across a wide range of machines but cannot apply to
> all?

The behavior for all escape sequences is expressed as intent.


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 wrote:
>
> Pete Becker wrote:
> [...]
> > And if that's the definition, what can you use \e for in portable
> > code? Whether it's undefined or implementation defined, you cannot
> > write a \e to a display device and expect any particular result
> > unless you have read your vendor's documentation and they have told
> > you what to expect.
>
> And how does that make \e different from \v or \a?

\v and \a have defined behavior, that sometimes can't be implemented
reasonably. \e has no defined behavior whatsoever.

>
> I've gotten a little lost in these diversions talking about CR/LF
> and device drivers and DOS and \v and \a and on and on, none of which
> has any real bearing on the issue at hand.  Just exactly what is your
> reason for objecting to adding \e to ISO C?
>

I haven't gotten a satisfactory explanation of what it is expected to
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              ]

Pete Becker wrote:
[...]
> And if that's the definition, what can you use \e for in portable
> code? Whether it's undefined or implementation defined, you cannot
> write a \e to a display device and expect any particular result
> unless you have read your vendor's documentation and they have told
> you what to expect.

And how does that make \e different from \v or \a?

I've gotten a little lost in these diversions talking about CR/LF
and device drivers and DOS and \v and \a and on and on, none of which
has any real bearing on the issue at hand.  Just exactly what is your
reason for objecting to adding \e to ISO 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              ]