mq@maq.org (Michael Quinlan) writes:
> What would implementations that use a non-ASCII/non-EBCDIC character set do
> for '\e'?

Whatever was appropriate for that platform. Users of that platform
would have some expectation, and the vendor would implement it. If
there was truly no meaningful translation at all, the vendor would
pick an arbitrary value, and no user on that platform would use it.

> Also, all of the cases that I am aware of (VT100, HPCL, etc.) actually require
> a specific bit pattern that happens to correspond to the ASCII Escape
> character. Since a specific bit pattern is required, it would be most portable
> to code it '\033' (or equivalent).

Those same terminals require a specific bit pattern that happens to
correspond to ASCII HT in order to move the cursor to the next tab
stop. So it would be most portable to code that as '\011'. Oddly
enough, most people prefer to use '\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              ]

David R Tribble <david@tribble.com> wrote:

>Yeah, that was more or less the committee response when I suggested
>that we needed an '\e' character sequence years ago.  Apparently,
>no one has been clever enough to come up with a written description
>of the semantics of the control character ESC, even though everyone
>damn well knows what it means.

What would implementations that use a non-ASCII/non-EBCDIC character set do
for '\e'?

Also, all of the cases that I am aware of (VT100, HPCL, etc.) actually require
a specific bit pattern that happens to correspond to the ASCII Escape
character. Since a specific bit pattern is required, it would be most portable
to code it '\033' (or equivalent).

--
No electrons were injured in the preparation of this message.
Michael Quinlan         mq@maq.org         http://www.maq.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              ]

Hyman Rosen <hymie@prolifics.com> writes:
> Paul Jarc <prj@po.cwru.edu> writes:
> > It is specifically implementing the C display semantics.  That is, the
> > purpose of the translation is to get the desired display effects.
> > Performing the translation for all text streams, rather than just
> > those directed at display devices, is just for convenience.  It allows
> > a text file's contents to be sent straight to the display device
> > without needing any (additional) translation.  As you say, it's no
> > coincidence that the translation performed on text streams is the same
> > one required to get the desired display effects.
>
> No, you have it backwards. It is specifically implementing text-file
> translation so that C programs can maintain the illusion that text
> file lines are terminated by a single character instead of two.

Why do you think these text files use two-character line endings?  To
conform to the host system's conventions, yes, but what motivated
those conventions?  The filesystem doesn't care about the content of
its data, does it?  The translation is done for the ultimate purpose
of achieving the desired display effects.  That purpose pervades the
system; it isn't limited to C's text file translation; but it is what
that translation is based 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              ]

Hyman Rosen <hymie@prolifics.com> writes:
> At my terminal, I type 'stty -onlcr olcuc' (or somesuch).
> Then this C program -
>  int main() { return printf("abc\ndef\nghi\n"); }
> prints
>  ABC
>            DEF
>               GHI
> which is clearly violating the rules of printing to a display.
> So is something broken here?

If the implementation documents that this terminal is a display device
and that it produces the standard's intended display effects, then
yes, something is broken.  But it's not the implementation's fault.
C9X 3.10p1:
# implementation
# a particular set of software, running in a particular translation
# environment under particular control options, that performs
# translation of programs for, and supports execution of functions in,
# a particular execution environment

By changing the "control options", or "execution environment", or
however you wish to classify stty settings, you've destroyed this
instance of an implementation.  Fortunately, it's a reversible
destruction.  It's like compiling with `gcc' instead of
`gcc -ansi -pedantic -...'.

> The C standard says that what is considered a display is
> implementation-defined.

I don't think the standard says even that - "display device" has to be
interpreted by common sense, I guess.

> So if my C vendor said that a display is defined to be a DEC VT100
> terminal, that would be fine as well.

Yes, that's another way the implementation could go.  In any case,
this isn't a conformance problem for the implementation.


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:
>
> Larry Jones wrote:
> >
> > Pete Becker (petebecker@acm.org) wrote:
> > >
> > > But that's the point: in order to know what this code does (as opposed
> > > to what the function names suggest that it does) you have to invoke
> > > magic. I don't see any other place in the standard that does that.
> >
> > Code compiled in the presence of a #pragma.  \e would have exactly the
> > same effect on the interpretation of the following characters as #pragma
> > has on the interpretation of the following code.  They're both standard
> > ways of invoking nonstandard behavior.
> >
>
> Since the effect of #pragma is implementation defined, you're saying
> that the result of writing any sequence of characters that contains a \e
> to any output device should also be defined by the implementation. I
> think you'll hear screams from compiler vendors if they are required to
> document the effects of every possible escape sequence on all devices
> that could be attached to the system.

If the device is part of your implementation, then the
device documentation is part of the the implementation
documentation as well. That is, if your printer manual
documents the codes, it suffices.
Of course this means that adding a printer to your system
which doesn't come with the needed documantation makes the
implementation non-conforming. But so does replacement of
the libraries coming with the compiler by other,
non-conforming ones. If you do that, it's not the problem
of the compiler vendor, but the problem of the vendor of
the component making your system non-conforming (i.e. the
printer vendor in the printer case, and the library vendor
in the library case).
Or do you really think the vendor has to document "If you
replace the libraries coming with this compiler with the
libraries of vendor Foo, the following implementation
defined behaviours will change..."?

If the implementation consists of several parts from
different vendors, then it's the duty of the vendor of
each part to document just his part. The compiler vendor
does not need to document all devices which might be
used, just as the printer vendor doesn't need to add
documentation of every program which might print to 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              ]

Paul Jarc <prj@po.cwru.edu> writes:
> Why do you think these text files use two-character line endings?  To
> conform to the host system's conventions, yes, but what motivated
> those conventions?

Beats me. UNIX, with its single-character line terminators already
existed when MS-DOS  first came out. Maybe it was to be compatible
with CP/M. Certainly, under MS-DOS, CR-LF has nothing to do with
the display, which after all is memory-mapped!


[ 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:
> Why do you think these text files use two-character line endings?

Hyman Rosen:
> Beats me. UNIX, with its single-character line terminators already
> existed when MS-DOS first came out. Maybe it was to be compatible
> with CP/M.

PC-DOS 1.0 was essentially a CP/M for the PC.  The UNIXisms didn't
start appearing in MS-DOS until version 2.

     - John Hauser
---
[ 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 <a3uK3.565$N64.15174@dfw-read.news.verio.net>,
T.E.Dickey <dickey@shell.clark.net> wrote:
>In comp.std.c Hyman Rosen <hymie@prolifics.com> wrote:
>
>> Paul Jarc <prj@po.cwru.edu> writes:
>>> Why do you think these text files use two-character line endings?  To
>>> conform to the host system's conventions, yes, but what motivated
>>> those conventions?
>
>> Beats me. UNIX, with its single-character line terminators already
>> existed when MS-DOS  first came out. Maybe it was to be compatible
>> with CP/M. Certainly, under MS-DOS, CR-LF has nothing to do with
>> the display, which after all is memory-mapped!
>
>besides borrowing from Unix, MS-DOS also borrowed extensively from other
>sources (such as DEC's operating systems).  Those used CR-LF.

While I doubt it mattered to Microsoft, the ASCII standard recommends
use of CR-LF as the representation of the end of a line.  That is not
surprising, since ASCII is derived from IA-5.

     Sincerely,
     Bob Corbett


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

Antoine Leca <Antoine.Leca@renault.fr> wrote in message
news:37F86D26.4F7EAF8A@renault.fr...
> Greg Brewer ha escrit:
> > Why do we keep missing the \f sequence which has not meaning in the context
> > of a monitor?
> I used implementations where a \f code sent to the screen did clear the screen.
> I am not sure it is not conforming.

I doubt that it was conforming on 2 counts.

First, it did not perform the action required by the specification.  I
conceed that it was an appropriate approximation; however, it was not the
specific action.

Second, I doubt the implementation did anything other than send the formfeed
character to the OS and the driver for the display cleared the screen.  The
OS could just as easily have responded by having the monitor whistle "Dixie"
for all the control the implimentation had over the situation.

Greg Brewer




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

Greg Brewer wrote:
>
> Antoine Leca <Antoine.Leca@renault.fr> wrote in message
> news:37F86D26.4F7EAF8A@renault.fr...
> > Greg Brewer ha escrit:
> > > Why do we keep missing the \f sequence which has not meaning in the context
> > > of a monitor?
> > I used implementations where a \f code sent to the screen did clear the screen.
> > I am not sure it is not conforming.
>
> I doubt that it was conforming on 2 counts.
>
> First, it did not perform the action required by the specification.  I
> conceed that it was an appropriate approximation; however, it was not the
> specific action.

"logical page" is not defined by the standard; why should it not be
defined by the implementor in this fashion?

> Second, I doubt the implementation did anything other than send the formfeed
> character to the OS and the driver for the display cleared the screen.  The
> OS could just as easily have responded by having the monitor whistle "Dixie"
> for all the control the implimentation had over the situation.

The monitor and it's device driver (if any) are parts of the
implementation.


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

"Greg Brewer" <nospam.greg@brewer.net> writes:
> Antoine Leca <Antoine.Leca@renault.fr> wrote in message
> news:37F86D26.4F7EAF8A@renault.fr...
> > I used implementations where a \f code sent to the screen did
> > clear the screen.  I am not sure it is not conforming.
>
> I doubt that it was conforming on 2 counts.
>
> First, it did not perform the action required by the specification.  I
> conceed that it was an appropriate approximation; however, it was not the
> specific action.

What would the specific action be in this case?  What constitutes a
logical page on a monitor?  Even if you think the display action is
required, that doesn't imply that the requirement makes sense and
actually means something in any particular situation.

> Second, I doubt the implementation did anything other than send the formfeed
> character to the OS and the driver for the display cleared the screen.  The
> OS could just as easily have responded by having the monitor whistle "Dixie"
> for all the control the implimentation had over the situation.

No, the implementation has complete control.  The reason this
statement confuses you is that you don't know what an implementation
is.  You think you do, but you don't.  An implementation is not just a
compiler and a library.  An implementation is (C9X 3.10p1):
# a particular set of software, running in a particular translation
# environment under particular control options, that performs
# translation of programs for, and supports execution of functions in,
# a particular execution environment

An implementation may include a compiler, a library, and whatever else
is required to make programs behave properly (OS, etc.).  There is
nothing below the implementation; it's implementation all the way
down.


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 <hymie@prolifics.com> writes:
> Paul Jarc <prj@po.cwru.edu> writes:
> > No, it is part of the "runtime system".  The terminal driver that does
> > the interpretation is part of the implementation too, because it is a
> > necessary piece of the puzzle.  The interpretation isn't in cc, and
> > it's not in libc.a, but that doesn't mean it's not in the
> > implementation.
>
> Apart from this view being totally ridiculous,

The reason that it seems ridiculous to you is that you don't know what
an implementation is.  You think you do, but you don't.  An
implementation is not just a compiler and library.  It is (C9X 3.10p1):
# a particular set of software, running in a particular translation
# environment under particular control options, that performs
# translation of programs for, and supports execution of functions in,
# a particular execution environment

Which is to say, it includes whatever it needs to include to get the
job done.  Anything that your program relies on, including but not
limited to compiler, library, OS kernel, device drivers, etc., is part
of the implementation.

The standard commandeered the word "implementation" and used it in a
way different from what you might expect.  This can cause some
confusion.  Fortunately, the standard says exactly what it means by
"implementation".  So although it may be a bit uncomfortable to
suspend our common-sense understanding of the word, we are told
exactly how to do so for the purposes of understanding the standard.

> the system is in fact not obeying the rules in the C standard.

How so?  Which rules?


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:
> Hyman Rosen <hymie@prolifics.com> writes:
> How many times do I have to repeat this?  You can't just say "pass it
> on to the next level", because the standard is talking about the level
> that *doesn't* just pass it on.  You may not be accustomed to thinking
> of that level as part of your C implementation, but it is, or can be.
>
> > Does your compiler document the effect of puts("\n\b")?
>
> # \n (new line) Moves the active position to the initial position of
> #    the next line.
>
> # \b (backspace) Moves the active position to the previous position on
> #    the current line.  If the active position is at the initial
> #    position of a line, the behavior is unspecified.
>                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^

This is what the C standard could say -

"\e (escape) The effect of writing this character followed by an unspecified
    number (including zero) of characters is unspecified, regardless of the
    other provisions of this section."

Notice that it permits unspecified behavior in some circumstances, just like
the description of \b. In some sense, \e is "more unspecified" than \b, but
what of that?

What I wrote is what the vendor's implementation documentation could say -

"The effect of writing \e to a FILE * is to pass the character through to
 the underlying output stream unmodified."


[ 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:
> It is specifically implementing the C display semantics.  That is, the
> purpose of the translation is to get the desired display effects.
> Performing the translation for all text streams, rather than just
> those directed at display devices, is just for convenience.  It allows
> a text file's contents to be sent straight to the display device
> without needing any (additional) translation.  As you say, it's no
> coincidence that the translation performed on text streams is the same
> one required to get the desired display effects.

No, you have it backwards. It is specifically implementing text-file
translation so that C programs can maintain the illusion that text
file lines are terminated by a single character instead of two. It
happens that treating the display like a text file gives desireable
behavior.
---
[ 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:
> Sure, that's easy. Trouble is, it doesn't say anything. What is this
> "it" that is being passed through to the underlying write system call?
> What is the "underlying write system call"? In particular, for an
> embedded system with a memory mapped display device that is driven
> directly by the application program, there would not be any "underlying
> write system call."

I was describing what the vendor's implementation documentation might say.
For the typical MS/Unix implementation, "it" is a byte with value 27, and
the "underlying write system call" is a call to _write (or some such) which
instructs the operating system to deliver a buffer of characters to a device
driver associated with an open file descriptor.

For an embedded system with a memory mapped display device that is driven
directly by the application program, there would be a different description,
possibly referring you to the chapter where the description of the following
code appears -

 unsigned char c = 0; do putchar(c++); while (c);
---
[ 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:
> Hyman Rosen <hymie@prolifics.com> writes:
> > the system is in fact not obeying the rules in the C standard.
> How so?  Which rules?

At my terminal, I type 'stty -onlcr olcuc' (or somesuch).
Then this C program -
 int main() { return printf("abc\ndef\nghi\n"); }
prints
 ABC
           DEF
              GHI
which is clearly violating the rules of printing to a display.
So is something broken here? The C standard says that what is
considered a display is implementation-defined. So if my C
vendor said that a display is defined to be a DEC VT100 terminal,
that would be fine as well.

*Shrug*


[ 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:
> No, it is part of the "runtime system".  The terminal driver that does
> the interpretation is part of the implementation too, because it is a
> necessary piece of the puzzle.  The interpretation isn't in cc, and
> it's not in libc.a, but that doesn't mean it's not in the
> implementation.

Apart from this view being totally ridiculous, the system is in fact
not obeying the rules in the C standard. Do you think I should return
my compiler and get a refund?
---
[ 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:
....
> "The effect of writing \e to a FILE * is to pass it through to the
>  underlying write system call unmodified."

That's not really an appropriate style of specification. The
implementation is not just the compiler, or even the linker. It includes
the operating system (if any), the GUI interface (if any), and the
hardware it runs on. The C and C++ standards specify what the
implementation as a whole does with your program. An implementation of C
or C++ ceases to be a conforming one, if any of its essential components
is turned off, destroyed, or placed in a mode (possibly as a result of
damage) that prevents it for any reason from providing the behavior
specified by the standards.

It's inconsistent with the form of the standards to single out one
single component of the implementation (the operating system), which
might not even exist for some implementations, and specify the behavior
in terms of communication between the rest of the components and that
one. That's behavior internal to the implementation, and as such not a
proper subject for standardization.

There's also the problem that an implementation might choose to
implement an encrypted or compressed relationship between the data
passed to and from runtime library I/O functions, and the data that
actually appears in files on disk (or wherever else it stores files).
One very plausible kind of 'encryption' would be a character set
translation. Adding your specification to the standard would make such
relationships very difficult to implement.



[ 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:
....
> "The effect of writing \e to a FILE * is to pass it through to the
>  underlying write system call unmodified."

That's not really an appropriate style of specification. The
implementation is not just the compiler, or even the linker. It includes
the operating system (if any), the GUI interface (if any), and the
hardware it runs on. The C and C++ standards specify what the
implementation as a whole does with your program. An implementation of C
or C++ ceases to be a conforming one, if any of its essential components
is turned off, destroyed, or placed in a mode (possibly as a result of
damage) that prevents it for any reason from providing the behavior
specified by the standards.

It's inconsistent with the form of the standards to single out one
single component of the implementation (the operating system), which
might not even exist for some implementations, and specify the behavior
in terms of communication between the rest of the components and that
one. That's behavior internal to the implementation, and as such not a
proper subject for standardization.

There's also the problem that an implementation might choose to
implement an encrypted or compressed relationship between the data
passed to and from runtime library I/O functions, and the data that
actually appears in files on disk (or wherever else it stores files).
One very plausible kind of 'encryption' would be a character set
translation. Adding your specification to the standard would make such
relationships very difficult to implement.
---
[ 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:
>
> Russell Bornschlegel wrote:
> >
> > Pete Becker wrote:
> > > Since the effect of #pragma is implementation defined, you're saying
> > > that the result of writing any sequence of characters that contains a \e
> > > to any output device should also be defined by the implementation. I
> > > think you'll hear screams from compiler vendors if they are required to
> > > document the effects of every possible escape sequence on all devices
> > > that could be attached to the system.
> >
> > Can you put on your compiler vendor hat and document the effects of
> > the following code:
>
> If I were the compiler vendor I would know what
> "/dev/somethingpetebeckerhasneverheardof" refers to, thus producing a
> contradiction.

Surely not.

Assume for a moment that *you* are vending a compiler for, let's say,
a FreeBSD system. Assume that *I* have written a device driver that
presents to the same system as
"/dev/somethingpetebeckerhasneverheardof".

It's not your job, given these assumptions, to know what a '\t'
does when sent to that device -- that's my point. It's your job to
send the execution character set's best approximation of a "tab"
character to the device driver.

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

Greg Brewer ha escrit:
>
> Why do we keep missing the \f sequence which has not meaning in the context
> of a monitor?

I used implementations where a \f code sent to the screen did clear the screen.
I am not sure it is not conforming.


Antoine
---
[ 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:
> > And if ANSI.SYS is not loaded, it would have to emulate ANSI.SYS.
>
> No. Just like UNIX compilers "do the wrong thing" when the terminal
> is in raw mode.
>
> > I suspect that compiler vendors would lean toward minimal implementations.
>
> Yes, exactly like we all want!
>

Please don't quote out of context. The message that I replied to said:

> > It introduces a device control string. Just as the library contains
> > special code to process \t, \v, \r, \n, \a, and \b into the device-
> > specific output that causes the display position to change or a
> > dialog window to be displayed for the alert, so it will process the
> > strings for device control. The compiler manual will come with that
> > implementation's description of what those strings are.

Clearly this poster does not want a minimal implementation.

--
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:
...
> The problem is that library routines _can't know_ that a particular
> character value was created by an escape sequence or a magic constant. That
> means users will be expecting printf to conform to any semantics associated
> with the target character set. Thus it is _not_ reasonable or feasible for
> an implementation to willy-nilly assign new meanings to code points in the
> target character set.

You seem to be identifying the execution character set with a character
set supported by the platform a program runs on (which I think is what
you mean by "target character set". First of all, there's no reason why
the platfrom must have such a character set. Secondly, there's no need
for it to be the same as the execution character set (though it would
obviously be convenient). It's not possible to access the platform
directly; you can only do so through standard library functions or calls
to functions not covered by the standard. The standard library functions
can perform whatever translations the implementor chooses, so long as it
produces the behavior required by the standard.

Consider an operating system function, let's call it 'open()', that
takes an argument that must be a string using the operating system's
chosen character set. fopen() almost certainly calls this function, but
can do a translation of the character strings passed to it as arguments
before doing so. Furthermore, even if you tried to call open() directly,
it would be perfectly legal for a C implementation to replace calls to
that function with calls to __open(), a wrapper for open() itself that
is defined by the C implementors to perform the necessary translations
on the character string.


[ 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 <37F39D04.2358C8C4@acm.org>,
  Pete Becker <petebecker@acm.org> wrote:
> AllanW wrote:
> >   #pragma foo(bar:baz)
> > Here is a standard way to evoke non-standard behavior. This isn't
> > terribly different than the \e proposal.
>
> Agreed. Many people think that #pragma is a horrible idea.

Who thinks that #pragma is a horrible idea? Why do these people
think this? Are they able to see some horror that I have missed?
Did these horror-viewers talk to the standards committee before
it was made part of the International Standard? If so, why did
the committee make it part of the IS anyway? Is it safe to
assume that the committee members couldn't see as much of the
horror as these horror-viewers were able to see? If so, what
would cause this horror-blindness? Am I also a victim of this
horror-blindness, or am I simply immune to #pragma-horror?

--
Allan_W@my-deja.com is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.


Sent via Deja.com http://www.deja.com/
Before you buy.


[ 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 <37F3CEC0.EBD321E2@acm.org>,
  Pete Becker <petebecker@acm.org> wrote:
> Larry Jones wrote:
> >
> > Pete Becker (petebecker@acm.org) wrote:
> > >
> > > But that's the point: in order to know what this code does (as opposed
> > > to what the function names suggest that it does) you have to invoke
> > > magic. I don't see any other place in the standard that does that.
> >
> > Code compiled in the presence of a #pragma.  \e would have exactly the
> > same effect on the interpretation of the following characters as #pragma
> > has on the interpretation of the following code.  They're both standard
> > ways of invoking nonstandard behavior.
> >
>
> Since the effect of #pragma is implementation defined, you're saying
> that the result of writing any sequence of characters that contains a \e
> to any output device should also be defined by the implementation. I
> think you'll hear screams from compiler vendors if they are required to
> document the effects of every possible escape sequence on all devices
> that could be attached to the system.

Hey, compiler vendors, stop screaming! I have a gift for you
that will eliminate this problem. As written, it describes
what it means to send \e to an output device on a system
where the screen and most peripherals use ASCII; you must
make suitable corrections for other platforms.

This text is hereby dedicated to the public domain. I grant
anyone and everyone permission to use it in any form, modified
or not, royalty-free, provided only that you do NOT attribute
it to me in any way, and that you do not attempt to hold me
responsible for any consequences of either misuse or correct
use of this text.

Note also that I do not know the name of the ANSI document
(originally created circa 1975?) that describes a great many
of these Escape Sequences. Thus, you should at a bare minimum
look up the name of that document, and substitute it's name
for the XXXXXX placeholder I give below.

    The \e character represents the "ESCAPE" character, which
    is Ascii code 27 decimal (1B hexidecimal). The effect of
    using it in a string sent to a device is to transmit the
    ESCAPE character. Typically, the ESCAPE character is the
    first byte of a sequence known as an "Escape Sequence."
    Many (but not all) devices respond to some or all of the
    Escape Sequences that are documented in ANSI document
    XXXXXX. As a simple example, many devices that are
    capable of moving the print position to any row and
    column (such as most video display terminal devices)
    would respond to the Escape Sequence "\e[3;5m" by moving
    to row 3, column 5.

    As Pete Becker pointed out on Internet newsgroups, the
    precise results of using \e cannot be explained in the
    documentation for this compiler. This is because the
    exact result is "device-dependant." This means that
    unfortunately, not all devices recognize Escape
    Sequences. Such devices may ignore the ESCAPE character
    and print the rest of the Escape Sequence as if it were
    meant to be displayed to the user; or it may try to print
    the ESCAPE character, or respond to the ESCAPE character
    in some non-standard way.

    Furthermore, even for devices that do recognize standard
    Escape Sequences, many devices have support for private
    Escape Sequences not defined by ANSI. For older devices,
    these may even conflict with later codes that were
    adopted by ANSI. This means that it is possible that
    using an ANSI-defined Escape Sequence will have results
    other than what ANSI specifies. For that reason, using
    Escape Sequences is not recommended unless your
    application has some way to know the exact type of
    device that it will be communicating with, and can
    react by using the correct Escape Sequences.

    For an exact list of Escape Sequences and other control
    codes supported by any one particular device, consult
    the documentation for that device as supplied by the
    device manufacturer. Alternatively, you can send E-mail
    to Pete Becker at petebecker@acm.org and ask for his
    list, "Top 50 reasons to NOT use \e in your code."

--
Allan_W@my-deja.com is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.


Sent via Deja.com http://www.deja.com/
Before you buy.


[ 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 point is that the C standard, as it exists today, does not prescribe
> the value for any character. The values that characters are translated
> to are implementation defined. That would not be the case for \e, which
> would make it unique.

It would still be implementation-defined, and would be ASCII ESC in
most implementations.

The number of bits in a char is implementation-defined. That does
not prevent it from being eight in almost all implementations.
---
[ 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:
> Since the effect of #pragma is implementation defined, you're saying
> that the result of writing any sequence of characters that contains a \e
> to any output device should also be defined by the implementation. I
> think you'll hear screams from compiler vendors if they are required to
> document the effects of every possible escape sequence on all devices
> that could be attached to the system.

Can you put on your compiler vendor hat and document the effects of
the following code:

  FILE* f;

  f = fopen( "/dev/somethingpetebeckerhasneverheardof", "wt" );

  if (f)
  {
      fputc( '\t', f );
      fclose( f );
  }

...for all possible devices that might be associated with the named
device?

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

Pete Becker <petebecker@acm.org> writes:
> Paul Jarc wrote:
> > No, even if you consider the display effects to be required, the
> > library doesn't have to emulate ansi.sys when ansi.sys isn't loaded -
> > the implementor can just say "ansi.sys is part of this
> > implementation".
>
> And, of course, they'd then have to deal with all the technical support
> calls from peole who want to know where to find the copy of ansi.sys
> that is part of the implementation, since it didn't get installed with
> the compiler.

Well, that's easily solved - let ansi.sys be part of the
implementation, but don't tell the users that.  Alternatively, the
implementation could target the platform "DOS with ansi.sys" rather
than just "DOS".


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              ]

nmm1@cus.cam.ac.uk (Nick Maclaren)  wrote on 23.09.99 in <7scnvh$jmh$1@pegasus.csx.cam.ac.uk>:

> Can you name one where curses could be implemented and termcap/terminfo
> could not?

Anything where you can get all the effects, but not by way of sending
special character sequences to the display. Instead, you'd use some
variant of out-of-band signalling, or maybe you control the actual display
hardware, or whatever.

The point being, curses is an API to the effects, whereas termcap/terminfo
is an API to a means to produce that effect, and assumes that a certain
type of means exists.

Kai
--
http://www.westfalen.de/private/khms/
"... by God I *KNOW* what this network is for, and you can't have it."
  - Russ Allbery (rra@stanford.edu)
---
[ 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) wrote:
>
> Since the effect of #pragma is implementation defined, you're saying
> that the result of writing any sequence of characters that contains a \e
> to any output device should also be defined by the implementation.

I said nothing of the sort; please don't try to put words in my mouth.
What I said was they both affect the interpretation of the following
"stuff" in a way that the standard can't describe.  In the case of
#pragma, the following "stuff" is code that's being interpreted by the
implementation, so requiring the implementation to define the effect is
reasonable.  In the case of \e, the following "stuff" is characters that
are being interpreted by a particular output device, so if anything were
to define the effect, it would have to be the output device; but that's
well outside the scope of a programming language standard.  In neither
case does the standard itself specify any particular effect.

-Larry Jones

I keep forgetting that rules are only for little nice people. -- 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              ]

Pete Becker <petebecker@acm.org> writes:
> The runtime library needs to do what's necessary to create a newline on
> a "normal" system. You can fiddle with the system's settings and defeat
> that behavior if that's what you'd like to do.

The standard doesn't mention "normal" systems. It talks about the
actions of the alphabetic escape sequences on display devices. Do
you mean to tell me that if I modify my terminal settings, I have
turned it into something that's no longer a display device?


[ 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:
> Fine. However, under DOS, there is no character that you can send to the
> OS that will move the output position to the beginning of the next line.
> It's as if your terminal were permanently stuck in that mode. In order
> to get real newlines you'd have to write output strings with both LF and
> CR: puts("\n\r"). And that's not the behavior that users of the compiler
> expect and want.

Sure, but it's no coincidence that DOS text lines are delimited by CR-LF.
Writing \n to a text file turns into writing CR-LF, and it's that handling
that's applied to stdout. There's nothing in the code that's specificly
implementing the C standard display semantics.


[ 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:
> Since the effect of #pragma is implementation defined, you're saying
> that the result of writing any sequence of characters that contains a \e
> to any output device should also be defined by the implementation. I
> think you'll hear screams from compiler vendors if they are required to
> document the effects of every possible escape sequence on all devices
> that could be attached to the system.

"The effect of writing \e to a FILE * is to pass it through to the
 underlying write system call unmodified."

There, that wasn't so hard.

Does your compiler document the effect of puts("\n\b")?


[ 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:
> > But that's the point: in order to know what this code does (as opposed
> > to what the function names suggest that it does) you have to invoke
> > magic. I don't see any other place in the standard that does that.
>
> First of all, who says that stdprn is a display device? It could just
> as easily be a FILE * of something which was opened in binary mode.

Who says it's a display device? The person who wrote the code. See
below, in particular the words "It sends text to a printer in bold
type."

>
> You don't invoke magic, you invoke your implementation's documentation,
> which will tell you the value which \e is given, and the action of the
> runtime when a char of that value is written. The value is going to be
> ASCII ESC and the action is going to be to pass that value to the output
> stream in most implementations.

Please don't quote out of context. The message that I replied to said:

> > It
> > send text to a printer in bold type.  Before sending it, it detects what
> > type of printer is attached by some magical means that are outside the scope
> > of the exercise so that it knows what codes to send.
> >

If you think making this stuff portable doesn't involve magic then your
disagreement is with the person who wrote those words.

--
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:
> From section 1.7 of the ANSI C standard: "A strictly conforming program
> shall use only those features of the language and library specified in
> this standard. It shall not produce output dependent on any unspecified,
> undefined, or implementation-defined behavior, and shall not exceed any
> minimum implementation limit."

Therefore, a strictly conforming program cannot do puts("\t"), since
there is no way of knowing if the active position is at or past the
last defined horizontal tabulation position. So strict conformance
is irrelevant to the \e debate, because the same arguments apply to
\t, which *is* in the 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 in message <37F3CC2E.235ECC9A@acm.org>...

>1. The C standard does not define the effect of writing alphabetic
>escape sequences in terms of what characters are sent to the display
>device, but in terms of the behavior of the display device;

It may appear to do that, but in far stronger language it forces the C
compiler to translate escape sequences into single character objects. What
that means is that those "intended behaviors" are not implemented for
"alphabetic escape sequences" but for individual characters in the target
character set. (It may say "execution", but the concept of an execution
character set (in the sense of being arbitrarily definable by C) is an
untenable fiction. (See below.) Presumably that was intended not to allow C
to hijack the target character set (as I take it you are advocating), but to
impose no requirements on it. That can be done by other wording.)

>2. It is often convenient for the implementor to map alphabetic escape
>sequences to control characters, because control characters can usually
>produce the correct behavior; and

There are really only _two_ character sets, the source (host) and the
"execution" (target) set. The question then arises, how reasonable/feasible
is it for a C implementation to use characters with different semantics from
any semantics implicit or explicit in the definition of the underlying
character set. I submit that it is completely unreasonable to reassign
character meanings from the target set.

>3. If there is no control character that will produce the correct
>behavior, the implementor should produce a sequence of system-dependent
>instructions that produce the correct behavior if it is feasible.

The implementor of the translator must first assign a unique character value
to each escape sequence. Only then does the implementation "produce a
sequence of system-dependent instructions that produce the correct behavior
if it is feasible" as the way the standard library interprets _the
translated value_ of the escape sequence.

The problem is that library routines _can't know_ that a particular
character value was created by an escape sequence or a magic constant. That
means users will be expecting printf to conform to any semantics associated
with the target character set. Thus it is _not_ reasonable or feasible for
an implementation to willy-nilly assign new meanings to code points in the
target character set.

In other words, if the target character set can't support a particular
escape sequence, the only reasonable thing to do is issue a diagnostic to
the effect that it won't work.

Finally, ESC, SI, and SO are used in internationally standardized protocols.
The stance that C only supports writing character data to certain library
routines strikes me as extreme now that there are many places to send
character data other than the KSR33 emulation stipulated by the standard.

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              ]

AllanW wrote:
>
>
>     Alternatively, you can send E-mail
>     to Pete Becker at petebecker@acm.org and ask for his
>     list, "Top 50 reasons to NOT use \e in your code."
>

I have no such list, nor have I said anything to suggest that if it were
added to the standard it should not be used. What I object to is adding
it to the standard in the various fuzzy ways that have been presented
here.

--
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 <37F3CC2E.235ECC9A@acm.org>,
Pete Becker  <petebecker@acm.org> wrote:
>
>Nick Maclaren wrote:
>>
>> A huge number of people believe that, because they have done the
>> first task a couple of times, it equips them to blather on about the
>> second.  I can assure you that it is much harder to get right than
>> you appear to be able to imagine.
>
>Your assurances aren't needed. I'm well aware of that. What I'm not
>aware of is why you think that what I've said here implies anything to
>the contrary. I've said three things:
>
>1. The C standard does not define the effect of writing alphabetic
>escape sequences in terms of what characters are sent to the display
>device, but in terms of the behavior of the display device;

You have got that right.

>2. It is often convenient for the implementor to map alphabetic escape
>sequences to control characters, because control characters can usually
>produce the correct behavior; and

That is more an indication of your restricted experience than anything
else, but it is true for most of the systems (operating and display)
that you will have come across.

>3. If there is no control character that will produce the correct
>behavior, the implementor should produce a sequence of system-dependent
>instructions that produce the correct behavior if it is feasible.

You have completely missed the point, because you have made two
assumptions that ain't so.

    1) You are assuming that the output medium (whether a display
or storage device) uses compatible concepts to those assumed by the
specification of the C control characters.

    2) You are assuming that the specification of the C control
characters is complete and consistent.

The first may be true in your experience, but not in general.  The
second is false in an absolute sense, but the problems caused by
its falseness are not generally serious except when the first
assumption is also false.


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              ]

Christopher Eltschka wrote:
>
> That you don't know what f. g and \n will do any more, unless
> you know the specific implementation of the device you send it to.
> The reason why this is useful is that there are standardized
> devices, on which this sequence will have a well-known effect.
>

I understand why it's useful. I don't understand why it belongs in the
standard, since there is so little that the standard can say about it
and it is simple to handle in user code in much more predictable ways.

--
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 <hymie@prolifics.com> writes:
> Pete Becker <petebecker@acm.org> writes:
> > Fine. However, under DOS, there is no character that you can send to the
> > OS that will move the output position to the beginning of the next line.
> > It's as if your terminal were permanently stuck in that mode. In order
> > to get real newlines you'd have to write output strings with both LF and
> > CR: puts("\n\r"). And that's not the behavior that users of the compiler
> > expect and want.
>
> Sure, but it's no coincidence that DOS text lines are delimited by CR-LF.
> Writing \n to a text file turns into writing CR-LF, and it's that handling
> that's applied to stdout. There's nothing in the code that's specificly
> implementing the C standard display semantics.

It is specifically implementing the C display semantics.  That is, the
purpose of the translation is to get the desired display effects.
Performing the translation for all text streams, rather than just
those directed at display devices, is just for convenience.  It allows
a text file's contents to be sent straight to the display device
without needing any (additional) translation.  As you say, it's no
coincidence that the translation performed on text streams is the same
one required to get the desired display effects.


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 <hymie@prolifics.com> writes:
> "The effect of writing \e to a FILE * is to pass it through to the
>  underlying write system call unmodified."

How many times do I have to repeat this?  You can't just say "pass it
on to the next level", because the standard is talking about the level
that *doesn't* just pass it on.  You may not be accustomed to thinking
of that level as part of your C implementation, but it is, or can be.

> Does your compiler document the effect of puts("\n\b")?

# \n (new line) Moves the active position to the initial position of
#    the next line.

# \b (backspace) Moves the active position to the previous position on
#    the current line.  If the active position is at the initial
#    position of a line, the behavior is unspecified.
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^

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              ]

Russell Bornschlegel wrote:
>
> Pete Becker wrote:
> > Since the effect of #pragma is implementation defined, you're saying
> > that the result of writing any sequence of characters that contains a \e
> > to any output device should also be defined by the implementation. I
> > think you'll hear screams from compiler vendors if they are required to
> > document the effects of every possible escape sequence on all devices
> > that could be attached to the system.
>
> Can you put on your compiler vendor hat and document the effects of
> the following code:

If I were the compiler vendor I would know what
"/dev/somethingpetebeckerhasneverheardof" refers to, thus producing 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:
> > Paul Jarc wrote:
> > > No, even if you consider the display effects to be required, the
> > > library doesn't have to emulate ansi.sys when ansi.sys isn't loaded -
> > > the implementor can just say "ansi.sys is part of this
> > > implementation".
> >
> > And, of course, they'd then have to deal with all the technical support
> > calls from peole who want to know where to find the copy of ansi.sys
> > that is part of the implementation, since it didn't get installed with
> > the compiler.
>
> Well, that's easily solved - let ansi.sys be part of the
> implementation, but don't tell the users that. Alternatively, the
> implementation could target the platform "DOS with ansi.sys" rather
> than just "DOS".
>

Unfortunately, back when this mattered, many people didn't want to
install ANSI.SYS, because it took up memory space in that 640k that DOS
had to fit in. But this is getting bogged down in details and getting
away from the main point: ANSI.SYS is only one of many possible schemes
for interpreting the ASCII ESC character. Whatever the vendor documents
they have to support. Most vendors would document as little as possible,
becaues the support burden would be too large otherwise.

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

Larry Jones wrote:
>
> Pete Becker (petebecker@acm.org) wrote:
> >
> > Since the effect of #pragma is implementation defined, you're saying
> > that the result of writing any sequence of characters that contains a \e
> > to any output device should also be defined by the implementation.
>
> I said nothing of the sort; please don't try to put words in my mouth.
> What I said was they both affect the interpretation of the following
> "stuff" in a way that the standard can't describe.  In the case of
> #pragma, the following "stuff" is code that's being interpreted by the
> implementation, so requiring the implementation to define the effect is
> reasonable.  In the case of \e, the following "stuff" is characters that
> are being interpreted by a particular output device, so if anything were
> to define the effect, it would have to be the output device; but that's
> well outside the scope of a programming language standard.  In neither
> case does the standard itself specify any particular effect.
>

The effect of a #pragma directive is implementation defined. That means
that the implementation must tell you how the following "stuff" will be
interpreted.

--
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:
> > The runtime library needs to do what's necessary to create a newline on
> > a "normal" system. You can fiddle with the system's settings and defeat
> > that behavior if that's what you'd like to do.
>
> The standard doesn't mention "normal" systems. It talks about the
> actions of the alphabetic escape sequences on display devices. Do
> you mean to tell me that if I modify my terminal settings, I have
> turned it into something that's no longer a display device?

Not at all. What I have said consistently is that the implementaiton
must do whatever is reasonable to produce the appropriate behavior.

--
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 <7PpcYeyXw-B@khms.westfalen.de>,
Kai Henningsen <kaih=7PpcYeyXw-B@khms.westfalen.de> wrote:
>nmm1@cus.cam.ac.uk (Nick Maclaren)  wrote on 23.09.99 in <7scnvh$jmh$1@pegasus.csx.cam.ac.uk>:
>
>> Can you name one where curses could be implemented and termcap/terminfo
>> could not?
>
>Anything where you can get all the effects, but not by way of sending
>special character sequences to the display. Instead, you'd use some
>variant of out-of-band signalling, or maybe you control the actual display
>hardware, or whatever.

Firstly, I asked for an example.  Secondly, you can drive even such
things from termcap/terminfo - see below.

>The point being, curses is an API to the effects, whereas termcap/terminfo
>is an API to a means to produce that effect, and assumes that a certain
>type of means exists.

That is not so.  In particular, termcap/terminfo is not a full API.

termcap/terminfo is a database format, and is most simply implemented
on systems with Unix-like I/O.  However, every system with traditional
(i.e. before Unix, Ethernet, IP, Internet etc.) networking and many
devices (e.g. 3270s) need interface modules to convert the characters
that the application writes into the protocol that the network or
device accepts.  This applies even if the application is merely
writing plain C text (i.e. printing characters, newline and tab.)
So conversion of the characters defined by termcap/terminfo is still
possible.

This may seem off-group, but the relevance is in the display CONCEPTS.
curses and termcap/terminfo use the same concepts, and hence either
can be implemented if the other is.  If the network or device uses
incompatible concepts, then both are impossible, or both are possible
in a crippled fashion.

The main bodies of the C and C++ languages should not introduce such
conceptual assumptions into their languages - and it makes not a jot
of difference whether people are talking about library interfaces
(e.g. curses), database formats (e.g. termcap/terminfo) or escape
sequences.  What IS reasonable is to define a standard mechanism by
which an implementation can add such an extension.


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 wrote:
>
> Pete Becker <petebecker@acm.org> writes:
> > Since the effect of #pragma is implementation defined, you're saying
> > that the result of writing any sequence of characters that contains a \e
> > to any output device should also be defined by the implementation. I
> > think you'll hear screams from compiler vendors if they are required to
> > document the effects of every possible escape sequence on all devices
> > that could be attached to the system.
>
> "The effect of writing \e to a FILE * is to pass it through to the
>  underlying write system call unmodified."
>
> There, that wasn't so hard.

Sure, that's easy. Trouble is, it doesn't say anything. What is this
"it" that is being passed through to the underlying write system call?
What is the "underlying write system call"? In particular, for an
embedded system with a memory mapped display device that is driven
directly by the application program, there would not be any "underlying
write system call."

>
> Does your compiler document the effect of puts("\n\b")?
>

No, because its behavior is specified by the C 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              ]

Greg Brewer wrote:
...
> Why do we keep missing the \f sequence which has not meaning in the context
> of a monitor?  And think it, more than anything else, defines a device
> specific output code!

On myany systems, it has the meaning: clear screen, and set the cursor
at the upper left corner. That strikes me as a reasonable interpretation
of "logical page" in the context of a monitor.
---
[ 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) wrote:
>
> But that's the point: in order to know what this code does (as opposed
> to what the function names suggest that it does) you have to invoke
> magic. I don't see any other place in the standard that does that.

Code compiled in the presence of a #pragma.  \e would have exactly the
same effect on the interpretation of the following characters as #pragma
has on the interpretation of the following code.  They're both standard
ways of invoking nonstandard behavior.

-Larry Jones

Girls are like slugs -- they probably serve some purpose, but
it's hard to imagine what. -- 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              ]

Pete Becker wrote:
>
> Kai Henningsen wrote:
> >
> > petebecker@acm.org (Pete Becker)  wrote on 21.09.99 in <37E6EC0A.40DDF311@acm.org>:
> >
> > > The C standard talks about intended behavior, which is more than anyone
> > > has been willing to do with regard to \e.
> >
> > Untrue.
> >
>
> Sigh. Once again, please state the effect on the display of including
> the character \e in a character string that is displayed with printf.
> Here's a start:
>
> #include <stdio.h>
>
> int main()
> {
> printf("abcd\efg\n");
> return 0;
> }
>
> We know what 'a', 'b', 'c', 'd', 'f', 'g', and '\n' should do. What is
> the effect of the \e?

That you don't know what f. g and \n will do any more, unless
you know the specific implementation of the device you send it to.
The reason why this is useful is that there are standardized
devices, on which this sequence will have a well-known effect.


[ 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 the point: in order to know what this code does (as opposed
> to what the function names suggest that it does) you have to invoke
> magic. I don't see any other place in the standard that does that.

First of all, who says that stdprn is a display device? It could just
as easily be a FILE * of something which was opened in binary mode.

You don't invoke magic, you invoke your implementation's documentation,
which will tell you the value which \e is given, and the action of the
runtime when a char of that value is written. The value is going to be
ASCII ESC and the action is going to be to pass that value to the output
stream in most implementations.
---
[ 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              ]

Greg Brewer wrote:
>
> Pete Becker <petebecker@acm.org> wrote in message
> news:37F15310.F69B2C61@acm.org...
> > It's clear from the code what the programmer who wrote it intended it to
> > do. It's not at all clear that it in fact does that. Compare it with:
> >
> > fprintf(stdprn, "\t");
> >
> > Anyone who is familiar with the C standard can tell you what the effect
> > of that code is.
>
> Short of standardizing bold, underline, italic, and other advanced
> operations, there is no way to clarify that it does work.  However, that it
> will work has to do with the accuracy of the detection routines and the
> correctness of the codes being sent.  Assumming good detection routines, the
> code will run on both ASCII and EBCDIC machines.

Yup. Which means that the C standard says nothing at all about what it
does. So you cannot use that code in a strictly conforming C program.

>
> Your statement will only work with a printer that understands the TAB
> character.

Nonsense. It will work so long as the code that sends characters to the
printer knows how to get the printer to move the active position to the
next horiziontal tabulation position. If the printer "understands" TAB,
then the code that sends characters to the printer doens't have to do
anything other than send a TAB character when it sees the value that \t
was translated to. If the printer understnads some other single
character, then the driver sends that character. If there is no single
character, then the driver does whatever is needed. Assuming, that is,
that "stdprn" is the name of a stream that is connected to a display
device. I don't know whether a printer qualifies, but leaving that
aside...

>  I have a specialty printer here that will not work as you expect
> it to.  Now, you tell me what
>    fprintf(stdout,"\f");
> does.

It "[m]oves the active position to the initial position at the start of
the next logical page."

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

Douglas A. Gwyn <gwyn@arl.mil> wrote in message
news:37F23430.EDD4B51C@arl.mil...
> Greg Brewer wrote:
> > ... it send text to a printer in bold type.
> But clearly it is not very close to portable even if \e is supported.

There must have been a mistake in transmission.  I think the text should
have said "clearly it is very portable if \e is supported".  Some extra
words were added that made it sound like you were saying exactly opposite of
that.  To make it even worse, the example that demonstrated that it was
clearly portable was lost in transmission.

Greg Brewer
---
[ 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              ]

Greg Brewer wrote:
>
> Paul Jarc <prj@po.cwru.edu> wrote in message
> news:m31zbktg7d.fsf@multivac.student.cwru.edu...
> > Use of fopen() is not strictly conforming; it relies on something
> > implementation-defined.
>
> Ok, someone is going to have to come up with the definition of "strictly
> conforming".
>

>From section 1.7 of the ANSI C standard: "A strictly conforming program
shall use only those features of the language and library specified in
this standard. It shall not produce output dependent on any unspecified,
undefined, or implementation-defined behavior, and shall not exceed any
minimum implementation limit."

--
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:
> So if, for example, the compiler targeted DOS with ANSI.SYS, it would
> document the effects of the various ANSI control strings (probably by
> referring to the defining document). And if ANSI.SYS is not loaded, it
> would have to emulate ANSI.SYS.

No, even if you consider the display effects to be required, the
library doesn't have to emulate ansi.sys when ansi.sys isn't loaded -
the implementor can just say "ansi.sys is part of this
implementation".


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> wrote in message
news:37F2716B.580A78F3@wizard.net...
> Greg Brewer wrote:
> > Ok, someone is going to have to come up with the definition of "strictly
> > conforming".
> You've been using the term without even knowing it's definition? I
> thought you were simply misunderstanding the definition. OK - here it is
> (from the C9X standard - I don't have a copy of the C89 standard, and
> the C++ standard doesn't use the concept):

Guilty.  I thought I knew what it meant.  It has been around10 years since I
read up on the C standard.  Everything I've read since then was on the C++
standard.

Greg Brewer
---
[ 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:
>
> Paul Jarc <prj@po.cwru.edu> writes:
> > Hyman is right (AFAIK), but confused: no *compiler* implements those
> > effects, but the standard talks about a great deal more than just
> > compilers.  Even if the handling is not done in libc.a, or whatever,
> > that doesn't imply that whatever code does the handling is not part of
> > the implementation.
>
> I am not confused at all. On my UNIX terminal, I can use the stty command
> to change its behavior in many ways. For example, I can ask it to display
> lower case characters in upper case, and to not convert LF into CR-LF.
> When I do so, my C programs print only upper case characters, and print
> multiple lines like this -
>
> LINE 1
>       LINE 2
>             LINE 3
>
> Therefore, I believe I am justified in saying that my C compiler/runtime
> system does not implement the behavior requested in the C standard, but
> instead relies on the fact that the usual settings cause uninterpreted
> output of characters to do the right thing.
>
> Furthermore, I assert that this is the behavior that users of the compiler
> expect and want.
>

Fine. However, under DOS, there is no character that you can send to the
OS that will move the output position to the beginning of the next line.
It's as if your terminal were permanently stuck in that mode. In order
to get real newlines you'd have to write output strings with both LF and
CR: puts("\n\r"). And that's not the behavior that users of the compiler
expect and want.

--
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:
> > Hyman Rosen wrote:
> > > According to you,
> > > the C runtime should check stdout for isatty, then use termio functions
> > > to determine whether the terminal is in raw or cooked mode. If the former,
> > > then the runtime should write LFs as CR-LF pairs. Do you know of any
> > > implementation that does this? Can you think of a reason why?
> >
> > I feel like a broken record. The C standard describes what happens when
> > a source string containing '\n' is sent to a display device. That
> > description, and the resulting effect, does not depend on what value the
> > compiler translates \n into. It is convenient to translate it into a
> > value that will have the desired effect when sent to a display device,
> > but that is an implementation detail, and not a requirement of the
> > standard.
>
> I'm sorry, let me rewrite my question:
>
> According to you, the C runtime should check stdout for isatty, then
> use termio functions to determine whether the terminal is in raw or
> cooked mode.

Nope, I've never said anything about raw or cooked mode. I did get
sidetracked into talinkg about checking whether a stream was writing to
a display device, but I'm feeling much better now.

The runtime library needs to do what's necessary to create a newline on
a "normal" system. You can fiddle with the system's settings and defeat
that behavior if that's what you'd like to do. Under DOS, a "normal"
system has no mechanism for writing a single character that will move
the output position to the beginning of the next line. So the runtime
code writes the two characters ASCII LF and ASCII CR in order to start a
new 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              ]

AllanW wrote:
>
> In article <37F14C7D.19F6A1F4@acm.org>,
>   Pete Becker <petebecker@acm.org> wrote:
> (about using \e for escape)
> > ... in order to know what this code does (as opposed
> > to what the function names suggest that it does) you have to invoke
> > magic. I don't see any other place in the standard that does that.
>
> How about
>   #pragma foo(bar:baz)
> Here is a standard way to evoke non-standard behavior. This isn't
> terribly different than the \e proposal.

Agreed. Many people think that #pragma is a horrible idea.

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

Greg Brewer wrote:
>
> Pete Becker <petebecker@acm.org> wrote in message
> news:37F142A0.293E373D@acm.org...
> > So if, for example, the compiler targeted DOS with ANSI.SYS, it would
> > document the effects of the various ANSI control strings (probably by
> > referring to the defining document). And if ANSI.SYS is not loaded, it
> > would have to emulate ANSI.SYS. The bottom line here is that whatever
> > behavior is documented, if that behavior depends on having a suitable
> > driver running on the system, then the compiler must also provide
> > emulation when such a driver is not present. I suspect that compiler
> > vendors would lean toward minimal implementations.
>
> If a programs behavior depends on having a suitable driver running, the
> appropriate thing for the programmer to do is to check for the driver and if
> it is not running, either run it or refuse to run.  I do not want to
> compiler providing the emulation.

Please don't quote out of context. The message that I replied to said:

> > It introduces a device control string. Just as the library contains
> > special code to process \t, \v, \r, \n, \a, and \b into the device-
> > specific output that causes the display position to change or a
> > dialog window to be displayed for the alert, so it will process the
> > strings for device control. The compiler manual will come with that
> > implementation's description of what those strings are.

If the implementaiton documents the behavior of control strings, then it
must insure that they work as documented. Your disagreement here is with
the poster of this message, not with me.

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

Nick Maclaren wrote:
>
> A huge number of people believe that, because they have done the
> first task a couple of times, it equips them to blather on about the
> second.  I can assure you that it is much harder to get right than
> you appear to be able to imagine.
>

Your assurances aren't needed. I'm well aware of that. What I'm not
aware of is why you think that what I've said here implies anything to
the contrary. I've said three things:

1. The C standard does not define the effect of writing alphabetic
escape sequences in terms of what characters are sent to the display
device, but in terms of the behavior of the display device;

2. It is often convenient for the implementor to map alphabetic escape
sequences to control characters, because control characters can usually
produce the correct behavior; and

3. If there is no control character that will produce the correct
behavior, the implementor should produce a sequence of system-dependent
instructions that produce the correct behavior if it is feasible.

--
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> wrote in message
news:37F39B40.CCEA25B8@acm.org...
> Fine. However, under DOS, there is no character that you can send to the
> OS that will move the output position to the beginning of the next line.

Uh, make that "under DOS prior to version 7"

Greg Brewer
---
[ 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:
>
> Pete Becker (petebecker@acm.org) wrote:
> >
> > But that's the point: in order to know what this code does (as opposed
> > to what the function names suggest that it does) you have to invoke
> > magic. I don't see any other place in the standard that does that.
>
> Code compiled in the presence of a #pragma.  \e would have exactly the
> same effect on the interpretation of the following characters as #pragma
> has on the interpretation of the following code.  They're both standard
> ways of invoking nonstandard behavior.
>

Since the effect of #pragma is implementation defined, you're saying
that the result of writing any sequence of characters that contains a \e
to any output device should also be defined by the implementation. I
think you'll hear screams from compiler vendors if they are required to
document the effects of every possible escape sequence on all devices
that could be attached to the system.

--
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:
> > So if, for example, the compiler targeted DOS with ANSI.SYS, it would
> > document the effects of the various ANSI control strings (probably by
> > referring to the defining document). And if ANSI.SYS is not loaded, it
> > would have to emulate ANSI.SYS.
>
> No, even if you consider the display effects to be required, the
> library doesn't have to emulate ansi.sys when ansi.sys isn't loaded -
> the implementor can just say "ansi.sys is part of this
> implementation".
>

And, of course, they'd then have to deal with all the technical support
calls from peole who want to know where to find the copy of ansi.sys
that is part of the implementation, since it didn't get installed with
the compiler.

--
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 <7sr3mc$23mi$1@news.hal-pc.org>,
Greg Brewer <nospam.greg@brewer.net> wrote:
>Why do we keep missing the \f sequence which has not meaning in the context
>of a monitor?  And think it, more than anything else, defines a device
>specific output code!

Amusingly, I've known a number of people who insisted that \f should clear
screens, and I've seen a number of terminal drivers where it does just because
people expect it to work.

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

Greg Brewer wrote:
>
> Hyman Rosen <hymie@prolifics.com> wrote in message
> news:t7r9jkxf3p.fsf@calumny.jyacc.com...
> > Pete Becker <petebecker@acm.org> writes:
> > It introduces a device control string. Just as the library contains
> > special code to process \t, \v, \r, \n, \a, and \b into the device-
> > specific output that causes the display position to change or a
>
> Why do we keep missing the \f sequence which has not meaning in the context
> of a monitor?  And think it, more than anything else, defines a device
> specific output code!
>

Oversight. Add \f to the list if you prefer. Me, I'd rather discuss
substance.

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

Greg Brewer wrote:
>
> Paul Jarc <prj@po.cwru.edu> wrote in message
> news:m31zbktg7d.fsf@multivac.student.cwru.edu...
> > Use of fopen() is not strictly conforming; it relies on something
> > implementation-defined.
>
> Ok, someone is going to have to come up with the definition of "strictly
> conforming".

You've been using the term without even knowing it's definition? I
thought you were simply misunderstanding the definition. OK - here it is
(from the C9X standard - I don't have a copy of the C89 standard, and
the C++ standard doesn't use the concept):

Section 4 paragraph 5:
"A _strictly conforming program_ shall use only those features of the
language and library specified in this International Standard.2) It
shall not produce output dependent on any unspecified, undefined, or
implementation-defined behavior, and shall not exceed any minimum
implementation limit."

The '_'s indicate that "strictly conforming program" is printed in
italics, which is the standard's way of indicating that this paragraph
defines the term. The "2)" is a superscript referring to footnote 2:

"A strictly conforming program can use conditional features (such as
those in annex F) provided the use is guarded by a #ifdef directive with
the appropriate macro. For example:

 #ifdef _ _STDC_IEC_559_ _ /* FE_UPWARD defined */
    /* ... */
    fesetround(FE_UPWARD);
    /* ... */
 #endif
"

As has been frequently pointed out, the term "strictly conforming" is so
restrictive that essentially no useful program qualifies. The term is
useful mainly for judging the severity of a proposed change to the
standard: if a change affects even strictly conforming code, it's pretty
significant.


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

"Greg Brewer" <nospam.greg@brewer.net> writes:
> Paul Jarc <prj@po.cwru.edu> wrote in message
> news:m31zbktg7d.fsf@multivac.student.cwru.edu...
> > Use of fopen() is not strictly conforming; it relies on something
> > implementation-defined.
>
> Ok, someone is going to have to come up with the definition of "strictly
> conforming".

C9X 4p5:
# A strictly conforming program shall use only those features of the
# language and library specified in this International Standard. It
# shall not produce output dependent on any unspecified, undefined, or
# implementation-defined behavior, and shall not exceed any minimum
# implementation limit.

3.18p1: undefined behavior
# behavior, upon use of a nonportable or erroneous program construct,
# of erroneous data, or of indeterminately valued objects, for which
# this International Standard imposes no requirements

3.19p1: unspecified behavior
# behavior where this International Standard provides two or more
# possibilities and imposes no requirements on which is chosen in any
# instance

3.11p1: implementation-defined behavior
# unspecified behavior where each implementation documents how the
# choice is made


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 <petebecker@acm.org> writes:
> Hyman Rosen wrote:
> > Pete Becker <petebecker@acm.org> writes:
> > > The C standard says nothing about "control characters," but it does
> > > define the effect of writing a \n to a display device.
> >
> > No UNIX C compiler implements those effects, however!
>
> None? Really? I wouldn't dare to assume that I was familiar with every
> compiler in existence that targets any system called UNIX.

Hyman is right (AFAIK), but confused: no *compiler* implements those
effects, but the standard talks about a great deal more than just
compilers.  Even if the handling is not done in libc.a, or whatever,
that doesn't imply that whatever code does the handling is not part of
the implementation.


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 <petebecker@acm.org> writes:
> And if ANSI.SYS is not loaded, it would have to emulate ANSI.SYS.

No. Just like UNIX compilers "do the wrong thing" when the terminal
is in raw mode.

> I suspect that compiler vendors would lean toward minimal implementations.

Yes, exactly like we all want!


[ 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:
> > According to you,
> > the C runtime should check stdout for isatty, then use termio functions
> > to determine whether the terminal is in raw or cooked mode. If the former,
> > then the runtime should write LFs as CR-LF pairs. Do you know of any
> > implementation that does this? Can you think of a reason why?
>
> I feel like a broken record. The C standard describes what happens when
> a source string containing '\n' is sent to a display device. That
> description, and the resulting effect, does not depend on what value the
> compiler translates \n into. It is convenient to translate it into a
> value that will have the desired effect when sent to a display device,
> but that is an implementation detail, and not a requirement of the
> standard.

I'm sorry, let me rewrite my question:

According to you, the C runtime should check stdout for isatty, then
use termio functions to determine whether the terminal is in raw or
cooked mode. If the former, then the runtime should write the character
whose value is '\n' as a CR-LF pair, and if the latter, as a single LF
(although CR-LF would work there too, I suppose). Do you know of any
implementation that does this? Can you think of a reason why?

Suppose I set OLCUC on my Unix terminal, so that lower case is mapped
to upper case on output. Do you know of a C implementation that detects
this, and attempts to reset this mode so that lower case characters are
displayed correctly? Can you think of a reason why?


[ 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> wrote in message
news:37F142A0.293E373D@acm.org...
> So if, for example, the compiler targeted DOS with ANSI.SYS, it would
> document the effects of the various ANSI control strings (probably by
> referring to the defining document). And if ANSI.SYS is not loaded, it
> would have to emulate ANSI.SYS. The bottom line here is that whatever
> behavior is documented, if that behavior depends on having a suitable
> driver running on the system, then the compiler must also provide
> emulation when such a driver is not present. I suspect that compiler
> vendors would lean toward minimal implementations.

If a programs behavior depends on having a suitable driver running, the
appropriate thing for the programmer to do is to check for the driver and if
it is not running, either run it or refuse to run.  I do not want to
compiler providing the emulation.

Greg Brewer


[ 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:
> Hyman is right (AFAIK), but confused: no *compiler* implements those
> effects, but the standard talks about a great deal more than just
> compilers.  Even if the handling is not done in libc.a, or whatever,
> that doesn't imply that whatever code does the handling is not part of
> the implementation.

I am not confused at all. On my UNIX terminal, I can use the stty command
to change its behavior in many ways. For example, I can ask it to display
lower case characters in upper case, and to not convert LF into CR-LF.
When I do so, my C programs print only upper case characters, and print
multiple lines like this -

LINE 1
      LINE 2
            LINE 3

Therefore, I believe I am justified in saying that my C compiler/runtime
system does not implement the behavior requested in the C standard, but
instead relies on the fact that the usual settings cause uninterpreted
output of characters to do the right thing.

Furthermore, I assert that this is the behavior that users of the compiler
expect and want.


[ 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 <37F14C7D.19F6A1F4@acm.org>,
  Pete Becker <petebecker@acm.org> wrote:
(about using \e for escape)
> ... in order to know what this code does (as opposed
> to what the function names suggest that it does) you have to invoke
> magic. I don't see any other place in the standard that does that.

How about
  #pragma foo(bar:baz)
Here is a standard way to evoke non-standard behavior. This isn't
terribly different than the \e proposal.

--
Allan_W@my-deja.com is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.


Sent via Deja.com http://www.deja.com/
Before you buy.


[ 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 <7stik8$2ves$1@news.hal-pc.org>,
  "Greg Brewer" <nospam.greg@brewer.net> wrote:
> Your statement will only work with a printer that understands the
> TAB character.  I have a specialty printer here that will not work
> as you expect it to.  Now, you tell me what
>    fprintf(stdout,"\f");
> does.

How about:
    The sequence \f ("Form Feed") represents a character which,
       when sent to a device that understands the host character
       set, will typically advance the print position to the
       next page. If the host character set does not have such
       a code, it represents any character which is distinct
       from \n, \r, etc. Note that there is no guarantee that
       any device will actually respond to this code by advancing
       the print position as specified; the \f sequence simply
       refers to the appropriate codes, if they exist.

And, by the same token:

    The sequence \r ("Return") represents a character which,
       when sent to a device that understands the host character
       set, will typically move the print position back to the
       beginning of the current line. If the host character set
       does not have such a code, it represents any character
       which is distinct from \n, \f, etc. Note that there is
       no guarantee that any device will actually respond to
       this code by moving the print position as specified; the
       \r sequence simply refers to the appropriate codes, if
       they exist.

    The sequence \e ("Escape") represents a character which,
       when sent to a device that understands the host character
       set, will typically mark the beginning of device-
       dependant commands. If the host character set does not
       have such a code, it represents any character which is
       distinct from \n, \r, etc. Note that there is no
       guarantee that any device will actually respond to this
       code in any way at all; the \e sequence simply refers to
       the appropriate codes, if they exist.

And so on. Obviously, the actual text would list all of the
defined \x characters, rather than using the word "etc."

--
Allan_W@my-deja.com is a "Spam Magnet," never read.
Please reply in newsgroups only, sorry.


Sent via Deja.com http://www.deja.com/
Before you buy.


[ 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:
> Therefore, I believe I am justified in saying that my C compiler/runtime
> system does not implement the behavior requested in the C standard, but
> instead relies on the fact that the usual settings cause uninterpreted
> output of characters to do the right thing.

No, it is part of the "runtime system".  The terminal driver that does
the interpretation is part of the implementation too, because it is a
necessary piece of the puzzle.  The interpretation isn't in cc, and
it's not in libc.a, but that doesn't mean it's not in the
implementation.


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> wrote in message
news:37EFEF2A.4D97DFB@wizard.net...
> Greg Brewer wrote:
> > It may be true that there are compilers that recognize special file
names --
> > there may even be many but I doubt it; however, it is not the compiler
that
> > connects the special name to the define, it is the operating system.
The
> Not necessarily; an operating system might not provide file-based access
> to a device at all - it could provide an entirely different way of
> controlling it. Despite that fact, an implementor of C might choose to
> make file-based access available through a special implementation of
> fopen() which recognises the compiler-defined, rather than OS-defined,

Hence, the first sentence of my statement.  I personally am not aware of any
such implementation; but, I did recognize that they may exist.  My
experience is on DEC/VAX, VM/CMS, MS/DOS/Windows, and MacIntosh.  Of those,
VM/CMS and MacIntosh did not have a mechanism for accessing a device using
fopen and I did not see any documentation on a "special implemenation".
When the OS supports such a convention, it is common to all implementations
on that platform.  When it is not OS supported, you have to be intimately
familar with the specifics of the compiler implementation.

Greg Brewer


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

"Greg Brewer" <nospam.greg@brewer.net> writes:
> My experience is on DEC/VAX, VM/CMS, MS/DOS/Windows, and MacIntosh.
> Of those, VM/CMS and MacIntosh did not have a mechanism for
> accessing a device using fopen and I did not see any documentation
> on a "special implemenation".

I know of one example, offhand: DJGPP, a DOS port of gcc and, I
assume, glibc, recognizes names such as "/dev/null" and treats them
specially.  (I'm not sure whether "/dev/tty" is also handled, but
presumably it could easily be.)


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              ]

"Greg Brewer" <nospam.greg@brewer.net> writes:
> Pete Becker <petebecker@acm.org> wrote in message
> news:37ED2C01.2EA60F19@acm.org...
> > > The standard doesn't make any distinction between text and binary mode
> > > streams with regard to display devices.
> >
> > In standard C you cannot create a binary stream that writes to a display
> > device.
>
> Yes you can!  Just fopen a display device.  Piece of cake.

NO!  Strictly conforming code can't know the name of a display device,
nor need there be one at all.


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              ]

"Greg Brewer" <nospam.greg@brewer.net> writes:
> Paul Jarc <prj@po.cwru.edu> wrote in message
> news:m3r9jljt2y.fsf@multivac.student.cwru.edu...
> > Yes, there is: the standard provides no means of opening a stream so
> > that it will be hooked up to the same output channel as stdout or
> > stderr, nor is "/dev/tty" (or whatever) necessarily a legal filename
> > to pass to fopen().
>
> That standard does not, and can not, define a legal filename.  So, by your
> definition, using fopen will violate some provision of the standard because
> the filename is not a defined, legal filename.  Is this what you mean to
> say?

Pretty nearly.  From C9X 7.19.3p8:
# Functions that open additional (nontemporary) files require a file
# name, which is a string.  The rules for composing valid file names
# are implementation-defined.

Use of fopen() is not strictly conforming; it relies on something
implementation-defined.


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              ]

Greg Brewer wrote:
>
> Paul Jarc <prj@po.cwru.edu> wrote in message
> news:m3r9jljt2y.fsf@multivac.student.cwru.edu...
> > Yes, there is: the standard provides no means of opening a stream so
> > that it will be hooked up to the same output channel as stdout or
> > stderr, nor is "/dev/tty" (or whatever) necessarily a legal filename
> > to pass to fopen().
>
> That standard does not, and can not, define a legal filename.  So, by your
> definition, using fopen will violate some provision of the standard because
> the filename is not a defined, legal filename.  Is this what you mean to
> say?

Earlier steps leading up to that message:

> "Greg Brewer" <nospam.greg@brewer.net> writes:
> > Paul Jarc <prj@po.cwru.edu> wrote in message
> > news:m3g104b5s0.fsf_-_@multivac.student.cwru.edu...
> > > "Greg Brewer" <nospam.greg@brewer.net> writes:
> > > > Also, you can open another stream in binary-mode that will write to the
> > > > screen.
> > >
> > > Not in strictly conforming code.
> >
> > There is not such restriction.

You're talking about opening it for output. It's implementation-defined
whether "/dev/tty" is even a valid filename, much less whether or not it
exists. Therefore, you may or may not be able to write output to it,
depending upon the implementation. Strictly conforming C programs are
prohibited from producing "output dependent upon ...
implementation-define behavior". It's perfectly legal C code, but it's
not strictly conforming C.
---
[ 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              ]

Greg Brewer wrote:
>
> Pete Becker <petebecker@acm.org> wrote in message
> news:37EE70E8.79A06CBA@acm.org...
> > 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?
>
> Ok.
>
> void PrintBold(const char *text)
> {
>    if (IsOragami3000())
>       fprintf(stdprn,"\eB%s\en", text);
>    else if (IsOragami5000())
>       fprintf(stdprn,"\eBt%s\ent", text);
>    else if (IsDunkirk())
>       fprintf(stdprn,"\e4[8]%s\e4[1]",text);
> }

Sure, you can write this code (which qualifies as a trivial use of \e),
but what does it do (which is a non-trivial use of \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              ]

Greg Brewer wrote:
>
> > The C standard does just that:
> >
> > \t (horizontal tab) Moves the active position to the next
> > horizontal tabulation position on the current line.
>
> But that doesn't always happen.  If I am running a Windows program and I
> type the tab key then the cursor usually moves to the next input field which
> may be anywhere on the current window and expect that a some point in the
> processing of that keystroke, code to the same effect as "if (? == '\t')"
> is executed.
>

Pressing the tab key has nothing to do with using the alphabetic escape
sequence \t in your source code. The issue here is what does the C
standard require conforming implementations to do on output with source
code containing \t, not what does the Windows OS do with a tab on input.

--
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:
> None of the various fuzzy proposed definitions of '\e' that I've seen
> here has come anywhere near the degree of specificity of the C standards
> definition of the effect of, say, '\v'. Putting aside whether it's
> actually required or implementable, with '\v' there's a clear goal for
> the implementor. With the suggestions that have been made for '\e' there
> is no formal guidance as to what it should actually do.

It introduces a device control string. Just as the library contains
special code to process \t, \v, \r, \n, \a, and \b into the device-
specific output that causes the display position to change or a
dialog window to be displayed for the alert, so it will process the
strings for device control. The compiler manual will come with that
implementation's description of what those strings are.

The C standard as written provides no formal guidance for what should
happen if one prints \b at the start of a line, yet actual C
implementations have managed to be shipped anyway, even though the
lack of guidance sent the library writers into an existential funk. I
imagine that the programmers left a big comment in the appropriate
place in the code saying "We don't know what to do here!" and the
marketing department was able to find the comment and replace it with
code that wrote a BS to the output stream.
---
[ 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:
> > On UNIX platforms, the C runtime delivers '\n' uninterpreted, because
> > UNIX text files lines are in fact delimited by single LF characters.
> > The effects of the control characters upon a display are left up to
> > the operating system, without the runtime being involved at all.
>
> I agree with everything in this response except for the last sentence.
> The C standard says nothing about "control characters," but it does
> define the effect of writing a \n to a display device.

No UNIX C compiler implements those effects, however! According to you,
the C runtime should check stdout for isatty, then use termio functions
to determine whether the terminal is in raw or cooked mode. If the former,
then the runtime should write LFs as CR-LF pairs. Do you know of any
implementation that does this? Can you think of a reason why?
---
[ 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 <7snj4k$1tjl$1@news.hal-pc.org>, Greg Brewer
<nospam.greg@brewer.net> writes
>How can you say that?  Using functions not defined by the standard does not
>make a program less conforming.  setmode() can too be implemented in
>strictly conforming code.

Go on: show us.

--
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 <t7r9jkxf3p.fsf@calumny.jyacc.com>,
Hyman Rosen  <hymie@prolifics.com> wrote:
>
>The C standard as written provides no formal guidance for what should
>happen if one prints \b at the start of a line, yet actual C
>implementations have managed to be shipped anyway, even though the
>lack of guidance sent the library writers into an existential funk. I
>imagine that the programmers left a big comment in the appropriate
>place in the code saying "We don't know what to do here!" and the
>marketing department was able to find the comment and replace it with
>code that wrote a BS to the output stream.

Or "wrote BS to the output stream" :-)  Exactly the same applies to
writing '\f', '\r' or '\v' without an associated '\n' to a file
with ANSI control characters, '\f', '\r' or '\v' to a file with
no control character support, '\a' or '\t' to an MVS text file,
more characters that would fit in a record, and so on.

Yes, I can confirm that your view of the process is considerably
closer than Pete Becker's.  Been there, done that.  Twice, actually.


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              ]

Pete Becker <petebecker@acm.org> wrote in message
news:37EFBEAF.2BCACEA7@acm.org...
> > void PrintBold(const char *text)
> > {
> >    if (IsOragami3000())
> >       fprintf(stdprn,"\eB%s\en", text);
> >    else if (IsOragami5000())
> >       fprintf(stdprn,"\eBt%s\ent", text);
> >    else if (IsDunkirk())
> >       fprintf(stdprn,"\e4[8]%s\e4[1]",text);
> > }
>
> Sure, you can write this code (which qualifies as a trivial use of \e),
> but what does it do (which is a non-trivial use of \e)?

Really.  Then we have different definitions of "trivial"!  As to what does
it do?  The functions name is "PrintBold" and it sends output to stdprn.  I
know that are purist who believe that every line of code should have a least
one comment; however, I am not one of them.  Ok, to answer your question, it
send text to a printer in bold type.  Before sending it, it detects what
type of printer is attached by some magical means that are outside the scope
of the exercise so that it knows what codes to send.

Greg Brewer


[ 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 <37F14B48.A3CEEFBA@acm.org>,
Pete Becker  <petebecker@acm.org> wrote:
>
>Nick Maclaren wrote:
>>
>> Or "wrote BS to the output stream" :-)  Exactly the same applies to
>> writing '\f', '\r' or '\v' without an associated '\n' to a file
>> with ANSI control characters, '\f', '\r' or '\v' to a file with
>> no control character support, '\a' or '\t' to an MVS text file,
>> more characters that would fit in a record, and so on.
>>
>> Yes, I can confirm that your view of the process is considerably
>> closer than Pete Becker's.  Been there, done that.  Twice, actually.
>
>Same here. Twice, too. But the C standard doesn't talk about the
>"process," it talks about the meaning of alphabetic escape sequences.
>And as I've said several times, it's often convenient to implement those
>semantics by emitting control characters that the device will handle
>appropriately. But that doesn't mean that the way the device handles the
>control characters defines what the standard requires.

Sigh.  Perhaps I need to go right back and explain the basics.  If
anyone who actually knows about this area is still following this
thread, I apologise for giving such an oversimplified description.

There are two major common models of text files - one where they are
a sequence of characters with embedded control characters to indicate
newlines etc., which is the one used by ASCII, most serial line
communication systems and C - and one where they are a sequence of
arrays of uninterpreted characters, with the record separators being
out-of-band data (usually in the form of an implicit or explicit
record length, sometimes with a control character associated with a
record separator.)

Similarly, there are three common models of fancy device control - one
where you embed control characters and escape sequences in a text
stream (e.g. VT-100 and friends) - another where the interface is
a set of 'system' calls and not a text stream at all - and one where
the control functions are handled out of band with the text stream.
3270s are a bit of a hybrid between the last two forms.

Many systems that use the first file model and one of the two latter
device models have a clear distinction between binary record files
and text ones - in the former, they have both record boundaries AND
any characters can occur in the data (i.e. a strict superset of the
C model) - in the latter, it is common to support ONLY printing
characters (i.e. there are NO control characters that may be embedded
in the data.)

It is generally pretty easy to write C I/O support if the text files
use the first model.  For reasons that I could go into, devices that
use the escape sequence model are almost always associated with the
character stream file model.

It is extremely hard to do this if the text files use the second
model, and it is much worse to interpret control characters for them,
because those systems usually use one of the second two fancy device
models.

A huge number of people believe that, because they have done the
first task a couple of times, it equips them to blather on about the
second.  I can assure you that it is much harder to get right than
you appear to be able to imagine.


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              ]

"Douglas A. Gwyn" <gwyn@arl.mil> writes:
> Paul Jarc wrote:
> > Use of fopen() is not strictly conforming; it relies on something
> > implementation-defined.
>
> NOt necessarily.  If the filename is a command-line argument,
> for example, or is read on stdin, then in effect part of the
> "program" is provided by the execution environment, to which
> the responsibility for providing a valid filename has devolved.

True.  But roughly the same can be said of:

#include <stdio.h>
int main(void) {
    int x, y;
    scanf("%d%d", &x, &y);
    printf("%d", x/y);
    return 0;
}

The only difference is that in this case, it's possible for the
program to verify the validity of the data before operating on it.
`strictly conforming', then, isn't even a property of a complete
program, but rather of an execution of it.

> It becomes impossible in such a case to know that the program
> is strictly conforming by examining the source code, but the
> fact that it *might* be means it should be considered as such
> from the code-checking perspective.

If you're forced to say either `strictly conforming' or `not', then
it's debatable what you'd want to say in these cases.  Better to say
`depends on input data'.  You can't prove that it won't "produce
output dependent on any unspecified, undefined, or implementation-
defined behavior", but you can't prove that it will, 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              ]

In article <m31zbktg7d.fsf@multivac.student.cwru.edu>, prj@po.cwru.edu
says...

[ ... ]

> Use of fopen() is not strictly conforming; it relies on something
> implementation-defined.

Technically speaking, using something implementation defined doesn't
affect whether the program is strictly conforming unless the output of
the program depends on the part that's implementation defined.

OTOH, since a program can't create ANY output that without using
something that's implementation defined, this is of little
consequence.

--
    Later,
    Jerry.

The universe is a figment of its own imagination.
---
[ 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> wrote in message
news:t7r9jkxf3p.fsf@calumny.jyacc.com...
> Pete Becker <petebecker@acm.org> writes:
> It introduces a device control string. Just as the library contains
> special code to process \t, \v, \r, \n, \a, and \b into the device-
> specific output that causes the display position to change or a

Why do we keep missing the \f sequence which has not meaning in the context
of a monitor?  And think it, more than anything else, defines a device
specific output code!

Greg Brewer
---
[ 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 in message
news:m31zbktg7d.fsf@multivac.student.cwru.edu...
> Use of fopen() is not strictly conforming; it relies on something
> implementation-defined.

Ok, someone is going to have to come up with the definition of "strictly
conforming".

Greg Brewer
---
[ 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 <7snkvg$1um5$1@news.hal-pc.org>, Greg Brewer
<nospam.greg@brewer.net> writes
>> 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.

>On the other hand, if you want to hook up an HP printer to your Torch
>Unicorn or Psion 3a then you might actually want to do things like bolding
>characters and setting page margins.  To do those things, you will need to
>send out an escape character.

And if I want to hook up a Postscript printer and do those things I'll
have to send out other characters. Why should HP get special status in
the C Standard ?

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

Hyman Rosen wrote:
>
> Pete Becker <petebecker@acm.org> writes:
> > Hyman Rosen wrote:
> > > On UNIX platforms, the C runtime delivers '\n' uninterpreted, because
> > > UNIX text files lines are in fact delimited by single LF characters.
> > > The effects of the control characters upon a display are left up to
> > > the operating system, without the runtime being involved at all.
> >
> > I agree with everything in this response except for the last sentence.
> > The C standard says nothing about "control characters," but it does
> > define the effect of writing a \n to a display device.
>
> No UNIX C compiler implements those effects, however!

None? Really? I wouldn't dare to assume that I was familiar with every
compiler in existence that targets any system called UNIX.

> According to you,
> the C runtime should check stdout for isatty, then use termio functions
> to determine whether the terminal is in raw or cooked mode. If the former,
> then the runtime should write LFs as CR-LF pairs. Do you know of any
> implementation that does this? Can you think of a reason why?

I feel like a broken record. The C standard describes what happens when
a source string containing '\n' is sent to a display device. That
description, and the resulting effect, does not depend on what value the
compiler translates \n into. It is convenient to translate it into a
value that will have the desired effect when sent to a display device,
but that is an implementation detail, and not a requirement of 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              ]

Hyman Rosen wrote:
>
> Pete Becker <petebecker@acm.org> writes:
> > None of the various fuzzy proposed definitions of '\e' that I've seen
> > here has come anywhere near the degree of specificity of the C standards
> > definition of the effect of, say, '\v'. Putting aside whether it's
> > actually required or implementable, with '\v' there's a clear goal for
> > the implementor. With the suggestions that have been made for '\e' there
> > is no formal guidance as to what it should actually do.
>
> It introduces a device control string. Just as the library contains
> special code to process \t, \v, \r, \n, \a, and \b into the device-
> specific output that causes the display position to change or a
> dialog window to be displayed for the alert, so it will process the
> strings for device control. The compiler manual will come with that
> implementation's description of what those strings are.

So if, for example, the compiler targeted DOS with ANSI.SYS, it would
document the effects of the various ANSI control strings (probably by
referring to the defining document). And if ANSI.SYS is not loaded, it
would have to emulate ANSI.SYS. The bottom line here is that whatever
behavior is documented, if that behavior depends on having a suitable
driver running on the system, then the compiler must also provide
emulation when such a driver is not present. I suspect that compiler
vendors would lean toward minimal implementations.

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

Greg Brewer wrote:
>
> Pete Becker <petebecker@acm.org> wrote in message
> news:37EFBEAF.2BCACEA7@acm.org...
> > > void PrintBold(const char *text)
> > > {
> > >    if (IsOragami3000())
> > >       fprintf(stdprn,"\eB%s\en", text);
> > >    else if (IsOragami5000())
> > >       fprintf(stdprn,"\eBt%s\ent", text);
> > >    else if (IsDunkirk())
> > >       fprintf(stdprn,"\e4[8]%s\e4[1]",text);
> > > }
> >
> > Sure, you can write this code (which qualifies as a trivial use of \e),
> > but what does it do (which is a non-trivial use of \e)?
>
> It
> send text to a printer in bold type.  Before sending it, it detects what
> type of printer is attached by some magical means that are outside the scope
> of the exercise so that it knows what codes to send.
>

But that's the point: in order to know what this code does (as opposed
to what the function names suggest that it does) you have to invoke
magic. I don't see any other place in the standard that does that.

--
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 <37EFDF43.ECE1FC98@acm.org>,
Pete Becker  <petebecker@acm.org> wrote:
>
>"Douglas A. Gwyn" wrote:
>>
>> Pete Becker wrote:
>> > It can be said much more simply: "Unlike all other character constants,
>> > whose values in the exeuction character set are implementation defined,
>> > the value of \e in the exeuction character set must be 27."
>>
>> But that's *not* what people are asking for -- C already provides
>> a simple way to code *that*.
>>
>
>That is what the message that I replied to suggested.

No, it didn't.  That is why your "simpler" translation fails.
What the original message suggested is that:
   1. If the execution character set is not ASCII, but
   2. if the execution environment provides some standard translation
      between the execution character set and ASCII devices and/or
      ASCII environments, and
   3. if the execution character set has a single character foo
   that is translated to an ASCII ESC by such translation,

   then the value of \e in the execution character set should be foo.
   Not 27 (unless that also happens to be foo).

Go back and read the message again.
--
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              ]

Pete Becker <petebecker@acm.org> wrote in message
news:37F15310.F69B2C61@acm.org...
> It's clear from the code what the programmer who wrote it intended it to
> do. It's not at all clear that it in fact does that. Compare it with:
>
> fprintf(stdprn, "\t");
>
> Anyone who is familiar with the C standard can tell you what the effect
> of that code is.

Short of standardizing bold, underline, italic, and other advanced
operations, there is no way to clarify that it does work.  However, that it
will work has to do with the accuracy of the detection routines and the
correctness of the codes being sent.  Assumming good detection routines, the
code will run on both ASCII and EBCDIC machines.

Your statement will only work with a printer that understands the TAB
character.  I have a specialty printer here that will not work as you expect
it to.  Now, you tell me what
   fprintf(stdout,"\f");
does.

Greg Brewer
---
[ 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 E. Wallace" wrote:
>
> In article <37EFDF43.ECE1FC98@acm.org>,
> Pete Becker  <petebecker@acm.org> wrote:
> >
> >"Douglas A. Gwyn" wrote:
> >>
> >> Pete Becker wrote:
> >> > It can be said much more simply: "Unlike all other character constants,
> >> > whose values in the exeuction character set are implementation defined,
> >> > the value of \e in the exeuction character set must be 27."
> >>
> >> But that's *not* what people are asking for -- C already provides
> >> a simple way to code *that*.
> >>
> >
> >That is what the message that I replied to suggested.
>
> No, it didn't.  That is why your "simpler" translation fails.
> What the original message suggested is that:
>    1. If the execution character set is not ASCII, but
>    2. if the execution environment provides some standard translation
>       between the execution character set and ASCII devices and/or
>       ASCII environments, and
>    3. if the execution character set has a single character foo
>    that is translated to an ASCII ESC by such translation,
>
>    then the value of \e in the execution character set should be foo.
>    Not 27 (unless that also happens to be foo).
>
> Go back and read the message again.

The point is that the C standard, as it exists today, does not prescribe
the value for any character. The values that characters are translated
to are implementation defined. That would not be the case for \e, which
would make it unique.

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

Nick Maclaren wrote:
>
> In article <t7r9jkxf3p.fsf@calumny.jyacc.com>,
> Hyman Rosen  <hymie@prolifics.com> wrote:
> >
> >The C standard as written provides no formal guidance for what should
> >happen if one prints \b at the start of a line, yet actual C
> >implementations have managed to be shipped anyway, even though the
> >lack of guidance sent the library writers into an existential funk. I
> >imagine that the programmers left a big comment in the appropriate
> >place in the code saying "We don't know what to do here!" and the
> >marketing department was able to find the comment and replace it with
> >code that wrote a BS to the output stream.
>
> Or "wrote BS to the output stream" :-)  Exactly the same applies to
> writing '\f', '\r' or '\v' without an associated '\n' to a file
> with ANSI control characters, '\f', '\r' or '\v' to a file with
> no control character support, '\a' or '\t' to an MVS text file,
> more characters that would fit in a record, and so on.
>
> Yes, I can confirm that your view of the process is considerably
> closer than Pete Becker's.  Been there, done that.  Twice, actually.
>

Same here. Twice, too. But the C standard doesn't talk about the
"process," it talks about the meaning of alphabetic escape sequences.
And as I've said several times, it's often convenient to implement those
semantics by emitting control characters that the device will handle
appropriately. But that doesn't mean that the way the device handles the
control characters defines what the standard requires.

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

Greg Brewer wrote:
>
> Pete Becker <petebecker@acm.org> wrote in message
> news:37EFBEAF.2BCACEA7@acm.org...
> > > void PrintBold(const char *text)
> > > {
> > >    if (IsOragami3000())
> > >       fprintf(stdprn,"\eB%s\en", text);
> > >    else if (IsOragami5000())
> > >       fprintf(stdprn,"\eBt%s\ent", text);
> > >    else if (IsDunkirk())
> > >       fprintf(stdprn,"\e4[8]%s\e4[1]",text);
> > > }
> >
> > Sure, you can write this code (which qualifies as a trivial use of \e),
> > but what does it do (which is a non-trivial use of \e)?
>
> Really.  Then we have different definitions of "trivial"!  As to what does
> it do?  The functions name is "PrintBold" and it sends output to stdprn.  I
> know that are purist who believe that every line of code should have a least
> one comment; however, I am not one of them.  Ok, to answer your question, it
> send text to a printer in bold type.  Before sending it, it detects what
> type of printer is attached by some magical means that are outside the scope
> of the exercise so that it knows what codes to send.
>

It's clear from the code what the programmer who wrote it intended it to
do. It's not at all clear that it in fact does that. Compare it with:

fprintf(stdprn, "\t");

Anyone who is familiar with the C standard can tell you what the effect
of that code is.

--
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:
>> Use of fopen() is not strictly conforming; it relies on something
> implementation-defined.

NOt necessarily.  If the filename is a command-line argument,
for example, or is read on stdin, then in effect part of the
"program" is provided by the execution environment, to which
the responsibility for providing a valid filename has devolved.
It becomes impossible in such a case to know that the program
is strictly conforming by examining the source code, but the
fact that it *might* be means it should be considered as such
from the code-checking perspective.
---
[ 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              ]

Greg Brewer wrote:
> ... it send text to a printer in bold type.

But clearly it is not very close to portable even if \e is supported.


[ 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 in message
news:m3ogepjqka.fsf_-_@multivac.student.cwru.edu...
> Yes, until someone is in the situation of trying to implement C++, and
> has no way to know what to do with control characters.  Saying "this \
> sequence becomes the character with that name" is no good unless you
> also provide a reference to some other document that tells what those
> named characters are supposed to do.

Someone implementing C++ would know exactly what to do with the control
characters.  The do the same thing with the control characters that they do
with all of the rest of the characters.

> I expect those were meant for you to define.  I.e., on each system you
> develop on, have a header specific to that system (uniformly named
> across all systems), which defines ASCII or EBCDIC as appropriate.

I know of no implementations of that define ASCII.

> Well, it's obvious that a macro isn't syntactically equivalent to an
> escape sequence.  But a macro can be just as useful.
>     #define ESC "\033" /* or whatever */
>     const char *str = "ghgh" ESC "^]";
>     if (str[5]==ESC[0]) return;

Nope, the definition of ESC would be incorrect on an EBCDIC computer.

> It's not quite as pretty, but it gets the job done.  You could also
> define ESCs and ESCc to be string and character constants,
> respectively, to avoid the [0].

\e would be a lot easier and portable to boot.

Greg Brewer
---
[ 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> wrote in message
news:37EE70E8.79A06CBA@acm.org...
> 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?

Ok.

void PrintBold(const char *text)
{
   if (IsOragami3000())
      fprintf(stdprn,"\eB%s\en", text);
   else if (IsOragami5000())
      fprintf(stdprn,"\eBt%s\ent", text);
   else if (IsDunkirk())
      fprintf(stdprn,"\e4[8]%s\e4[1]",text);
}

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

Not this one though.  It can't be by its nature.  But it is still very
useful.

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

But it does.

> The C standard does just that:
>
> \t (horizontal tab) Moves the active position to the next
> horizontal tabulation position on the current line.

But that doesn't always happen.  If I am running a Windows program and I
type the tab key then the cursor usually moves to the next input field which
may be anywhere on the current window and expect that a some point in the
processing of that keystroke, code to the same effect as "if (? == '\t')"
is executed.

Greg Brewer
---
[ 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 in message
news:m3hfkhjnyi.fsf@multivac.student.cwru.edu...
> 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

That is not the case at all.  The only character that I know of that is
handled in anyway other than just passing it on is the '\n' character when a
text mode stream is involved.

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

I would prefer "device defined".  The C/C++ implementation really has no say
in how it is defined.

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

Why?  No one is offering any guarantee, recommendation, or even suggestion
on what it will do.  It is the programmers responsibility to know what it
will do.  If the programmer does not know what it will do then the
programmer is invited to not use it.

Greg Brewer
---
[ 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> wrote in message
news:37ED2C01.2EA60F19@acm.org...
> > The standard doesn't make any distinction between text and binary mode
> > streams with regard to display devices.
>
> In standard C you cannot create a binary stream that writes to a display
> device.

Yes you can!  Just fopen a display device.  Piece of cake.

Greg Brewer
---
[ 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> wrote in message
news:37ECF282.E4B5277C@acm.org...
> No, it defines the semantics of writing a string to a display device
> when that string's source text contains an escape sequence.

Tell me again what are the semantics of writing a \f to a display device.  I
have this vision of my monitor being ejected and a new one put in its place.

Greg Brewer
 .
---
[ 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 in message
news:m3r9jljt2y.fsf@multivac.student.cwru.edu...
> Yes, there is: the standard provides no means of opening a stream so
> that it will be hooked up to the same output channel as stdout or
> stderr, nor is "/dev/tty" (or whatever) necessarily a legal filename
> to pass to fopen().

That standard does not, and can not, define a legal filename.  So, by your
definition, using fopen will violate some provision of the standard because
the filename is not a defined, legal filename.  Is this what you mean to
say?

Greg Brewer


[ 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 in message
news:m3g101jnlo.fsf@multivac.student.cwru.edu...
> The OS is irrelevant.  A Win3.1 program will treat LF and CR-LF the
> same way under Win9x as it did under Win3.1.  What is different is
> that there are new programs, or new versions of old programs, that
> treat LF the same as CR-LF.  This doesn't tell you anything about any
> particular C implementation's external representation of text files.

True, but the type command will treat LF and CR-LF the same way.

Greg Brewer


[ 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 <7sj28v$c0e$1@news.hal-pc.org>,
Greg Brewer <nospam.greg@brewer.net> wrote:
>
>Nick Maclaren <nmm1@cus.cam.ac.uk> wrote in message
>news:7sfnkn$ccs$1@pegasus.csx.cam.ac.uk...
>> In article <7seci4$4vn$1@news.hal-pc.org>, "Greg Brewer"
><nospam.greg@brewer.net> writes:
>> |> Paul Jarc <prj@po.cwru.edu> wrote in message
>> |> news:m34sglqrcb.fsf@multivac.student.cwru.edu...
>> You mean 'conforming', not 'strictly conforming', I think.  It certainly
>> is NOT allowed in strictly conforming code, as there is no function to
>> change the mode of a stream without closing and reopening it.
>
>Yes it is.  A strickly conforming implementation can provide a function that
>can change the mode of a stream.  Nor would using such a function cause a
>program to be any less conforming.

Please look up "strictly conforming" in the standard.  There is no
such thing as a strictly conforming implementation, not can a strictly
conforming program call anything that is implementation defined
(including any extensions.)


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              ]

Pete Becker wrote:
> It can be said much more simply: "Unlike all other character constants,
> whose values in the exeuction character set are implementation defined,
> the value of \e in the exeuction character set must be 27."

But that's *not* what people are asking for -- C already provides
a simple way to code *that*.


[ 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 in message
news:m3k8pdjpma.fsf@multivac.student.cwru.edu...
> A strictly conforming program can use functions that it defines, but
> it cannot use implementations' extensions.  It cannot use an
> implementation's setmode(), and setmode() cannot be implemented in
> strictly conforming code.

How can you say that?  Using functions not defined by the standard does not
make a program less conforming.  setmode() can too be implemented in
strictly conforming code.

Greg Brewer


[ 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:AxJG0GTPyM73Ew$P@romana.davros.org...
>
> 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.

What do yo want the substitution to be?  And why would you care?  If you
don't use it then it won't cause you any problems no matter what it is
defined for.

On the other hand, if you want to hook up an HP printer to your Torch
Unicorn or Psion 3a then you might actually want to do things like bolding
characters and setting page margins.  To do those things, you will need to
send out an escape character.  The substitution value should be whatever is
required to acheive that result.

Greg Brewer




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

Greg Brewer wrote:
>
> Paul Jarc <prj@po.cwru.edu> wrote in message
> news:m3k8pdjpma.fsf@multivac.student.cwru.edu...
> > A strictly conforming program can use functions that it defines, but
> > it cannot use implementations' extensions.  It cannot use an
> > implementation's setmode(), and setmode() cannot be implemented in
> > strictly conforming code.
>
> How can you say that?  Using functions not defined by the standard does not
> make a program less conforming.  setmode() can too be implemented in
> strictly conforming code.

"strictly conforming" applies to a whole program; when applied to
individual pieces of code the definition is problematic. There can also
be pieces of code that can't be the reason why a program isn't strictly
conforming, so it might be reasonable to call such code "strictly
conforming". However, for most code you have look for interactions with
the entire rest of the program to determine strict conformance.

Specifically, you could call freopen(NULL, "wb", stdout), but whether or
not that will work is implementation-defined. That's not a problem in
itself, but it will be a problem the next time you write to stdout. In
that case, you will be producing "output dependent upon ...
implementation-defined behavior", which is specifically forbidden to
strictly-conforming programs. Now, what would be the point of calling
freopen(NULL, "wb", stdout), unless you're planning to write to stdout?


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

Greg Brewer wrote:
>
> Pete Becker <petebecker@acm.org> wrote in message
> news:37ED2C01.2EA60F19@acm.org...
> > > The standard doesn't make any distinction between text and binary mode
> > > streams with regard to display devices.
> >
> > In standard C you cannot create a binary stream that writes to a display
> > device.
>
> Yes you can!  Just fopen a display device.  Piece of cake.
>

Let me rephrase my other response a bit less aggressively.

Many compilers recognize special file names, and open a stream connected
to a device when such a name is used. (e.g. with many DOS compilers,
passing "lpt1:" to fopen as the file name creates a stream that writes
bytes to the first parallel port, which usually is connected to a
printer). There's nothing in the C standard that says that that has to
work, much less anything that requires the use of any particular string
to refer to any particular device. So while many compilers allow you to
open a stream to a display device, the C standard does not. It's a
useful extension, but relying on it in a program makes that program not
strictly conforming.

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

Greg Brewer wrote:
>
> Paul Jarc <prj@po.cwru.edu> wrote in message
> news:m3r9jljt2y.fsf@multivac.student.cwru.edu...
> > Yes, there is: the standard provides no means of opening a stream so
> > that it will be hooked up to the same output channel as stdout or
> > stderr, nor is "/dev/tty" (or whatever) necessarily a legal filename
> > to pass to fopen().
>
> That standard does not, and can not, define a legal filename.  So, by your
> definition, using fopen will violate some provision of the standard because
> the filename is not a defined, legal filename.  Is this what you mean to
> say?
>

What it means is that the C standard does not give any meaning to the
string "/dev/tty" (or any other string) when it is used as the name of a
file. In particular, the C standard does not require that fopen create a
stream that talks to the display device when it is given that string as
the file name. Many runtime libraries recognize specific strings as the
names of devices, but that is an implementation-specific extension, and
not required by 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              ]

"Douglas A. Gwyn" wrote:
>
> Pete Becker wrote:
> > It can be said much more simply: "Unlike all other character constants,
> > whose values in the exeuction character set are implementation defined,
> > the value of \e in the exeuction character set must be 27."
>
> But that's *not* what people are asking for -- C already provides
> a simple way to code *that*.
>

That is what the message that I replied to suggested.

--
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> wrote in message
news:37EFCEA9.40999765@acm.org...
> Let me rephrase my other response a bit less aggressively.
>
> Many compilers recognize special file names, and open a stream connected
> to a device when such a name is used. (e.g. with many DOS compilers,
> passing "lpt1:" to fopen as the file name creates a stream that writes
> bytes to the first parallel port, which usually is connected to a
> printer). There's nothing in the C standard that says that that has to
> work, much less anything that requires the use of any particular string
> to refer to any particular device. So while many compilers allow you to
> open a stream to a display device, the C standard does not. It's a
> useful extension, but relying on it in a program makes that program not
> strictly conforming.

It may be true that there are compilers that recognize special file names --
there may even be many but I doubt it; however, it is not the compiler that
connects the special name to the define, it is the operating system.   The
application I support was written for DOS.  When it was written,  UNC
filenames were not valid.  But when under Win95, it will read and write to a
UNC filename.  That is because it just passes the given name to the OS.

Greg Brewer


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

Greg Brewer wrote:
>
> Pete Becker <petebecker@acm.org> wrote in message
> news:37EFCEA9.40999765@acm.org...
> > Let me rephrase my other response a bit less aggressively.
> >
> > Many compilers recognize special file names, and open a stream connected
> > to a device when such a name is used. (e.g. with many DOS compilers,
> > passing "lpt1:" to fopen as the file name creates a stream that writes
> > bytes to the first parallel port, which usually is connected to a
> > printer). There's nothing in the C standard that says that that has to
> > work, much less anything that requires the use of any particular string
> > to refer to any particular device. So while many compilers allow you to
> > open a stream to a display device, the C standard does not. It's a
> > useful extension, but relying on it in a program makes that program not
> > strictly conforming.
>
> It may be true that there are compilers that recognize special file names --
> there may even be many but I doubt it; however, it is not the compiler that
> connects the special name to the define, it is the operating system.   The
> application I support was written for DOS.  When it was written,  UNC
> filenames were not valid.  But when under Win95, it will read and write to a
> UNC filename.  That is because it just passes the given name to the OS.
>

Now I'm confused. My point was that the C standard does not require that
any string map to a device, so strictly conforming code cannot rely on
using fopen to create a stream that talks to a display device. You seem
to be disagreeing with the details of the way I explained it, but you
have not addressed, one way or the other, the substance of that
assertion. So do you still claim that fopen can be used to create a
stream that writes to a display device in a strictly conforming C
program?

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

Greg Brewer wrote:
...
> It may be true that there are compilers that recognize special file names --
> there may even be many but I doubt it; however, it is not the compiler that
> connects the special name to the define, it is the operating system.   The

Not necessarily; an operating system might not provide file-based access
to a device at all - it could provide an entirely different way of
controlling it. Despite that fact, an implementor of C might choose to
make file-based access available through a special implementation of
fopen() which recognises the compiler-defined, rather than OS-defined,
name used for that device, and modifies various I/O functions to
translate file-base I/O to that file into the interface specified by the
OS.

You've got to keep in mind that there are many different kinds of
systems that C is implemented on. Many of those systems don't obey the
same kind of distinctions between program/compiler/linker/OS/hardware
that you're used to.


[ 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 <nmm1@cus.cam.ac.uk> wrote in message
news:7sfnkn$ccs$1@pegasus.csx.cam.ac.uk...
> In article <7seci4$4vn$1@news.hal-pc.org>, "Greg Brewer"
<nospam.greg@brewer.net> writes:
> |> Paul Jarc <prj@po.cwru.edu> wrote in message
> |> news:m34sglqrcb.fsf@multivac.student.cwru.edu...
> You mean 'conforming', not 'strictly conforming', I think.  It certainly
> is NOT allowed in strictly conforming code, as there is no function to
> change the mode of a stream without closing and reopening it.

Yes it is.  A strickly conforming implementation can provide a function that
can change the mode of a stream.  Nor would using such a function cause a
program to be any less conforming.

> |> Also, you can open another stream in binary-mode that will write to the
> |> screen.
> That is REALLY asking for trouble!  Think synchronisation.

There is nothing in the standard to stop a strickly conforming program from
"asking for trouble" as you put it.  I personally would advise against it
but doing so is perfectly legal.

Greg Brewer


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

Peter Seebach wrote:
>
> In article <37EC3125.EA4EBBAA@acm.org>,
> Pete Becker  <petebecker@acm.org> wrote:
> >Then it has to be defined in a way that's portable, and that means
> >describing what it's expected to do.
>
> Hmm.  How about
>         \e      Converts to a character which, when output, is likely to
>                 be translated to an ASCII escape (0x1b) if the output
>                 environment is ASCII.  Otherwise, the value is implementation
>                 defined.
>
> I know we can't say that, but I think that's what everyone means.

It can be said much more simply: "Unlike all other character constants,
whose values in the exeuction character set are implementation defined,
the value of \e in the exeuction character set must be 27."

--
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 <prj@po.cwru.edu> wrote in message
news:m3g104b5s0.fsf_-_@multivac.student.cwru.edu...
> "Greg Brewer" <nospam.greg@brewer.net> writes:
> > Paul Jarc <prj@po.cwru.edu> wrote in message
> > news:m34sglqrcb.fsf@multivac.student.cwru.edu...
> > Again, not true.  I know I have seen a function somewhere that will change
> > the mode of a stream.
>
> Yes; I'd not known of this use of freopen.
>
> > Also, you can open another stream in binary-mode that will write to the
> > screen.
>
> Not in strictly conforming code.

There is not such restriction.

Greg Brewer


[ 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 Jr. <kuyper@wizard.net> wrote in message
news:37EB78E8.262ADD4F@wizard.net...
> Greg Brewer wrote:
> Do you know the name of it? I remember seeing a setmode() function, but
> it's not a part of the C standard.

I think freopen will do it but I'm not sure.  It was probably setmode().
BTW, using functions that are not part of the standard is perfectly legal.
Otherwise, all programs would only have a main and recursion would be next
to impossible.

Greg Brewer




[ 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> wrote in message
news:37EB6D4A.F8B203A3@acm.org...
> Yes, and that choice is driven by the knowledge that the stream being
> written to is attached to a display device.

That's not true.  The same translation takes place when the stream being
written to is attached to a file or anything else.

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

That would not be improper.  The output may not be interactive.  It may be
writting to stdout which is connected to stdin of another process that might
need to receive that alert.

Greg Brewer


[ 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> wrote in message
news:37EB67DA.35679E6E@acm.org...
> standard. The C output code typically calls isatty to determine whether
> it's writing to a display device, and adjusts its output accordingly.
> Once you pipe its output to some other program, it's that other program
> that determines what gets displayed.

And that is where you are wrong.  C output code doesn't not typically call
isatty to determine anything about the output.  In this case, if foo has
stdout opened in text mode and more is a C program that has stdin opened in
binary mode then more will the both \r and \n.

Greg Brewer




[ 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 <francis@robinton.demon.co.uk> wrote in message
news:umA+FLAu1163EwDZ@robinton.demon.co.uk...
> In article <7sde3s$2gue$1@news.hal-pc.org>, Greg Brewer
> I would strongly resist this concept (C++ as almost a superset of future
> C standards).  What we could use would be a mechanism for informing
> those concerned that we will consider a specific feature and incorporate
> it to the extent possible.  For example C9X's 'restrict' keyword
> certainly cannot just be dumped into C++ but we might consider it useful
> enough to want to incorporate some refined version with as much
> compatibility as possible with its use in C.

That is what I had in mind.  If 'restrict' cannot be easily incorporated
into C++ then silence on the issue would identify that as a C feature that
should not be incorporated into a C++ compiler when C is updated.  But how
about a 'long long' integer.  That should cause no problem to C++ except in
portability.  Programmers using "appreciated" features do so at their own
risk.

Dave Tribble has documented a number of proposed C features and marked those
likely to be adopted before they are formally incorporated into C++ at the
first opportunity.  I think that it would be helpful to those designing the
version of a compiler to know what features can be incorporated in their new
version of the compiler with a least some knowledge that the C++ standard
intends to go in that direction.

I don't think that it is accurate to say that "C++ is almost a superset of
future C standards."  I remember seeing a quote to the effect that the C
committee feels no obligation at all to go in the direction C++ has gone.
Staying ahead of a moving target can be very difficult.

Greg Brewer




[ 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 Jr." <kuyper@wizard.net> writes:
> I don't know the relevant DR, but others with more knowledge than I have
> frequently said that implementation-defined behavior can, at least for
> some features, vary from one run of the compiler to the next, or even
> from one instance of a feature to another in the same program during the
> same translation. I'd love to know precisely what the official word is
> on that issue. Can anybody cite the relevant text?

Well, this isn't the DR, but C9X 3.11p1 says:
# implementation-defined behavior
# unspecified behavior where each implementation documents how the
# choice is made

This apparently doesn't require the choice to be made before compile
time, or run time, or whatever, nor does it bar the implementation
from considering any particular piece of information in making its
choice.


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              ]

"Greg Brewer" <nospam.greg@brewer.net> writes:
> James Kuyper Jr. <kuyper@wizard.net> wrote in message
> news:37EB78E8.262ADD4F@wizard.net...
> > Do you know the name of it? I remember seeing a setmode() function, but
> > it's not a part of the C standard.
>
> I think freopen will do it but I'm not sure.  It was probably setmode().
> BTW, using functions that are not part of the standard is perfectly legal.
> Otherwise, all programs would only have a main and recursion would be next
> to impossible.

A strictly conforming program can use functions that it defines, but
it cannot use implementations' extensions.  It cannot use an
implementation's setmode(), and setmode() cannot be implemented in
strictly conforming code.


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              ]

"Greg Brewer" <nospam.greg@brewer.net> writes:
> Pete Becker <petebecker@acm.org> wrote in message
> news:37EC20CA.340FB619@acm.org...
> > change in the platform's conventions. Try opening a file that has no CRs
> > in notepad.
>
> I do it all the time.  Other than having to turn on word wrap, not big deal.
> What was your point?

The point is that the sensitivity to \n vs. \r\n varies between
programs; you can't just expect a program to work exactly the same way
with \n under a newer OS as it did with \r\n under the older OS.  Even
the Win9x versions of Notepad behave differently for \n and \r\n.  The
*conventions* may be different for the newer OS, but that doesn't
necessarily affect any particular program.


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              ]

Greg Brewer wrote:
> I remember seeing a quote to the effect that the C
> committee feels no obligation at all to go in the direction
> C++ has gone.

That is at best misleading.  Part of the C standards committee's
charter, and a working principle, has been to minimize differences
in the overlapping part of Standard C and Standard C++.  Not every
such difference can be eliminated; for example, C++ from the very
start gave a different semantic interpretation to
 int foo();
and it was not practical for the C standard to bless that change.
However, compatibility with Standard C++ has been a great force
within the C standards deliberations, often having major effect
on our decisions.


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

"Greg Brewer" <nospam.greg@brewer.net> writes:
> Paul Jarc <prj@po.cwru.edu> wrote in message
> news:m3g104b5s0.fsf_-_@multivac.student.cwru.edu...
> > "Greg Brewer" <nospam.greg@brewer.net> writes:
> > > Also, you can open another stream in binary-mode that will write to the
> > > screen.
> >
> > Not in strictly conforming code.
>
> There is not such restriction.

Yes, there is: the standard provides no means of opening a stream so
that it will be hooked up to the same output channel as stdout or
stderr, nor is "/dev/tty" (or whatever) necessarily a legal filename
to pass to fopen().


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              ]

In article <7sj2km$c2c$1@news.hal-pc.org>, Greg Brewer
<nospam.greg@brewer.net> writes
>> > Also, you can open another stream in binary-mode that will write to the
>> > screen.
>> Not in strictly conforming code.
>There is not such restriction.

Yes there is - there's no file name that will guarantee to route to
stdout.

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

Pete Becker <petebecker@acm.org> wrote in message
news:37EC3125.EA4EBBAA@acm.org...
> Then it has to be defined in a way that's portable, and that means
> describing what it's expected to do.

Why can't you except that what it is expected to do is device dependant?
What it is expected to do varies with both device and context.

> The C++ standard takes a different approach, defining the escape
> charaqater sequences by using various undefined terms like LF, HT, BEL.
> (Yes, we all know what those usually mean, but standards are supposed to
> explicitly define their terms whenever possible). The table that lists
> these things appears in the ARM, and I don't recall any discussion in
> the standards committee about this. I think it was a mistake in the
> beginning, and I don't think it was seriously examined in the courser of
> adopting the standard.

I disagree.  I think the C approach was the mistake.  The C approach was
handled more like Jeopardy; they new the answer but had to struggle to come
up with the question.  Now, we have to follow that precedent?  I think not.
Let's follow the one set by C++.  Makes life a lot less complicated.

> Regardless of what I think of that approach, though, it isn't the
> approach that the C standard takes. Adding \e to C would produce a lump,
> and the benefit seems small, since the same effect can be achieved in C
> as it exists today:
> #if ASCII
> #define ESC '\033'
> #elif EBCDIC
> #define ESC 'whatever'
> #else
> ....
> #endif

You do seem to be in the minority in thinking that the benefit would be
small.  The tide against you seems to be about 10 to 1.

You are wrong about being able to achieve the same effect as well.  First,
the conditional compilation code you use won't work; I know of no C compiler
that defines the macros your example demonstrates.  Second, it wouldn't work
well
   const char *str = "ghghESC^]";   // treats ESC as 3 characters
   const char *str = "ghgh" ESC "^]";  // compiler error
And before you modify the definition to accommidate the second case
   if (str[5] == ESC) return;
would fail in the modified case.

Greg Brewer




[ 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> wrote in message
news:37EC20CA.340FB619@acm.org...
> change in the platform's conventions. Try opening a file that has no CRs
> in notepad.

I do it all the time.  Other than having to turn on word wrap, not big deal.
What was your point?

Greg Brewer




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

Greg Brewer wrote:
>
> Pete Becker <petebecker@acm.org> wrote in message
> news:37EB6993.5DBBDE83@acm.org...
> > And the runtime code has to be able to adjust what it does accordingly,
> > typically by asking the OS whether the stream that it's writing to is a
> > display device. If it is, it to does whatever is needed to produce the
>
> I don't believe this is the case.  I pretty sure that it does something like
>    if (c == '\n' && stdout->mode & O_TEXT)
>       putch('\r');
>    putch(c);
>

Yes, I must have been hallucinating when I wrote that.

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

petebecker@acm.org (Pete Becker)  wrote on 23.09.99 in <37E98EAA.BDEBD6C@acm.org>:

> Kai Henningsen wrote:
> >
> > petebecker@acm.org (Pete Becker)  wrote on 21.09.99 in
> > <37E6EC0A.40DDF311@acm.org>:
> >
> > > The C standard talks about intended behavior, which is more than anyone
> > > has been willing to do with regard to \e.
> >
> > Untrue.
> >
>
> Sigh. Once again, please state the effect on the display of including
> the character \e in a character string that is displayed with printf.

I have done so multiple times; I see no reason to repeat myself yet again,
just because you insist on lying about it.


Kai
--
http://www.westfalen.de/private/khms/
"... by God I *KNOW* what this network is for, and you can't have it."
  - Russ Allbery (rra@stanford.edu)


[ 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 <37EC3125.EA4EBBAA@acm.org>,
Pete Becker  <petebecker@acm.org> wrote:
>Then it has to be defined in a way that's portable, and that means
>describing what it's expected to do.

Hmm.  How about
 \e Converts to a character which, when output, is likely to
  be translated to an ASCII escape (0x1b) if the output
  environment is ASCII.  Otherwise, the value is implementation
  defined.

I know we can't say that, but I think that's what everyone means.

>#if ASCII
>#define ESC '\033'
>#elif EBCDIC
>#define ESC 'whatever'
>#else
>....
>#endif

But then you have to do concatenation, or %c's, or something, and what people
seem to be asking for is a nice way to do this in string literals that doesn't
require further programmer-visible effort.

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

Greg Comeau wrote:
>
> Note my remark that he didn't care about portability (at least that's
> how I understood it) so telling me how to portability specify it seems
> neither here nor there.

I said I don't personally care about portability, because I will almost
certainly never write for anything other than an ASCII machine. But I went
on to explain that \e would have the added benefit that it would aid
portability between character sets (like all the other backslash escapes),
for people who need that sort of thing.

--

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:
>
> Finally, I personally don't believe that \e is worth the effort. The
> commonest use of escape sequences is display control, and such sequences
> should be in data files, not code.

That's a parochial view. Often I write code that I _know_ controls a device
that understands certain escape sequences.

For instance, one might be a programmer for HP, writing a driver for HP
printers. The code would be probably be peppered with PCL escape sequences,
which are universal across all HP printers. But there would be no reason to
put these strings in data files, or even bury them in #defines, because the
driver will never be ported to any non-HP printer.

--

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              ]

Steve Downey wrote:
>
> James Kuyper <kuyper@wizard.net> writes:
>
> > Steve Downey wrote:
> > ...
> > > No, it would produce implementation-defined behavior. The
> > > implementation would be required to document what, if anything, \e
> > > did. In particular, \e would always have the same interpretation. It
> > > could not occasionally start WW3.
> >
> > Why not, so long as they document the fact?
>
> Well, I suppose it would be OK if it always started WW3. But for

It only can do it once; the next time it would have to be WW4.

> implementation defined behavior, as I recall, an implementation must
> be consistent. I also would be surprised if starting WW3 was one of

No - it's merely required to document the nature of it's inconsistency.
I don't know the relevant DR, but others with more knowledge than I have
frequently said that implementation-defined behavior can, at least for
some features, vary from one run of the compiler to the next, or even
from one instance of a feature to another in the same program during the
same translation. I'd love to know precisely what the official word is
on that issue. Can anybody cite the relevant text?

> the range of choices that the standard provided to the implementation.

Notheless, that's what's being proposed: in various forms, it's
proponents say only that '\e' should have implementation-defined effects
when displayed. None of them has proposed a definition of those effects
that would prohibit such an implementation.


[ 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 <7sgl08$1oha$1@news.hal-pc.org>, 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.

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

comeau@panix.com (Greg Comeau) writes:
> Note my remark that he didn't care about portability (at least that's
> how I understood it) so telling me how to portability specify it seems
> neither here nor there.

I went back and looked, and it looks like you misunderstood.
He wants to write a portable program which sends specific
escape sequences to an ASCII printer. I assume that, like
most such sequences, the ESC is the only non-printable
character in the sequence. When this program runs on an
EBCDIC machine, he assumes that his output will pass through
an EBCDIC-to-ASCII translator before going to the printer.
Therefore, he wants to use \e in his strings, which will be
translated by the compiler to an EBCDIC ESC, which will be
translated to an ASCII ESC by the protocol converter. If he
embeds \x1B in his strings, that is *not* an EBCDIC ESC, and
the EBCDIC-to-ASCII translator will translate it to something
quite different than an ASCII ESC.


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

Greg Brewer wrote:

> root <jdennett@acm.org> wrote in message news:37E977A0.CC9FF2F8@acm.org...
> >
> > > #include <iostream>
> > > main()
> > > {
> > >  std::cout << 'a' << '\t' << 'b' << '\n';
> > > }
> > >
> >
>  > Yes, in that code the compiler will have translated the '\t', and call
> > something like
> > std::cout::operator <<(char).  The actual 'char' value which gets passed
> to
> > this depends on the compiler's knowledge of the environment which is
> targetted
> > -- if that environment doesn't support a horizontal tab character then I
> > suppose (and maybe Pete Becker or other library implementors could comment
> > here) that its at this level or below that they might intercept their
> chosen
> > '\t' char and call some code to move the current output position suitably.
> The
>
> The problem with this example is that it would never be proper for any
> library implementor to intercept the call sending any text to the standard
> output.  I would expect the compiler to either generate a direct call to the
> OS's api or a call to a runtime library function that would call one or more
> OS api functions that would send the character code to the standard output.

That's consistent with what I said -- at the level of std::cout::operator <<
_or below_.   I was too loose; it should be done at the level where the library
knows that the output is destined for a display device.  (Is that right?)

> One important thing to remember about standard output is that it isn't
> necessarily a display.  In many OS's, standard output can be a file, a
> printer, the standard input of another program, or a named pipe.
>

And other things besides -- these things being outside the scope of the
C++ (Language) Standard.

>
> I would not want a library implementer to change the output stream destined
> for another program's input stream to change the tab to a series of spaces.
> I once faced a similar situation where the stream was directed to a
> destination that was not supported by the application.  In order to get the
> stream to work, I had to use a hook to reformat text formatted for a
> supported printer.  Then I ran out of gas.  The supported printer didn't
> support a tab so all the tabs where converted to spaces.  It's rather
> difficult to unconvert them.
>
> On the other hand, if you are sending stuff to standard output, it may be
> necessary.  For my applications, I have defined an object called Printer
> that acts as an interface to a printer.  Therefore, I would have the code
>      Printer printer;
>      printer << 'a' << '\t' << 'b' << '\n';
> and it will then process the characters 'a', tab, 'b' and newline.  At this
> time, I don't support sending tab characters to my printer object in the way
> I should.  I have some plans along those lines but I have not had the time.
> This does demonstrate a good point though.  In the processing for my object,
> I would just send the tab on to the Windows printer manager and let it worry
> about it.  I say "would" since everyone using my printer object has been
> instructed not to use that character and an alternate means of tabbing is
> provided.  I do provide special processing for the new line character since
> I have to change the column and line number for subsequent output.  Now, if
> this \e character were implemented, it would be treated no different than a
> \t is handled.  BTW, if this text lacks continuity in some points, I
> apologize.  I have been interupted thrice since I started.
> >
> > So; the compiler maps '\t' to a value of type char, which the runtime
> library
> > is responsible for mapping to the action of a horizontal tab.  Granted, in
> nice
> > clean systems, passing the character through to the host OS unchanged --
> but
> > not for all.  And "most" systems (in some sense) require the library to
> get in
> > the way of '\n' because there's no single byte which can be written to
> their
> > console to have the desired effect.
>
> Still, the operation should be handled at the lowest level possible.  The
> compiler vendor should have supplied an output routine that should handle
> the translation.  If a library routine is interacting with a specific device
> then it would be proper to process the special sequences.

Yes, that's what I would have said if I'd said things better than I did :)

>
>
> > Without trying to start a vote, I'd think that this is a reasonable thing
> to
> > add to a future C++ standard (though I can't see that I'd ever have a use
> for
> > it in my line of work).
> > 1.  It would make one less incompatibility between C and C++.   ("As close
> as
> > possible...").
> > 2.  It would make some (probably non-portable) code more readable.
> > 3.  It has clearly-defined semantics.
> > 4.  It would not break any existing code.
>
> This would not decrease incompability between C and C++; neither standard
> defines \e.

My error; I was referring to the forthcoming revised C standard, which I
believe will define \e.  Areas on which I'm not an expert include (but are
certainly not limited to) the C Standard as it exists today.

> Adding it will create a short-term incompatibility since both
> standards can't be updated simultaneously.  Personally, I think that if C++
> is going to continue to be a more-or-less superset of C then it will be
> necessary to create some mechanism to "appreciate" new C standards for the
> C++ standard; i.e, tell vendors that some new C feature will be incorporated
> in the C++ standard "as is" at the earliest opportunity unless some
> extraordinary issue arises.  Since most C++ vendors sell a C compiler too,
> this would give them a head start in complience.
>
> In fact, there is an argument that this would make code more portable since
> the ESC character is different in ASCII and EBCDIC.
>

Again, my words were imprecise.  I was using portable to mean "completely
portable to any platform with a conforming C++ compiler", not just "portable
across a range of platforms".  Portability of less-than-perfectly portable code
could be improved by the addition of \e to the C and C++ Standards.


[ 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> wrote in message
news:37EB5F58.144813B@acm.org...
> Yup. And if that's the definition, what can you use it 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.

I'll give it another shot.

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.  printf and
all the out routines that can output to a display should treat the character
substituted for \e the same as it does 'A' or 'b' or '.' or any other
character.

Greg Brewer




[ 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 <37E8EB86.DC88AE9F@physik.tu-muenchen.de>, Christopher
Eltschka <celtschk@physik.tu-muenchen.de> writes
>Now, the standard expresses an *intent* of what \n
>should do. It could also express an intent what \e
>should do. Even if on some systems that intent cannot
>be followed, it's no problem - the same may be true
>for \b. The intent is *not* binding, but nevertheless
>a way to get compiler vendors do the right thing.
>
>If the standard demanded \e, and gave the intent, then
>you could expect code containing "\e" to work. If on your
>compiler it doesnm't work, but the execution character set
>has an ESC character, you could blame your compiler vendor

There's two or three parts to this.

Firstly, it's clear (I hope) that each of \n, \b, \r, and so on map to a
single byte value. To that extent they are like \012, except that the
value varies from implementation to implementation. To that extent, \e
would be just the same. That's all the Standard requires
unconditionally.

Second is the question of what the value should be. As I understand it,
the C++ Standard says something like:
    \n   is  NL
    \b   is  BS
    \a   is  BEL
leaving us to wonder what on earth NL, BS, BEL, and so on are. In this
world view adding "\e is ESC" is easy.

However, C has a different world view. In effect, what it says is
something like:
    \b is the value which, if sent to a display device, would cause
    the active position to move backwards one place
(this is not the actual wording, but I think it's the intent). In this
world view, it's easy to define the existing escape codes, but what
would you say for \e:
    \e is the value which, if sent to a display device, would cause
    ...
What would you put instead of the ellipsis ?

Finally, I personally don't believe that \e is worth the effort. The
commonest use of escape sequences is display control, and such sequences
should be in data files, not code.

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

Pete Becker <petebecker@acm.org> writes:
> Where in the standard does it say that only \n is handled differently?

Why, nowhere, and yet only \n is handled differently! Isn't that odd?


[ 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> wrote in message
news:37EB6993.5DBBDE83@acm.org...
> And the runtime code has to be able to adjust what it does accordingly,
> typically by asking the OS whether the stream that it's writing to is a
> display device. If it is, it to does whatever is needed to produce the

I don't believe this is the case.  I pretty sure that it does something like
   if (c == '\n' && stdout->mode & O_TEXT)
      putch('\r');
   putch(c);

  If stdout has been freopened in binary mode then only \n will be sent
reguardless of whether the output device is a display.

One complicating factor in this is a change in Win/Dos.  Recent versions no
longer require the translation.  I discovered this recently when I
accidently coded a program that created a text file in binary mode.  On my
Windows 95 machine, it looked and acted fine.  I could open it in edit and
type it to the screen and everything looked fine.  When my customer did the
same thing on his Windows 3.1 system, he got quite different results.

Greg Brewer




[ 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> wrote:

> The character set that I have in mind is ASCII, which has no newline
> character.

ASCII has included a newline character since 1968.  The relevant
text of the standard reads:

  LF (Line Feed): A format effector which controls the movement of
  the printing position to the next printing line.  (Applicable
  also to display devices.)  Where appropriate, this character may
  have the meaning "New Line" (NL), a format effector which controls
  the movement of the printing point to the first printing position
  of the next printing line.  Use of this convention requires
  agreement between sender and recipient of data.

ISO 646 contains similar language.

Eric


[ 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:
[ on translating \n to \r\n, etc. ]
> That's consistent with what I said -- at the level of std::cout::operator <<
> _or below_.  I was too loose; it should be done at the level where the
> library knows that the output is destined for a display device.  (Is that
> right?)

If the transformation is reversible, it can be applied to all text streams.
Then it has the intended effect on a display device, and can be undone when
the file is read back in.  (Witness DOS.)

> > > 1.  It would make one less incompatibility between C and C++.   ("As
> > >     close as possible...").
> >
> > This would not decrease incompability between C and C++; neither standard
> > defines \e.
>
> My error; I was referring to the forthcoming revised C standard, which I
> believe will define \e.  Areas on which I'm not an expert include (but are
> certainly not limited to) the C Standard as it exists today.

No, \e has not been included in C9X.


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              ]

Greg Comeau wrote:
>
> In article <37EBE42A.34C972A1@acm.org> Pete Becker <petebecker@acm.org> writes:
> >
> >Greg Comeau wrote:
> >>
> >> In article <37EA95B4.7D97A8A7@acm.org> Pete Becker <petebecker@acm.org> writes:
> >> >Greg Comeau wrote:
> >> >>
> >> >> 4) The crux??: "To avoid the issue of whether an implementation conforms
> >> >>    if it cannot properly effect vertical tabs (for instance), the
> >> >>    Standard emphasizes that the semantics merely describe intent."
> >> >>    Why isn't this just undefined behavior, and be done with it?
> >> >
> >> >Because the authors of the standard wanted to make a stronger statement
> >> >than leaving the behavior undefined.
> >>
> >> Clearly, but it becomes double-talk'ish.  Ok, it's not undefined.
> >> But it's only defined(yuck) as an intent, not a requirment.
> >> What the heck does that mean Standard-wise and confomring-wise.
> >> Can you detail the implications?
> >
> >Sure: it's required unless it can't be done reasonably.
>
> How do you feel this case, an intent, differs from unspecified behavior?

Because the behavior is specified.

> How do you feel this case, an intent, differs from undefined behavior?

Because the behavior is defined.

> How do you feel this case, an intent, differs from implementation-defined
> behavior?

Because the behavior is not left up to the implementation with an
additional requirement that the implemenation specify what its behavior
is.

>
> I'm trying to find out what "stronger" means.
>

It simply doesn't fit any of those categories. As I said earlier, the
most natural interpretation is that an implementor must do what the
standard says unless it can't be done reasonably.

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

Francis Glassborow wrote:
>
> Paul D. DeRocco <pderocco@ix.netcom.com> writes
>> It doesn't say what these characters must do on
>> any output device, but this isn't a problem because every existing
>> standard character set (which is to say, ASCII and EBCDIC) has
>> corresponding characters, and people know what they do. The same
>> would be true of escape.
>
> I wish we had some input from those that do not use the US alphabet.
> I think that the Japanese might have a different take on this.

Maybe, but doubtful.  Most of their character sets (JIS, etc.) are
derived from ASCII.

But they do have the added joy of dealing with SI/SO and mixed
multibyte character encodings.

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

James Dennett wrote:
...
> My error; I was referring to the forthcoming revised C standard, which I
> believe will define \e.  Areas on which I'm not an expert include (but are
> certainly not limited to) the C Standard as it exists today.

I don't believe that's true; it's not in my copy of the draft C9X
standard. You might also note that this thread has been cross posted to
both comp.std.c and comp.std.c++. It's been drawing criticism from both
sides, and I think that the cross posting has produced considerable
confusion.

Basically, people who've been saying that \t is defined as HT are
correctly describing what the C++ standard says (whether or not that's
what they intended). People who've been saying that \t is defined solely
in terms of it's intended effects when sent to the display device are
correctly describing what the C standard says (whether or not that's
what they intended). My impression is that we've had a lot of people
from both sides participating in this discussion.


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

Greg Brewer wrote:
>
> Pete Becker <petebecker@acm.org> wrote in message
> news:37EB6993.5DBBDE83@acm.org...
> > And the runtime code has to be able to adjust what it does accordingly,
> > typically by asking the OS whether the stream that it's writing to is a
> > display device. If it is, it to does whatever is needed to produce the
>
> I don't believe this is the case.  I pretty sure that it does something like
>    if (c == '\n' && stdout->mode & O_TEXT)
>       putch('\r');
>    putch(c);
>
>   If stdout has been freopened in binary mode then only \n will be sent
> reguardless of whether the output device is a display.

Yes, binary mode doesn't have to deal with devices because the standard
doesn't require writing to a display device in binary mode to work.

>
> One complicating factor in this is a change in Win/Dos.  Recent versions no
> longer require the translation.  I discovered this recently when I
> accidently coded a program that created a text file in binary mode.  On my
> Windows 95 machine, it looked and acted fine.  I could open it in edit and
> type it to the screen and everything looked fine.  When my customer did the
> same thing on his Windows 3.1 system, he got quite different results.

Many editors understand UNIX newline conventions and will display UNIX
files without complaint. That's a convenience for their users, not a
change in the platform's conventions. Try opening a file that has no CRs
in notepad.

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

Greg Brewer wrote:
>
> Pete Becker <petebecker@acm.org> wrote in message
> news:37EB5F58.144813B@acm.org...
> > Yup. And if that's the definition, what can you use it 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.
>
> I'll give it another shot.
>
> All everyone wants is for the string "XYZ\eB" to be portable among
> compilers.

Then it has to be defined in a way that's portable, and that means
describing what it's expected to do.

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

Well, that seems to be what some people want, although whenever I've
reduced it to those terms nobody has said that that's what they want.
<g>

> printf and
> all the out routines that can output to a display should treat the character
> substituted for \e the same as it does 'A' or 'b' or '.' or any other
> character.
>

This is where the problem comes in. The C standard says that when you
write a printable character (e.g. 'A', 'b', or '.') to a display device
you get a graphical representation of that character. That is, the
effect of puts("A") is to put the letter A on the screen. This doesn't
work for non-graphical characters, of course, which is why the standard
says explicitly that '\a' produces an alert, etc. It quite deliberately
stays away from describing output in terms of the values that are sent
to the screen driver, because there are other ways of implementing
character displays (including directly writing to memory mapped video,
as in the example I gave earlier) for which the behavior can't be
adequately described in terms of characters only.

The C++ standard takes a different approach, defining the escape
charaqater sequences by using various undefined terms like LF, HT, BEL.
(Yes, we all know what those usually mean, but standards are supposed to
explicitly define their terms whenever possible). The table that lists
these things appears in the ARM, and I don't recall any discussion in
the standards committee about this. I think it was a mistake in the
beginning, and I don't think it was seriously examined in the courser of
adopting the standard.

Regardless of what I think of that approach, though, it isn't the
approach that the C standard takes. Adding \e to C would produce a lump,
and the benefit seems small, since the same effect can be achieved in C
as it exists today:

#if ASCII
#define ESC '\033'
#elif EBCDIC
#define ESC 'whatever'
#else
....
#endif

--
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:
> > 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. 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?
>
> No you don't. On DOS, the compiler translates '\n' into a single ASCII
> character whose value is 10. Certain parts of the runtime library, when
> writing characters to certain file descriptors, choose to write a pair
> of characters, 13 and 10, when asked to write the single character 10.

Yes, and that choice is driven by the knowledge that the stream being
written to is attached to a display device.

>
> The C++ Standard does not specify what the escape characters are aside
> from giving a name and a mnemonic for them. Therefore, all it needs to
> do is to say "escape ESC \e", and that the basic execution character
> set shall contain a control character representing escape.

The last part there is a truism. The execution character set is the set
of values that characters are translated into. So requiring compilers to
accept \e as a valid characte adds whatever value \e gets translated to
into the execution character set.

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

--
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 <7sde3s$2gue$1@news.hal-pc.org>, Greg Brewer
<nospam.greg@brewer.net> writes
>Personally, I think that if C++
>is going to continue to be a more-or-less superset of C then it will be
>necessary to create some mechanism to "appreciate" new C standards for the
>C++ standard; i.e, tell vendors that some new C feature will be incorporated
>in the C++ standard "as is" at the earliest opportunity unless some
>extraordinary issue arises.  Since most C++ vendors sell a C compiler too,
>this would give them a head start in complience.

I would strongly resist this concept (C++ as almost a superset of future
C standards).  What we could use would be a mechanism for informing
those concerned that we will consider a specific feature and incorporate
it to the extent possible.  For example C9X's 'restrict' keyword
certainly cannot just be dumped into C++ but we might consider it useful
enough to want to incorporate some refined version with as much
compatibility as possible with its use in C.


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ 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 runtime library for every C compiler for DOS translates \n into two
> > characters on output. Otherwise you end up with subsequent lines
> > overwriting previous ones, because DOS requires both a carriage return
> > and a linefeed to start a new line.
>
> It does this translation for files opened in text mode, because C/C++
> programs want to believe that text file lines are terminated by a single
> '\n' character regardless of what reality is. It happens that stdout,
> stdin, and stderr are open in text mode, and therefore this translation
> is done for them.
>
> On UNIX platforms, the C runtime delivers '\n' uninterpreted, because
> UNIX text files lines are in fact delimited by single LF characters.
> The effects of the control characters upon a display are left up to
> the operating system, without the runtime being involved at all.

I agree with everything in this response except for the last sentence.
The C standard says nothing about "control characters," but it does
define the effect of writing a \n to a display device.

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

Nick Maclaren wrote:
>
> You can, however, reasonably expect that all implementations will do
> SOMETHING sensible with it (such as ignoring it or diagnosing it),
> but the latter is very little different from rejecting it.  In this,
> it does not differ in the slightest from the way that '\e' would be
> specified and treated.
>

None of the various fuzzy proposed definitions of '\e' that I've seen
here has come anywhere near the degree of specificity of the C standards
definition of the effect of, say, '\v'. Putting aside whether it's
actually required or implementable, with '\v' there's a clear goal for
the implementor. With the suggestions that have been made for '\e' there
is no formal guidance as to what it should actually 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 <petebecker@acm.org> wrote in message
news:37EA1728.59FBBB8C@acm.org...
> So how is '\e' different, if it is, from '\033'? Or is all this heat
> only about wanting a two-letter abbreviation for a four-character
> constant?

The short answer -- yes.

Greg Brewer
---
[ 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> wrote in message
news:37EA9611.A09F2D76@acm.org...
> Greg Brewer wrote:
> >
> > Pete Becker <petebecker@acm.org> wrote in message
> > news:37E9A255.D6EFBE3D@acm.org...
> > > case '\a':
> > > beep();
> > > break;
> > Dear compiler vendor:
> >
> > I would like a refund on the compiler I purchased from you.  It has the
> > following defects
> > 1) when I execute the following program
> >    it hangs in an infinite loop.
>
> If this is intended to be a comment on the code snippet that I posted,
> note that I did not give any implementation for put. You must have
> filled that in yourself, and gotten it wrong.

Yep.  Must have gotten beep() wrong too.  If my guess was wrong then the
snippet was useless.

Greg Brewer
---
[ 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 <7seci4$4vn$1@news.hal-pc.org>, "Greg Brewer" <nospam.greg@brewer.net> writes:
|> Paul Jarc <prj@po.cwru.edu> wrote in message
|> news:m34sglqrcb.fsf@multivac.student.cwru.edu...
|> >
|> > As he said, "when writing it to the screen".  stdout and stderr are in
|> > text mode, and you can't get a binary-mode stream writing to the
|> > screen in strictly conforming code.
|>
|> Again, not true.  I know I have seen a function somewhere that will change
|> the mode of a stream.   I don't believe there is anything in the standard
|> that disallows strictly conforming code from changing the mode of any stream
|> including stdout and stderr.  I personally would discourage doing so though.

You mean 'conforming', not 'strictly conforming', I think.  It certainly
is NOT allowed in strictly conforming code, as there is no function to
change the mode of a stream without closing and reopening it.

|> Also, you can open another stream in binary-mode that will write to the
|> screen.

That is REALLY asking for trouble!  Think synchronisation.


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              ]

Greg Brewer wrote:
....
> Again, not true.  I know I have seen a function somewhere that will change
> the mode of a stream.   I don't believe there is anything in the standard
> that disallows strictly conforming code from changing the mode of any stream
> including stdout and stderr.  I personally would discourage doing so though.

Do you know the name of it? I remember seeing a setmode() function, but
it's not a part of the C standard.

> Also, you can open another stream in binary-mode that will write to the
> screen.

Not by any means that is specified by the C standard. There are
operating systems that will allow this, but that's a different issue.
---
[ 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              ]

Greg Brewer wrote:
>
> Pete Becker <petebecker@acm.org> wrote in message
> news:37E99FD7.24638D86@acm.org...
> >
> > "Paul D. DeRocco" wrote:
> > >
> > > Pete Becker wrote:
> > > >
> > > > Please give an example of code using \e, and based on this definition,
> > > > explain what the behavior of the program will be.
> > >
> > >     cout << "\eH";
> > >
> > > This will write an escape and a capital H to the standard output stream.
> I
> >
> > "write an escape and a capital H" doesn't say anything that the code
> > itself doesn't say. Compare it to what the C standard says about \n:
> >
> > \n (new line) Moves the active position to the initial position of the
> > next line.
>
> You are confusing two different things.

No, you are introducing a red herring. The words I quoted from the
standard apply when writing characters to a display device, which is
what cout ordinarily does and what the context of this discussion has
always implied. But if you want to get into the semantics of binary mode
output, remember that the only guarantee that the standard gives you
when you do that is that you can read the data into a program built with
the same compiler.

> "write an escape and a capital H"
> accurately describes what the code in question does.  If the code had been
>    cout << "\nH";
> then "write a new line and a capital H" would have been an accurate
> description.  It would not have been accurate to include "moves the active
> position to the initial position of the next line" because that is not
> necessarily what happens.  If the program that contains that statement is
> executed and the standard output is redirected to a file at that time then
> the only thing that you can say for sure that happens is that the size of
> the file will increase.  To say more will require more information.

And when you have that information, i.e. in the context of the statement
that I made, you can make a stronger statement in the case of \n, but
you cannot make it from the proposed definition of \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              ]

In article <37E9E45B.B257E49@ix.netcom.com>, 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.

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

"Greg Brewer" <nospam.greg@brewer.net> writes:
> Steve Downey <sdowney@panix.com> wrote in message
> news:uu2oluzg0.fsf@sdowney.ny.jpmorgan.com...
> > No, it would produce implementation-defined behavior. The
> > implementation would be required to document what, if anything, \e
> > did. In particular, \e would always have the same interpretation. It
> > could not occasionally start WW3.
>
> What do you mean by implementation?  If you mean that the implementation of
> the C standard would have to document what it does, I would have to
> disagree.

C9X 3.10p1:
# implementation
# a particular set of software, running in a particular translation
# environment under particular control options, that performs
# translation of programs for, and supports execution of functions in,
# a particular execution environment

3.11p1:
# implementation-defined behavior
# unspecified behavior where each implementation documents how the
# choice is made


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:
>
> I don't think it uses ESC in the source.  It certainly doesn't need
> to.  It looks up and prints escape sequences from a database - these
> can have ESC in them, rather than having curses print the ESC
> literally.

But the sequences in the database are allowed to contain the string "\E"
which the library is obliged to map into an ESC character, so it most
certainly *does* need to have some representation of ESC in the source.

-Larry Jones

I'm getting disillusioned with these New Years. -- 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              ]

James Kuyper <kuyper@wizard.net> writes:

> Steve Downey wrote:
> ...
> > No, it would produce implementation-defined behavior. The
> > implementation would be required to document what, if anything, \e
> > did. In particular, \e would always have the same interpretation. It
> > could not occasionally start WW3.
>
> Why not, so long as they document the fact?


Well, I suppose it would be OK if it always started WW3. But for
implementation defined behavior, as I recall, an implementation must
be consistent. I also would be surprised if starting WW3 was one of
the range of choices that the standard provided to the implementation.

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

This communication is for informational purposes only.  It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction, unless specifically agreed
otherwise. All market prices, data and other information are not warranted as
to completeness or accuracy and is subject to change without notice. Any
comments or statements made herein do not necessarily reflect those of
J.P. Morgan & Co. Incorporated, its subsidiaries and affiliates.
---
[ 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              ]

Greg Brewer wrote:
>
> Paul Jarc <prj@po.cwru.edu> wrote in message
> news:m3n1ueiwdn.fsf@multivac.student.cwru.edu...
> > > > > Huh!  So if I write a string containing \t to a file then go to the
> DOS
> > > > > prompt and use type to display that file and it behaves as you just
> > > > > described, I should call Inprise and complain?
> > > > No, the standard can't do anything about what happens when the
> > > > contents of your file, generated from a C program, are presented to a
> > > > display device from outside a C program.  The flaw in Pete's argument
> > > > is somewhere else.
> > > I disagree; that is precisely the flaw in the argument!  He is saying
> that
> > > is I send an output string to a device and it doesn't do what it is
> supposed
> > > to do then that is the compiler's fault.
> >
> > 1. The standard doesn't differentiate (much) between compiler, linker,
> >    library, etc.  There is only "the implementation".  I suspect Pete
> >    meant it's the implementation (vendor)'s fault, and happened to
> >    call the implementation "the compiler", which is not uncommon,
> >    though imprecise.
>
> I wouldn't know about that.  I have been remiss in actually reading the
> standard.  My experience with C suggests the language was originally defined
> in terms of Unix and then updated to remove Unix references.  I would expect
> that it is still oriented around OS's that handle output as streams.  My
> only non-Dos/Windows/Unix experience with C was more than 10 years ago when
> I used ThinkC on a MacIntosh.  The program I was attempting to port didn't
> run too well because the generated program had to attempt to create a
> console environment that the OS didn't support.  I didn't blame the fact
> that I didn't like the look on the vendor because the implementation was
> poor.  It was an OS issue.

That's one way of viewing it, and of course ultimately it's the
combination of compiler, library, and OS that produces the characters on
the display. But the C standard does not standardize OS's, it only
standardizes the C language. It describes the effect of writing valid C
code. So when someone says that their compiler and library for the ABC
OS conforms to the C standard, they mean that the a conforming C program
acts in the way prescribed by the standard. Since they typically don't
control the OS, the place to fix problems is in the compiler and
library.

>
> > 2. Your previous message talked about saving \t to a file from a C
> >    program, and sending that to a display device from outside a C
> >    program.  This is different from sending it directly, and that's
> >    all I was picking on.  (While the handling is typically done at a
> >    lower level, it could be done by stdio directly.)
>
> Maybe, maybe not.  A program that sends a particular string to standard out
> can't make any assumptions on the path it takes to get there.  If a C
> program was compiled to a .exe named foo then executing
>    foo
> should display the string on the console but so should
>   foo | more

No, because in this case foo is not writing characters to a display
device. more is, and the behavior of more is not controlled by the C
standard. The C output code typically calls isatty to determine whether
it's writing to a display device, and adjusts its output accordingly.
Once you pipe its output to some other program, it's that other program
that determines what gets displayed.

--
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 <o_AG3.451$a7.58222@nnrp.gol.com>, David J. Littleboy
<davidjl@gol.com> writes
>The next question that arises is: what should printf do if it gets a \e? My
>original thought was: exactly the same as what it now does if I feed it an
>x1B. However, there's a better answer. Since \e names a code point that exis
>ts in multiple execution character sets, printf's specifications can now be
>written in terms of "ESC in the execution character set". This gives you
>portable behavior, a big improvement over magic constants which may be
>meaningful on some platforms but not others.

In what way is \e different in concept from all the provided escape
sequences?

For each of those provided the consequence of using them is limited
directly to a single character value (even if somewhere - outside the
program - these have to be expanded into several characters or some
other mechanism to achieve the desired result)  We still have a small
problem in dealing with the cases where the value attached to, say, \a
is used for some other reason where it would be an error for that value
to be mapped to the apparently equivalent value in another code-set.

The problem of \e is that it effectively re-interprets one or more
subsequent values to have some other meaning.  How many and what that
meaning maybe is entirely dependant on the ultimate destination of the
code.

For example how am I to dispatch a printer control string that is
intended to set a print position on a page when the vertical position
value just happens to be that used to represent \v in the selected code-
set?  Of course the answer is to resort to binary streams, but in that
circumstance what added value is provided by \e?  It seems to me that if
I want to dispatch a control sequence to a peripheral I just about have
to do so through a stream in binary mode.  As long as we have a mapping
of one escape character to one effect we are OK, but anytime the result
extends (e.g. SI and SO) we have problems and \e is just going to be a
smoke screen.  Extended effects are bad news because the compiler has no
way of understanding where that extended effect is to end (actually SI
and SO are a little bit better than ESC in this context)

My objection to \e is not that it does not appear to be useful, but
exactly because its utility is deceptive.


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ 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:
>
> PS: By the way, the above compile time reasoning has frightening
> implications for "locale" in both C and C++. Since character and string
> literals are translated into the execution character set at _compile time_,
> I suspect there is wording in both the C and C++ standards that cannot be
> met, since (I think) it ends up specifying that certain decisions that have
> to be made at compile time be local-dependent, and the locale has to be
> switchable at run time. Ouch.

I just realized that I left out an important factor in the description
of the term "execution character set" in my other message. The primary
reason for the standard describing two character sets is to avoid
putting limitations on cross-compilers. For example, a compiler can read
source code from files encoded in ASCII, but generate executable code in
which the characters in the quoted strings in the source code have been
translated into EBCDIC.

--
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> wrote in message
news:37EA9679.BBBF579@acm.org...
> > Not true.  It only does the translation when writing to an output stream
> > that is opened in text mode.
> I agree with everything in the preceding paragraph except the first
> sentence. I would replace it with "True." since it simply restates what
> I said previously. (You can't legally send the contents of a binary
> stream to the screen).

Tell me you're kidding.  Where could you possible get that it is illegal to
send a binary stream to the screen?  In a Unix implementation, there really
is no difference between text mode and binary mode.

Greg Brewer


[ 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 <37EA19B4.CB3501AE@acm.org>...
>
> >That's all fine, but so far nobody has been willing to propose anything
> >non-trivial for the intent of \e.
>
> That's because specifying the intent of an escape sequence is meaningless.
>
> I think you (and the giants on whose shoulders we all stand) have conflated
> _compile time_ issues with _run time_ issues. Since escape sequences _must_
> be translated into single char objects with a value from the execution set
> _at compile time_, that translation has to be defined in terms of the
> execution character set;

No, that translation defines the execution character set. It is the set
of values that the compiler translates source characters into. Nothing
more. It's usually a good idea for the execution set to be a subset of
the OS's character set, because that makes many operations easier, but
they are two different notions.

> it makes no sense to talk about the behavior of
> "\a"at run time, since "\a" doesn't exist at run time.

Language standards talk about the effects of constructs in the source
code. It's perfectly reasonable to talk about the runtime effect of
characters in text strings, because that's what programmers are
concerned with. If I write puts("\a") in a program, when that statement
executes there should be an alert. It doesn't matter whether the OS that
I'm running on has a character that does this. The compiler translates
\a into some code in the execution character set which the runtime
library recognizes. If that character, by some deliberate coincidence,
happens to be the character that the OS recognizes as calling for an
alert, then the runtime library doesn't have to do anything special with
it.

>
> PS: By the way, the above compile time reasoning has frightening
> implications for "locale" in both C and C++. Since character and string
> literals are translated into the execution character set at _compile time_,
> I suspect there is wording in both the C and C++ standards that cannot be
> met, since (I think) it ends up specifying that certain decisions that have
> to be made at compile time be local-dependent, and the locale has to be
> switchable at run time. Ouch.

Which is a pretty good indication that it isn't correct. <g> You're
reading far too much into the term "execution character set." Here's
what the C standard says about it:

 Two sets of characters and their associated collating sequences shall
 be defined: the set in which source files are written, and the set
 interpreted in the execution environment. The values of the members
 of the execution character set are implementation-defined; any
additional
 members beyond those required by this section are locale-specific.

The implemetation has to tell you what values are in the execution
character set, and, presumably, which source characters correspond to
those values. Within the C program, however, those values can be
interpreted in ways other than what the OS would do with them, in order
to produce the behavior required by the C 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              ]

Hyman Rosen wrote:
>
> "Paul D. DeRocco" <pderocco@ix.netcom.com> writes:
> > Your description of the sort of translation that the library might make
> > applies to \n, but that's a special case. The standard mechanism for
> > passing text from one program to another (e.g., Unix pipes used to
> > implement text-based filters) _requires_ the ability to move to the start
> > of the next line, and there are at least two common standards for doing
> > this (\n and \r\n). If the inventors of C didn't pick one, and make the
> > library deal with systems that disagree, then virtually every text-based
> > program would need special code to handle the conversion in order to be
> > portable.
>
> It's even less than that. C started on UNIX, where text file line
> terminators were a single character, ASCII LF. It was always the job of
> the tty driver to "cook" LF into CR-LF on output, and CR into LF on
> input.
>
> When other systems with different line terminators came along, they
> were faced with a large body of C code which would not correctly
> process text files. Their solution was to invent a distinction between
> text and binary files, and to have something in the runtime system
> hide the different text line terminators into a single '\n' character.
>

This distinction also applies to multibyte character representations,
which can be translated on the fly into wide chars on input, and back t
multibyte characters on output.

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

Greg Brewer wrote:
>
> Steve Downey <sdowney@panix.com> wrote in message
> news:uu2oluzg0.fsf@sdowney.ny.jpmorgan.com...
> > No, it would produce implementation-defined behavior. The
> > implementation would be required to document what, if anything, \e
> > did. In particular, \e would always have the same interpretation. It
> > could not occasionally start WW3.
>
> What do you mean by implementation?  If you mean that the implementation of
> the C standard would have to document what it does, I would have to
> disagree.  If your saying that the programmer that writes the statement
>    Xmit("Do \eBnot\eN enter");
> is the implementation and must document that the first causes bold text and
> the second ends it when sent to a DG Scoreboard controller then I agree.

In the C standard there are a couple of categories of things that the
standard doesn't fully specify. Implementation-defined means "behavior,
for a correct program construct and correct data, that depends on the
characteristics of the implemetnaiton and that each implementaiton shall
document." One example is the character used to represent \n -- the
standard says that this is implementation defined, so the comiler vendor
must tell you what that value is. Another is "unspecified behavior,"
which means "behavior for a correct program construct and correct data,
for which the standard explictly imposes no requirements." For example,
arguments to a function can be computed in any order. "Undefined
behavior" means "behavior, upon use of a nonportable or erroneous
program construct, of erroneous data, or of indeterminately valued
objects, for which the standard imposes no requirements." One of the
most common examples is the expression i=i++, because there are at least
two sensible ways in which the expression could be interpreted.

>
> The biggest trouble we are having in the discussion is that ESC is a single
> code that -- by its nature -- has no defined behavior.  I think part of it
> has to do with why have such sequences in the first place.  When I was
> learning to program using Pascal back in college, I wanted to formfeed my
> output.  I discovered how to generate the formfeed character and place it in
> my string so that I had the statement
>    write('x');
> where x was the code for formfeed.  When I ran the program, the output was
> all nice and neat and followed up with a form feed making it convenent to
> tear off of the printer.  However, when I printed by program, it didn't look
> so neat because it did a formfeed in the middle of printing out that line of
> text.  Having the ability of using \f would have been much preferable.  In
> C, it is much easier to refer to a character using its hex or oct
> representation and sending that.  However, there certain values that are so
> common that it was easier for everyone to have a short hand.  I suspect that
> the fact that it made it more portable was only secondary.  These short hand
> values were developed in the age of tty devices and tty devices only
> supported a limited number of controls. At that time, ESC was as rare as
> sending SI and SO so no one had any special need for it.  Now, we have a
> plethora of specialty devices in need of fine control and ESC is the usual
> character used to give these devices their special commands.
>

At the time that the ANSI C standard was being written it was quite
common to use ANSI escape sequences to control the display. The ANSI C
committee explicitly decided not to put \e in the list of character
escape sequences. I don't want to misquote what the rationale document
says about this, and I don't have it in front of me, but Greg Comeau
cited it in one of his messages in this thread.

--
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:
> > Kai Henningsen wrote:
> > > petebecker@acm.org (Pete Becker)  wrote on 21.09.99 in <37E6EC0A.40DDF311@acm.org>:
> > > > The C standard talks about intended behavior, which is more than anyone
> > > > has been willing to do with regard to \e.
> > >
> > > Untrue.
> >
> > Sigh. Once again, please state the effect on the display of including
> > the character \e in a character string that is displayed with printf.
>
> Some have suggested making it implementation-defined or unspecified.
> This is a stronger requirement than undefined behavior.  Regardless of
> whether you agree about the current status, it's clear that these
> proposals are stonger than this interpretation of the current wording.
>

Yup. And if that's the definition, what can you use it 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.

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

Natarajan Krishnaswami wrote:
>
> On 23 Sep 99 07:11:59 GMT, Pete Becker <petebecker@acm.org> wrote:
> > The runtime library for every C compiler for DOS translates \n into two
> > characters on output. Otherwise you end up with subsequent lines
> > overwriting previous ones, because DOS requires both a carriage return
> > and a linefeed to start a new line.
>
> You know better than that!  That's only true for text streams, in
> which case you aren't guaranteed anything about what gets written,
> since "the external representations in a text file need not be
> identical to the internal representations, and are outside the scope
> of this International Standard".

The standard also says (sheesh, I get so sick of repeating this):

 \n (new line) Moves the active position to the initial position of the
next line.

That has nothing to do with representation. You're right that I left out
the words "text mode" in my statement, but that should have been
apparent from context.

--
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:
> > If it's entirely up to the implementor to decide how to
> > treat \e then there's no program that you can write that uses \e in a
> > non-trivial way but has predictable behavior.
>
> False. If the compiler targets a system which uses ASCII or EBCDIC,
> everyone would know that \e translated into ESC of the appropriate
> character set, which would then be written unmodified to output
> streams. Even you would know this, because you are a library
> implementor, and your users would force you to code it that way :-)
>

No, true. Read the first phrase of the paragraph you quoted again: "If
it's entirely up to the implementor to decide how to treat \e..." That
was one of the suggestions that was made, and that's what I was replying
to.

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

Greg Brewer wrote:
>
> root <jdennett@acm.org> wrote in message news:37E977A0.CC9FF2F8@acm.org...
> >
> > > #include <iostream>
> > > main()
> > > {
> > >  std::cout << 'a' << '\t' << 'b' << '\n';
> > > }
> > >
> >
>  > Yes, in that code the compiler will have translated the '\t', and call
> > something like
> > std::cout::operator <<(char).  The actual 'char' value which gets passed
> to
> > this depends on the compiler's knowledge of the environment which is
> targetted
> > -- if that environment doesn't support a horizontal tab character then I
> > suppose (and maybe Pete Becker or other library implementors could comment
> > here) that its at this level or below that they might intercept their
> chosen
> > '\t' char and call some code to move the current output position suitably.
> The
>
> The problem with this example is that it would never be proper for any
> library implementor to intercept the call sending any text to the standard
> output.  I would expect the compiler to either generate a direct call to the
> OS's api or a call to a runtime library function that would call one or more
> OS api functions that would send the character code to the standard output.
> One important thing to remember about standard output is that it isn't
> necessarily a display.  In many OS's, standard output can be a file, a
> printer, the standard input of another program, or a named pipe.

And the runtime code has to be able to adjust what it does accordingly,
typically by asking the OS whether the stream that it's writing to is a
display device. If it is, it to does whatever is needed to produce the
right results on the display. If it isn't, it simply writes out the
implementation-defined value that is the external representation of the
character in question. The C standard doesn't require that this value be
the value that some other program expects -- that's outside the scope of
the standard. But implementors understand the problems that using
different values would create, so they usually stick to the conventions
of the OS.

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

Greg Brewer wrote:
>
> Pete Becker <petebecker@acm.org> wrote in message
> news:37E9AAAF.92EC8AE8@acm.org...
> > So what is the intent of \e? What should a sane implementor do with it?
> > Emulate an ANSI drive if one isn't present?
>
> No, a sane implementor should just send it on unmodified!
>

Please don't quote out of context. The text that I replied to, which you
snipped, is this:

> > That is, even though the standard does not make any strict
> > guarantees about '\a', by demanding the sequence to be compiled
> > and giving an _intent_, it makes programs using that far more
> > portable, since every sane implementor will try to follow the
> > intent as much as possible.
> >

If you don't think that the standard should give "an _intent_" then your
dispute is with the writer of those words, not with me.

--
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:
>
> Pete Becker wrote in message <37E99E28.B636DB3F@acm.org>...
> >> I think we are finally getting down to the real basics of the issue here.
> >> The question is "what does it mean to be a character in a character
> string?"
> >> If I read you correctly, essentially what you are saying is that C/C++
> >> should _not_ support code points in execution character sets that are not
> >> related to doing things to displays.
> >
> >No, I'm saying that the C standard (I'm avoiding the C++ standard
> >because I think it's seriously flawed here) does not define the
> >semantics of writing non-printable characters that are also not escape
> >sequence characters to a display device. (Phew, if you can parse that
> >you must be as tired as I am).
>
> That's easy (it even makes sense). You should see some of the stuff I have
> to parse for work<g>.
>
> OK. So, what you are saying is that C/C++ should _not_ provide (specify)
> abbreviations (escape sequences) for code points that cannot be defined in
> terms of display devices. I disagree.

No, what I said is that the C standard does not do that. The underlying
principle, however, comes close to your statement -- language standards
are defined in terms of their effects on physical systems. They put
visible characters on the display device, they put data in files, they
modify values in non-volatile memory.

>
> My reading of section 5.2.1 (C90) indicates that the intention of escape
> sequences is to represent charcters in the execution set that cannot be
> represented as printing characters in the source set. Now that, quite
> rightly IMHO, says _nothing_ about what characters in the execution set may,
> can, or should be available as escape sequences.
>
> First of all, here's a first shot at wording for definition of \e, \i, and
> \o:
>
> \e: Expresses the character ESC in the execution set if a unique character
> with that name exists, or the character with an equivalent definition to
> that of ESC in the Unicode standard if such a character is present and
> unique. Otherwise undefined.

The problem here is that this reads a great deal more into "execution
set" than is in the standard. The exeuction character set is simply the
set of values that characters in the source character set are translated
into. In the C standard, the meaning of those values is given only by
the descriptions of the effects of writing those characters to a display
device. There is no assertion that if you're using some externally
defined character set to represent printable characters then all
possible character values must be defined in terms of that character
set. That is, the standard does not import character set definitions. In
particular, the standard says "the values of the members of the
execution character set are implementation-defined."

Now, that doesn't mean that it's not possible to get where you're trying
to go, but the "execution character set" won't get you there, because it
simply reflects what the implementation does, nothing more.

>
> <Similarly for \i, \o.>
>
> Since these go in section 5.2.1, not section 5.2.2, they have no bearing on
> character display semantics.
>
> To appease the language lawyers, add "The following" as the first two words
> in the second paragraph of 5.2.1 so that it reads:
>
> "The following alphabetic escape sequences representing nongraphic
> characters in the execution set are intended to produce actions on display
> devices as follows:"
>
> Now are you happy? You have your well-defined (well, actually hopelessly
> broken, but that's your problem) display semantics, and the rest of us have
> an easy way of writing perfectly well-defined sequences without magic
> constants, and portably between ASCII, EBCIDIC, and Unicode, and maybe
> others.
>
> >> In other words, if a character set standard that's used widely defines a
> >> name for a particular code point that is unambiguous, and that named code
> >> point is used, then it may be useful for C/C++ to support an escape
> sequence
> >> for that named code point. (For all the good reasons that names are
> better
> >> than magic constants.) Which such code points are worth supporting is, of
> >> course, open for argument.
> >
> >It's not clear to me what's meant here by "support." If your compiler
> >vendor tells you that using \i in a character string that you send to an
> >output device will result in the ASCII character SI being sent to the
> >device, that's fine. Use it. It's up to your vendor to live up to their
> >promise. The issue for the standard, though, is whether that something
> >along that line should be required of every vendor, and, if so, how to
> >describe it.
>
> Support means support under section 5.2.1 of ANSI C90. These codes are
> completely unrelated to display semantics as described in section 5.2.2.

That's fine, but it's completely foreign to the approach that the C
standard currently takes. The C standard makes the values of characters
entirely implementation defined.

>
> >> Fortunately, the C++ standard eschews all mention of what happens to
> >> characters once they leave your program, and this is only a glitch in the
> >> wording of the C standard.
>
> >Ah, there we have it: no portable semantics for writing to any display
> >device. That page describing what happens when you write to a display
> >device was just an accident, and the folks who let it slip through into
> >the standard are hanging their heads in shame. Unfortunately, the view
> >among those folks is just the opposite: they express regret that it
> >wasn't possible to put stronger behavioral requirements here, but they
> >couldn't figure out how to say it without overly constraining
> >implementations.
>
> I don't want to write SI to a display device, I want to write it to an
> ISO-2022 interpreting library. Or whatever. It's legal well-defined
> ASCII/EBCDIC/Unicode.
>

But your statement was about what happens to characters, not what
happens to SI and its buddies. And one very common operation on
characters is to write them to a display device.

--
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:
....
> True. But the compiler doesn't know, when it sees \a in a quoted string,
> whether it will wind up in a display device or a file. It must simply turn
> it into a standardized byte value within the string.

Agreed. And when C implementor's standard library functions display that
string, they should implement the intended behavior when they run into
that byte value, if possible. That's non-trivial coding on some
platforms.

> > > If the execution character set is ASCII, then \e must produce the
> > > ASCII escape character.  If it is EBCDIC, then \e must produce the
> > > EBCDIC escape character.
> >
> > The standard would almost certainly not require that.  But it would
> > depend on the wording for \e, which so far has been fluid.  If \e were
> > treated like the other \ characters, there would certainly be no
> > requirement.
>
> Why wouldn't it require that? The point of having backslash escapes in
> C/C++ strings is to define a portable way of including certain standard
> control characters in strings, without resorting to nonportable hex or
> octal escapes.

No, that's true of C++, which defines them in Table 5 in terms of
standard character names, but not of C, which defines them in terms of
their behavior when displayed.


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

Greg Brewer wrote:
>
> Also, you can open another stream in binary-mode that will write to the
> screen.
>

And if you do that the effects are not defined by the standard. See my
other message.

--
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:
>
> Al Stevens wrote:
> >
> > Pete Becker wrote in message <37E7FD5A.EE264133@acm.org>...
> > >
> > >Al Stevens wrote:
> > >> The appropriate place to be sending /e to a
> > >> printer is from a program at some level in the hierarchy--not necessarily
> > >> the application and not necessarily the device driver--that knows
> > >> specifically which printer it is dealing with and, presumably, which
> > >> character set. This is not a language issue.
> > >>
> > >
> > >Fine: you've defined away the question. Since you never need to send \e,
> > >you don't need a way of representing it.
> >
> > If you are addressing me only as an applications programmer, that is
> > correct. But might I have another hat to wear?
>
> No, as everyone keeps telling me, the runtime library doesn't have to do
> anything here except pass the codes on to the operating system. <g>

And of course, no one does write operating systems in C ;-)

Ah, I see, the OS just passes the characters to the device driver.
And the device driver is written in...


[ 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 <t74sgl35ra.fsf@calumny.jyacc.com> Hyman Rosen <hymie@prolifics.com> writes:
>The effects of the control characters upon a display are left up to
>the operating system, without the runtime being involved at all.

There is no such requirement, just QoI.

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
     Producers of Comeau C/C++ 4.2.38 -- NOTE 4.2.42 BETAS NOW AVAILABLE
    Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.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 <37EA95B4.7D97A8A7@acm.org> Pete Becker <petebecker@acm.org> writes:
>Greg Comeau wrote:
>>
>> 4) The crux??: "To avoid the issue of whether an implementation conforms
>>    if it cannot properly effect vertical tabs (for instance), the
>>    Standard emphasizes that the semantics merely describe intent."
>>    Why isn't this just undefined behavior, and be done with it?
>
>Because the authors of the standard wanted to make a stronger statement
>than leaving the behavior undefined.

Clearly, but it becomes double-talk'ish.  Ok, it's not undefined.
But it's only defined(yuck) as an intent, not a requirment.
What the heck does that mean Standard-wise and confomring-wise.
Can you detail the implications?

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
     Producers of Comeau C/C++ 4.2.38 -- NOTE 4.2.42 BETAS NOW AVAILABLE
    Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.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 <7se85k$1bn$1@pegasus.csx.cam.ac.uk> nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
>In article <7se3a5$4fn$1@panix3.panix.com>,
>Greg Comeau <comeau@comeaucomputing.com> wrote:
>>
>>In article <7sdq76$l11$1@pegasus.csx.cam.ac.uk> nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
>>
>>>The second is that it is not
>>>always possible to fulfil that intent (which is why it is an intent
>>>and not a requirement.)
>>
>>This does not seem in dispute.  But failure to accomplish
>>the intent does not make the portable effect of the sequence wrong
>>(one can intepret to above that you are saying it does, at least I did).
>
>I have absolutely no idea what the committee intended in a case where
>it cannot be translated into anything sensible, and I don't think that
>they did, either.

I'm certain this was all well thought through and quite intentional,
even consciously coy.  I'd be quite shocked to find that it wasn't.

>I know what I did, what several of the other relevant
>implementations did, and can think of many other plausible approaches.

I can too.

>It cannot be used to produce a consistent effect under all conforming
>implementations, which is the normal meaning of "portable".

Something like that.

>You can, however, reasonably expect that all implementations will do
>SOMETHING sensible with it (such as ignoring it or diagnosing it),
>but the latter is very little different from rejecting it.  In this,
>it does not differ in the slightest from the way that '\e' would be
>specified and treated.

I don't know, as I've see a few definition for \e.

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
     Producers of Comeau C/C++ 4.2.38 -- NOTE 4.2.42 BETAS NOW AVAILABLE
    Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.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:
...
> In what way is \e different in concept from all the provided escape
> sequences?
>
> For each of those provided the consequence of using them is limited
> directly to a single character value (even if somewhere - outside the
> program - these have to be expanded into several characters or some

That expansion must be done by the standard library on some platforms,
and in my experience the relevant standard library module usually become
part of your program when you link if (or when you load it, if it's a
shared object library).


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

"Greg Brewer" <nospam.greg@brewer.net> writes:

> Steve Downey <sdowney@panix.com> wrote in message
> news:uu2oluzg0.fsf@sdowney.ny.jpmorgan.com...
> > No, it would produce implementation-defined behavior. The
> > implementation would be required to document what, if anything, \e
> > did. In particular, \e would always have the same interpretation. It
> > could not occasionally start WW3.
>
> What do you mean by implementation?  If you mean that the implementation of
> the C standard would have to document what it does, I would have to
> disagree.  If your saying that the programmer that writes the statement
>    Xmit("Do \eBnot\eN enter");
> is the implementation and must document that the first causes bold text and
> the second ends it when sent to a DG Scoreboard controller then I agree.
>


I don't think that defining escape _sequences_ would be
appropriate. What would be is to define what code point in the
character set the implementation translates \e to. The intent would be
to translate \e to the character set defined escape code. The result
of printing \e would depend on the device. It would be legit for
freestanding implementations, the same kind that output spaces for \t,
to say that \e has no effect.


[...]

--
        Steve Downey

This communication is for informational purposes only.  It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction, unless specifically agreed
otherwise. All market prices, data and other information are not warranted as
to completeness or accuracy and are subject to change without notice. Any
comments or statements made herein do not necessarily reflect those of
J.P. Morgan & Co. Incorporated, its subsidiaries and affiliates.



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

Greg Comeau wrote:
>
> In article <37EA95B4.7D97A8A7@acm.org> Pete Becker <petebecker@acm.org> writes:
> >Greg Comeau wrote:
> >>
> >> 4) The crux??: "To avoid the issue of whether an implementation conforms
> >>    if it cannot properly effect vertical tabs (for instance), the
> >>    Standard emphasizes that the semantics merely describe intent."
> >>    Why isn't this just undefined behavior, and be done with it?
> >
> >Because the authors of the standard wanted to make a stronger statement
> >than leaving the behavior undefined.
>
> Clearly, but it becomes double-talk'ish.  Ok, it's not undefined.
> But it's only defined(yuck) as an intent, not a requirment.
> What the heck does that mean Standard-wise and confomring-wise.
> Can you detail the implications?
>

Sure: it's required unless it can't be done reasonably.

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

> Greg Brewer wrote:
> >
> > Pete Becker <petebecker@acm.org> wrote in message
> > news:37E76A3E.42B95BC@acm.org...
> > > "Paul D. DeRocco" wrote:
> > > > characters, so defining \e as the character set's ESC character doesn't
> > > > cause any problems with portability.
> > > But it does: your printer that looks for ASCII ESC characters won't
> > > respond the same way to EBCDIC escape characters. It wants a particular
> > > value, not whatever value happens to be named ESC.
> >
> > You are wrong.  A printer looking for ASCII escape characters will react
> > properly to a valid EBCDIC string containing an EBCDIC escape character.  It
> > will react properly because it will receive ASCII characters including an
> > ASCII escape character.   Just as it will react properly when an EBCDIC 'A'
> > is sent to the printer; it will receive an ASCII 'A'.
> >
>
> Does the printer read the tag bits on each character to determine
> whether the value that it sees should be interpreted as ASCII or EBCDIC,
> or does it look at its color?
>
> Seriously, you seem to be talking about some sort of driver that
> translates EBCDIC to ASCII. That makes it work, of course, but it
> doesn't change what the printer sees. If you're sending the wrong
> characters to the printer you have to do something to fix them or it
> won't work.
>


If that driver isn't there, then whatever you send to the printer
won't work. In a EBCDIC hosted compiler 'A' isn't 65. If you don't
send 65 to an ASCII printer, it won't print an A. OTOH, if you try
to embed the translation in the library, the EBCDIC chain printers
stop working.

An implementation has a single target character set.

 int c1 = 'A';
 ofstream("test") << c1;
 int c2;
 ifstream("test") >> c2;
 assert(c1 == c2);

If that doesn't work, something is very broken, right?

--
        Steve Downey

This communication is for informational purposes only.  It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction, unless specifically agreed
otherwise. All market prices, data and other information are not warranted as
to completeness or accuracy and are subject to change without notice. Any
comments or statements made herein do not necessarily reflect those of
J.P. Morgan & Co. Incorporated, its subsidiaries and affiliates.



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

On 24 Sep 99 07:21:24 GMT, David J. Littleboy <davidjl@gol.com> wrote:
> One of the reasons I've been chipping in here is that ISO-2022-JP uses a
> 7-bit encoding to represent a large character set by using SI and SO to
> shift state. Which means that some people who deal with that standard might
> like an easier way to represent those values.

Many (I want to say all) EBCDIC-based multibyte coded charsets also
use stateful representation with SI (0xF) and SO (0xE) rather than
single/leading/trailing ranges.


<N/>
--
I feel so semantic today...
 -- Eric A. Meyer


[ 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 <o_AG3.451$a7.58222@nnrp.gol.com>, David J. Littleboy
<davidjl@gol.com> writes
>PS: By the way, the above compile time reasoning has frightening
>implications for "locale" in both C and C++. Since character and string
>literals are translated into the execution character set at _compile time_,
>I suspect there is wording in both the C and C++ standards that cannot be
>met, since (I think) it ends up specifying that certain decisions that have
>to be made at compile time be local-dependent, and the locale has to be
>switchable at run time. Ouch.

No. Though the locale can be switchable, the character codes that are
generated at compile time by (say) "%d" must be precisely the ones that
fprintf will understand as a conversion specifier for an integer. Even
if the current locale uses an EBCDIC encoding while the compiler used an
ASCII one.

Put another way, fprintf is not allowed to change the output it produces
based on the current locale except where stated. The code:

    printf ("%d", 123);

and the code

    putchar ('0' + 1);
    putchar ('0' + 2);
    putchar ('0' + 3);

must always produce the same output, no matter what locale is in effect
at any point.

--
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 <37EBE42A.34C972A1@acm.org> Pete Becker <petebecker@acm.org> writes:
>
>Greg Comeau wrote:
>>
>> In article <37EA95B4.7D97A8A7@acm.org> Pete Becker <petebecker@acm.org> writes:
>> >Greg Comeau wrote:
>> >>
>> >> 4) The crux??: "To avoid the issue of whether an implementation conforms
>> >>    if it cannot properly effect vertical tabs (for instance), the
>> >>    Standard emphasizes that the semantics merely describe intent."
>> >>    Why isn't this just undefined behavior, and be done with it?
>> >
>> >Because the authors of the standard wanted to make a stronger statement
>> >than leaving the behavior undefined.
>>
>> Clearly, but it becomes double-talk'ish.  Ok, it's not undefined.
>> But it's only defined(yuck) as an intent, not a requirment.
>> What the heck does that mean Standard-wise and confomring-wise.
>> Can you detail the implications?
>
>Sure: it's required unless it can't be done reasonably.

How do you feel this case, an intent, differs from unspecified behavior?
How do you feel this case, an intent, differs from undefined behavior?
How do you feel this case, an intent, differs from implementation-defined
behavior?

I'm trying to find out what "stronger" means.

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
     Producers of Comeau C/C++ 4.2.38 -- NOTE 4.2.42 BETAS NOW AVAILABLE
    Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.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:
> So what will you do with it if you have it that you can't do now?

Embed it in strings to write device control escape sequences.


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

Jan Echternach wrote:
>
> In article <37E6EC0A.40DDF311@acm.org>,
>         Pete Becker <petebecker@acm.org> writes:
> > And what is the "intended behavior" of \e?
>
> Unspecified behaviour.

So what will you do with it if you have it that you can't do now?

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

root <jdennett@acm.org> wrote in message news:37E977A0.CC9FF2F8@acm.org...
>
> > #include <iostream>
> > main()
> > {
> >  std::cout << 'a' << '\t' << 'b' << '\n';
> > }
> >
>
 > Yes, in that code the compiler will have translated the '\t', and call
> something like
> std::cout::operator <<(char).  The actual 'char' value which gets passed
to
> this depends on the compiler's knowledge of the environment which is
targetted
> -- if that environment doesn't support a horizontal tab character then I
> suppose (and maybe Pete Becker or other library implementors could comment
> here) that its at this level or below that they might intercept their
chosen
> '\t' char and call some code to move the current output position suitably.
The

The problem with this example is that it would never be proper for any
library implementor to intercept the call sending any text to the standard
output.  I would expect the compiler to either generate a direct call to the
OS's api or a call to a runtime library function that would call one or more
OS api functions that would send the character code to the standard output.
One important thing to remember about standard output is that it isn't
necessarily a display.  In many OS's, standard output can be a file, a
printer, the standard input of another program, or a named pipe.

I would not want a library implementer to change the output stream destined
for another program's input stream to change the tab to a series of spaces.
I once faced a similar situation where the stream was directed to a
destination that was not supported by the application.  In order to get the
stream to work, I had to use a hook to reformat text formatted for a
supported printer.  Then I ran out of gas.  The supported printer didn't
support a tab so all the tabs where converted to spaces.  It's rather
difficult to unconvert them.

On the other hand, if you are sending stuff to standard output, it may be
necessary.  For my applications, I have defined an object called Printer
that acts as an interface to a printer.  Therefore, I would have the code
     Printer printer;
     printer << 'a' << '\t' << 'b' << '\n';
and it will then process the characters 'a', tab, 'b' and newline.  At this
time, I don't support sending tab characters to my printer object in the way
I should.  I have some plans along those lines but I have not had the time.
This does demonstrate a good point though.  In the processing for my object,
I would just send the tab on to the Windows printer manager and let it worry
about it.  I say "would" since everyone using my printer object has been
instructed not to use that character and an alternate means of tabbing is
provided.  I do provide special processing for the new line character since
I have to change the column and line number for subsequent output.  Now, if
this \e character were implemented, it would be treated no different than a
\t is handled.  BTW, if this text lacks continuity in some points, I
apologize.  I have been interupted thrice since I started.
>
> So; the compiler maps '\t' to a value of type char, which the runtime
library
> is responsible for mapping to the action of a horizontal tab.  Granted, in
nice
> clean systems, passing the character through to the host OS unchanged --
but
> not for all.  And "most" systems (in some sense) require the library to
get in
> the way of '\n' because there's no single byte which can be written to
their
> console to have the desired effect.

Still, the operation should be handled at the lowest level possible.  The
compiler vendor should have supplied an output routine that should handle
the translation.  If a library routine is interacting with a specific device
then it would be proper to process the special sequences.

> Without trying to start a vote, I'd think that this is a reasonable thing
to
> add to a future C++ standard (though I can't see that I'd ever have a use
for
> it in my line of work).
> 1.  It would make one less incompatibility between C and C++.   ("As close
as
> possible...").
> 2.  It would make some (probably non-portable) code more readable.
> 3.  It has clearly-defined semantics.
> 4.  It would not break any existing code.

This would not decrease incompability between C and C++; neither standard
defines \e.  Adding it will create a short-term incompatibility since both
standards can't be updated simultaneously.  Personally, I think that if C++
is going to continue to be a more-or-less superset of C then it will be
necessary to create some mechanism to "appreciate" new C standards for the
C++ standard; i.e, tell vendors that some new C feature will be incorporated
in the C++ standard "as is" at the earliest opportunity unless some
extraordinary issue arises.  Since most C++ vendors sell a C compiler too,
this would give them a head start in complience.

In fact, there is an argument that this would make code more portable since
the ESC character is different in ASCII and EBCDIC.

Greg Brewer
---
[ 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              ]

Christopher Eltschka wrote:
>
> Pete Becker wrote:
> >
> > Christopher Eltschka wrote:
> > >
> > > Pete Becker wrote:
> > >
> > > [...]
> > >
> > > > Once again, condensed from the C standard:
> > > >
> > > >     \a (alert) Produces an audible or visible alert.
> > > >     \b (backspace) Moves the actrive position to the previous position on
> > > >         the current line.
> > >
> > > [...]
> > >
> > >       \e (escape) allow a different interpretation of following
> > >           characters.
> >
> > Please give an example of code using \e, and based on this definition,
> > explain what the behavior of the program will be.
>
> // program 1:
>
> int main()
> {
>   std::cout << "x\a";
> }
>
> // program 2
>
> int main()
> {
>   std::cout << "x\e\a";
> }
>
> Program 1 will output "x" and generate an alert. (Assume on
> the given implementation, it does).
> Program 2 will output "x", but is allowed (not required)
> to interpret the \a differently (f.ex. print the character
> which is displayed if you write the code of '\a' directly
> to text mode video memory).
>
> 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'? Or is all this heat
only about wanting a two-letter abbreviation for a four-character
constant?

--
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:
> > Paul Jarc wrote:
> > > Pete Becker <petebecker@acm.org> writes:
> > > >       2. "You idiot, of course newline means start a new line."
> > > >
> > > > Now, I suspect that most folks would lean strongly toward 2.
> > >
> > > Yes, but not on the grounds of conformance to the standard.  It's QoI.
> >
> > No, on the grounds of conformance, unless you are willing to ignore the
> > half page of text that describes what the effect of an escape sequence
> > is supposed to be. You have to look at the entire standard, not just the
> > parts that support your position.
>
> I should say the same to you.  All the text that supports your
> position is subordinate to "are intended to", not "shall".  Do you
> deny this?

Of course not. I don't read that to mean that the words that follow are
just spares, however. If the intention of the people who wrote the
standard had been to make the effects of these characters undefined they
wouldn't have said what those effects are supposed to be.

> If not, how do you maintain that that text is normative?

In a standards document, all text that is not in notes, comments,
examples, or footnotes is normative.

--
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 <37E99994.3BD88DDC@acm.org>, 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.



Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ 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 in message
news:m3n1ueiwdn.fsf@multivac.student.cwru.edu...
> > > > Huh!  So if I write a string containing \t to a file then go to the
DOS
> > > > prompt and use type to display that file and it behaves as you just
> > > > described, I should call Inprise and complain?
> > > No, the standard can't do anything about what happens when the
> > > contents of your file, generated from a C program, are presented to a
> > > display device from outside a C program.  The flaw in Pete's argument
> > > is somewhere else.
> > I disagree; that is precisely the flaw in the argument!  He is saying
that
> > is I send an output string to a device and it doesn't do what it is
supposed
> > to do then that is the compiler's fault.
>
> 1. The standard doesn't differentiate (much) between compiler, linker,
>    library, etc.  There is only "the implementation".  I suspect Pete
>    meant it's the implementation (vendor)'s fault, and happened to
>    call the implementation "the compiler", which is not uncommon,
>    though imprecise.

I wouldn't know about that.  I have been remiss in actually reading the
standard.  My experience with C suggests the language was originally defined
in terms of Unix and then updated to remove Unix references.  I would expect
that it is still oriented around OS's that handle output as streams.  My
only non-Dos/Windows/Unix experience with C was more than 10 years ago when
I used ThinkC on a MacIntosh.  The program I was attempting to port didn't
run too well because the generated program had to attempt to create a
console environment that the OS didn't support.  I didn't blame the fact
that I didn't like the look on the vendor because the implementation was
poor.  It was an OS issue.

> 2. Your previous message talked about saving \t to a file from a C
>    program, and sending that to a display device from outside a C
>    program.  This is different from sending it directly, and that's
>    all I was picking on.  (While the handling is typically done at a
>    lower level, it could be done by stdio directly.)

Maybe, maybe not.  A program that sends a particular string to standard out
can't make any assumptions on the path it takes to get there.  If a C
program was compiled to a .exe named foo then executing
   foo
should display the string on the console but so should
  foo | more
; however, in DOS, the output string is actually written to a file before it
gets to the display.

Greg Brewer
---
[ 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> wrote in message
news:37E9AAAF.92EC8AE8@acm.org...
> So what is the intent of \e? What should a sane implementor do with it?
> Emulate an ANSI drive if one isn't present?

No, a sane implementor should just send it on unmodified!

Greg Brewer
---
[ 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              ]

On 23 Sep 99 07:11:59 GMT, Pete Becker <petebecker@acm.org> wrote:
> The runtime library for every C compiler for DOS translates \n into two
> characters on output. Otherwise you end up with subsequent lines
> overwriting previous ones, because DOS requires both a carriage return
> and a linefeed to start a new line.

You know better than that!  That's only true for text streams, in
which case you aren't guaranteed anything about what gets written,
since "the external representations in a text file need not be
identical to the internal representations, and are outside the scope
of this International Standard".

Try doing an
  if(freopen(0,"wb",stdout))
      printf("hello\nworld!\n");
and see what your implementation (under DOS) does.


<N/>
--
I feel so semantic today...
 -- Eric A. Meyer
---
[ 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:
>
> root wrote:
> >
> > Yes, in that code the compiler will have translated the '\t', and call
> > something like std::cout::operator <<(char).  The actual 'char' value
> > which gets passed to this depends on the compiler's knowledge of the
> > environment which is targetted -- if that environment doesn't support a
> > horizontal tab character then I suppose (and maybe Pete Becker or other
> > library implementors could comment here) that its at this level or below
> > that they might intercept their chosen '\t' char and call some code to
> > move the current output position suitably.
>
> I disagree. The compiler should only translate backslash lower case t into
> the execution character set's tab character. It shouldn't care anything
> more specific about the environment than what its execution character set
> is (i.e., ASCII or EBCDIC), because it (the compiler) cannot know what
> ultimate process or device will be consuming the character. It isn't up to
> the compiler, or even the standard library, to do any translation on it.
>
> Your description of the sort of translation that the library might make
> applies to \n, but that's a special case. The standard mechanism for
> passing text from one program to another (e.g., Unix pipes used to
> implement text-based filters) _requires_ the ability to move to the start
> of the next line, and there are at least two common standards for doing
> this (\n and \r\n). If the inventors of C didn't pick one, and make the
> library deal with systems that disagree, then virtually every text-based
> program would need special code to handle the conversion in order to be
> portable.

Where in the standard does it say that \n is a special case?

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

No you don't. On DOS, the compiler translates '\n' into a single ASCII
character whose value is 10. Certain parts of the runtime library, when
writing characters to certain file descriptors, choose to write a pair
of characters, 13 and 10, when asked to write the single character 10.

Furthermore, this has nothing to do with the behavior of display devices.
Instead, this has to do with allowing C and C++ programs to believe the
convenient fiction that text files contain "lines" which are terminated
by a single character.

The C++ Standard does not specify what the escape characters are aside
from giving a name and a mnemonic for them. Therefore, all it needs to
do is to say "escape ESC \e", and that the basic execution character
set shall contain a control character representing escape.

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.
---
[ 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> wrote in message
news:37E99FD7.24638D86@acm.org...
>
> "Paul D. DeRocco" wrote:
> >
> > Pete Becker wrote:
> > >
> > > Please give an example of code using \e, and based on this definition,
> > > explain what the behavior of the program will be.
> >
> >     cout << "\eH";
> >
> > This will write an escape and a capital H to the standard output stream.
I
>
> "write an escape and a capital H" doesn't say anything that the code
> itself doesn't say. Compare it to what the C standard says about \n:
>
> \n (new line) Moves the active position to the initial position of the
> next line.

You are confusing two different things.  "write an escape and a capital H"
accurately describes what the code in question does.  If the code had been
   cout << "\nH";
then "write a new line and a capital H" would have been an accurate
description.  It would not have been accurate to include "moves the active
position to the initial position of the next line" because that is not
necessarily what happens.  If the program that contains that statement is
executed and the standard output is redirected to a file at that time then
the only thing that you can say for sure that happens is that the size of
the file will increase.  To say more will require more information.

Greg Brewer
---
[ 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 runtime library for every C compiler for DOS translates \n into two
> characters on output. Otherwise you end up with subsequent lines
> overwriting previous ones, because DOS requires both a carriage return
> and a linefeed to start a new line.

It does this translation for files opened in text mode, because C/C++
programs want to believe that text file lines are terminated by a single
'\n' character regardless of what reality is. It happens that stdout,
stdin, and stderr are open in text mode, and therefore this translation
is done for them.

On UNIX platforms, the C runtime delivers '\n' uninterpreted, because
UNIX text files lines are in fact delimited by single LF characters.
The effects of the control characters upon a display are left up to
the operating system, without the runtime being involved at all.
---
[ 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:
> > Right. I'm not sure at this point if you're agreeing with me or
> > disagreeing. Yes, every escape character sequence is compiled to a
> > value. The code that writes such values to an output device is
> > responsible for making sure that those values have the appropriate
> > effect. If sending the value to the device will do it, fine. If not,
> > then do something else.
>
> This is false. The runtime sometimes writes out 13 and 10 when asked
> to write a 10, but this is because it is matching the C/C++ fiction
> that text files contain lines terminated by a single character to the
> external reality of text files which contain lines terminated by a
> pair of characters.

I agree with everything in the paragraph above except the first
sentence. I would replace it with "This is true."

>
> > So what is the intent of \e? What should a sane implementor do with it?
> > Emulate an ANSI drive if one isn't present?
>
> No, assign a character value to it and deliver that value just as it
> does for \a, \v, \r, and \t. Only \n is handled differently, and that
> is only for files opened in text mode.
>

Where in the standard does it say that only \n is handled differently?

--
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:
> Kai Henningsen wrote:
> > petebecker@acm.org (Pete Becker)  wrote on 21.09.99 in <37E6EC0A.40DDF311@acm.org>:
> > > The C standard talks about intended behavior, which is more than anyone
> > > has been willing to do with regard to \e.
> >
> > Untrue.
>
> Sigh. Once again, please state the effect on the display of including
> the character \e in a character string that is displayed with printf.

Some have suggested making it implementation-defined or unspecified.
This is a stronger requirement than undefined behavior.  Regardless of
whether you agree about the current status, it's clear that these
proposals are stonger than this interpretation of the current wording.


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 in message <37E99E28.B636DB3F@acm.org>...
>> I think we are finally getting down to the real basics of the issue here.
>> The question is "what does it mean to be a character in a character
string?"
>> If I read you correctly, essentially what you are saying is that C/C++
>> should _not_ support code points in execution character sets that are not
>> related to doing things to displays.
>
>No, I'm saying that the C standard (I'm avoiding the C++ standard
>because I think it's seriously flawed here) does not define the
>semantics of writing non-printable characters that are also not escape
>sequence characters to a display device. (Phew, if you can parse that
>you must be as tired as I am).

That's easy (it even makes sense). You should see some of the stuff I have
to parse for work<g>.

OK. So, what you are saying is that C/C++ should _not_ provide (specify)
abbreviations (escape sequences) for code points that cannot be defined in
terms of display devices. I disagree.

My reading of section 5.2.1 (C90) indicates that the intention of escape
sequences is to represent charcters in the execution set that cannot be
represented as printing characters in the source set. Now that, quite
rightly IMHO, says _nothing_ about what characters in the execution set may,
can, or should be available as escape sequences.

First of all, here's a first shot at wording for definition of \e, \i, and
\o:

\e: Expresses the character ESC in the execution set if a unique character
with that name exists, or the character with an equivalent definition to
that of ESC in the Unicode standard if such a character is present and
unique. Otherwise undefined.

<Similarly for \i, \o.>

Since these go in section 5.2.1, not section 5.2.2, they have no bearing on
character display semantics.

To appease the language lawyers, add "The following" as the first two words
in the second paragraph of 5.2.1 so that it reads:

"The following alphabetic escape sequences representing nongraphic
characters in the execution set are intended to produce actions on display
devices as follows:"

Now are you happy? You have your well-defined (well, actually hopelessly
broken, but that's your problem) display semantics, and the rest of us have
an easy way of writing perfectly well-defined sequences without magic
constants, and portably between ASCII, EBCIDIC, and Unicode, and maybe
others.

>> In other words, if a character set standard that's used widely defines a
>> name for a particular code point that is unambiguous, and that named code
>> point is used, then it may be useful for C/C++ to support an escape
sequence
>> for that named code point. (For all the good reasons that names are
better
>> than magic constants.) Which such code points are worth supporting is, of
>> course, open for argument.
>
>It's not clear to me what's meant here by "support." If your compiler
>vendor tells you that using \i in a character string that you send to an
>output device will result in the ASCII character SI being sent to the
>device, that's fine. Use it. It's up to your vendor to live up to their
>promise. The issue for the standard, though, is whether that something
>along that line should be required of every vendor, and, if so, how to
>describe it.

Support means support under section 5.2.1 of ANSI C90. These codes are
completely unrelated to display semantics as described in section 5.2.2.

>> Fortunately, the C++ standard eschews all mention of what happens to
>> characters once they leave your program, and this is only a glitch in the
>> wording of the C standard.

>Ah, there we have it: no portable semantics for writing to any display
>device. That page describing what happens when you write to a display
>device was just an accident, and the folks who let it slip through into
>the standard are hanging their heads in shame. Unfortunately, the view
>among those folks is just the opposite: they express regret that it
>wasn't possible to put stronger behavioral requirements here, but they
>couldn't figure out how to say it without overly constraining
>implementations.

I don't want to write SI to a display device, I want to write it to an
ISO-2022 interpreting library. Or whatever. It's legal well-defined
ASCII/EBCDIC/Unicode.

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              ]

In article <t7d7v9369d.fsf@calumny.jyacc.com> Hyman Rosen <hymie@prolifics.com> writes:
>Pete Becker <petebecker@acm.org> writes:
>> Right. I'm not sure at this point if you're agreeing with me or
>> disagreeing. Yes, every escape character sequence is compiled to a
>> value. The code that writes such values to an output device is
>> responsible for making sure that those values have the appropriate
>> effect. If sending the value to the device will do it, fine. If not,
>> then do something else.
>
>This is false. The runtime sometimes writes out 13 and 10 when asked
>to write a 10, but this is because it is matching the C/C++ fiction
>that text files contain lines terminated by a single character to the
>external reality of text files which contain lines terminated by a
>pair of characters.

The last paragraph of "2.2.2 Character display semantics" disagrees with you:
"The external representation in a text file need not be idential to the
internal representations, and are outside the scope of this Standard."
It's not talking about 10 here, but of all the escape sequences.

>> So what is the intent of \e? What should a sane implementor do with it?
>> Emulate an ANSI drive if one isn't present?
>
>No, assign a character value to it and deliver that value just as it
>does for \a, \v, \r, and \t. Only \n is handled differently, and that
>is only for files opened in text mode.

All of this is for files in text mode.

Anyway, this discussion it too circular.  Can you really say for
certainty what the code for \t does in every single case?  I cannot.
So I don't see how you can say that only \n is handled differently.
The external reps of all of them are implementation specific.

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
     Producers of Comeau C/C++ 4.2.38 -- NOTE 4.2.42 BETAS NOW AVAILABLE
    Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.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 <david@tribble.com> writes:
> What does the curses source code, which I assume is portable, use
> for ESC?

I don't think it uses ESC in the source.  It certainly doesn't need
to.  It looks up and prints escape sequences from a database - these
can have ESC in them, rather than having curses print the ESC
literally.  That would be a bad idea anyway, since it would mean that
curses could only be useful when all escape sequences begin with ESC.


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              ]

In article <37E9A9A6.F65200A@acm.org>, Pete Becker  <petebecker@acm.org> wrote:
>So, how do you communicate to users? Morse code, using \a? <g>

Don't be silly; Morse was officially decommissioned.

Now we use speech synthesis, since it's more portable than using ASCII for
output.

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

In article <t7905x362k.fsf@calumny.jyacc.com> Hyman Rosen <hymie@prolifics.com> writes:
>
>comeau@panix.com (Greg Comeau) writes:
>> If the above is so (you have such a translator), then why is this so:
>> >then I need \e because I cannot blithely include \x1B in the code.
>> Your saying you don't care about portability and you'll be getting
>> \x1B anyway, no?
>
>No. He'll get \x1B *after* translation. That's why he needs \e in
>the source, in order to portably specify the character which will
>become \x1B, just like he uses 'a', which will become \x61 after
>translation.

Note my remark that he didn't care about portability (at least that's
how I understood it) so telling me how to portability specify it seems
neither here nor there.

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
     Producers of Comeau C/C++ 4.2.38 -- NOTE 4.2.42 BETAS NOW AVAILABLE
    Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.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:
>
> "David J. Littleboy" wrote:
...
> > and character codes in the execution character set, so both the C and C++

^^^^^^^^^
> > standards are explicit that \a must map to a particular value, namely alert
> > (BEL) in the execution character set.
>
> It says that \a must be translated to a unique, implementation-defined
> value. It says nothing about BEL.

The C++ standard identifies BEL with '\a' - the C standard doesn'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              ]

In article <37EA6EA6.23E00688@wizard.net> James Kuyper <kuyper@wizard.net> writes:
>Pete Becker wrote:
>...
>> The compiler and its runtime library come from the same vendor, and that
>
>Not necessarily; some C++ compilers are piggy-backed on top of whichever
>C compiler is currently installed, using that compiler's library for the
>C part of the C++ standard library.

Comeau C++ does that.

>I've often wondered how they can
>claim conformance, when a large portion of their conformance depends
>upon someone else's software.

I've often wondered how any C++ compiler or library vendor can
claim conformance, but do it they do.  Anyway, we don't -- we just
say we target the Standard and are doing quite quite well language-wise.

Anyway too, there's always a comfort point zone where a vendor
can reasonably say they are compliant.  That they depend upon
someone else's software may seem odd, but no more odd that many of
the other claims/situations, theoretical and real, being made. :(

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
     Producers of Comeau C/C++ 4.2.38 -- NOTE 4.2.42 BETAS NOW AVAILABLE
    Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.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:
>
> In article <37E99A83.8084A1C0@acm.org>,
> Pete Becker  <petebecker@acm.org> wrote:
> >Paul Jarc wrote:
> >>
> >> Those things can certainly be done, but not portably, which was Pete's
> >> point.  \v etc. are no more portable according to the standard, but he
> >> refuses to accept this.
> >
> >I refuse to accept it because it isn't so. The words that describe the
> >effect of the character escape sequences are not in a note, they are not
> >in an example, they are not in a footnote. They are normative text, and
> >you cannot simply ignore them.
>
> Well, you are wrong.  On two grounds.  The first being that the text
> of the standard clearly states that they are INTENDED to produce
> certain effects, whereas everything that the standard demands of an
> implementation uses different wording.  The second is that it is not
> always possible to fulfil that intent (which is why it is an intent
> and not a requirement.)

If the folks who wrote the standard intended them to be ignored they
wouldn't have included them. If they meant them merely as advice they
would have put them in the rationale, or perhaps in a footnote or a
comment. Since they did not do any of these, but put them in the
standards text itself, the words are not intended to be ignored.

The standard says nothing about the effect of '\033', so its effect is
undefined. The standard has words about the effect of '\n'. Those words
do not mean that its effect is undefined, because we have seen that the
authors of the standard know how to say that, and they didn't say 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              ]

Paul Jarc wrote:
>
> It's embedded within normative text, but it imposes no requirements,
> so it's no straonger than a footnote or example.
>

ISO rules say that footnotes and examples are not normative. Where does
your rule come from?

--
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 Kuyper wrote:
>
> Pete Becker wrote:
> ...
> > The compiler and its runtime library come from the same vendor, and that
>
> Not necessarily; some C++ compilers are piggy-backed on top of whichever
> C compiler is currently installed, using that compiler's library for the
> C part of the C++ standard library. I've often wondered how they can
> claim conformance, when a large portion of their conformance depends
> upon someone else's software.
>

They have to test carefully, and often.

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

Greg Comeau wrote:
>
> 4) The crux??: "To avoid the issue of whether an implementation conforms
>    if it cannot properly effect vertical tabs (for instance), the
>    Standard emphasizes that the semantics merely describe intent."
>    Why isn't this just undefined behavior, and be done with it?
>

Because the authors of the standard wanted to make a stronger statement
than leaving the behavior undefined.

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

Greg Brewer wrote:
>
> Pete Becker <petebecker@acm.org> wrote in message
> news:37E9A255.D6EFBE3D@acm.org...
> > > No weaseling by pointing at the standard, please. Implementation
> details.
> >
> > Well, it's pretty much a beginner's exercise, but if you insist, here's
> > a sketch:
> >
> > int putc(char *str)
> > {
> > int ch;
> > char *s = str;
> > while((ch = *s++) != '\0')
> > switch(ch)
> > {
> > case '\a':
> > beep();
> > break;
> > case '\t':
> > put(' ');
> > while(col % tab != 0)
> > put(' ');
> > break;
> > case '\n':
> > while(col != 0)
> > put(' ');
> > break;
> > case '\e':
> > /* exercise for the reader */
> > break;
> > ....
> > default:
> > put(ch);
> > }
> > return s - str;
> > }
>
> Dear compiler vendor:
>
> I would like a refund on the compiler I purchased from you.  It has the
> following defects
> 1) when I execute the following program
>    pgm1.c
>    #include <stdio.h>
>    int main(void) {
>       putc("\n");
>       return 0;
>     }
>     and execute as
>        pgm1 > anyfile1.txt
>    it hangs in an infinite loop.

If this is intended to be a comment on the code snippet that I posted,
note that I did not give any implementation for put. You must have
filled that in yourself, and gotten it wrong.

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

Francis Glassborow wrote in message
<3JfI+kARnq63EwyM@robinton.demon.co.uk>...

>I wish we had some input from those that do not use the US alphabet.  I
>think that the Japanese might have a different take on this.

One of the reasons I've been chipping in here is that ISO-2022-JP uses a
7-bit encoding to represent a large character set by using SI and SO to
shift state. Which means that some people who deal with that standard might
like an easier way to represent those values.

You might check out Ken Lunde's book "CJKV Information Processing" from
O'Reilly.

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              ]

Greg Brewer wrote:
>
> Pete Becker <petebecker@acm.org> wrote in message
> news:37E9A8BC.4667B075@acm.org...
> > Every runtime library for DOS translates the single character \n into
> > two ASCII characters, CR and LF, when writing it to the screen. That's
> > because there is no single character that you can write to the screen
> > under DOS that will move the output position to the beginning of the
> > next line.
>
> Not true.  It only does the translation when writing to an output stream
> that is opened in text mode.
>

I agree with everything in the preceding paragraph except the first
sentence. I would replace it with "True." since it simply restates what
I said previously. (You can't legally send the contents of a binary
stream to the screen).

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

Steve Downey wrote:
...
> No, it would produce implementation-defined behavior. The
> implementation would be required to document what, if anything, \e
> did. In particular, \e would always have the same interpretation. It
> could not occasionally start WW3.

Why not, so long as they document the fact?
---
[ 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 <7se3a5$4fn$1@panix3.panix.com>,
Greg Comeau <comeau@comeaucomputing.com> wrote:
>
>In article <7sdq76$l11$1@pegasus.csx.cam.ac.uk> nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
>
>>The second is that it is not
>>always possible to fulfil that intent (which is why it is an intent
>>and not a requirement.)
>
>This does not seem in dispute.  But failure to accomplish
>the intent does not make the portable effect of the sequence wrong
>(one can intepret to above that you are saying it does, at least I did).

I have absolutely no idea what the committee intended in a case where
it cannot be translated into anything sensible, and I don't think that
they did, either.  I know what I did, what several of the other relevant
implementations did, and can think of many other plausible approaches.
It cannot be used to produce a consistent effect under all conforming
implementations, which is the normal meaning of "portable".

You can, however, reasonably expect that all implementations will do
SOMETHING sensible with it (such as ignoring it or diagnosing it),
but the latter is very little different from rejecting it.  In this,
it does not differ in the slightest from the way that '\e' would be
specified and treated.


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 <prj@po.cwru.edu> wrote in message
news:m34sglqrcb.fsf@multivac.student.cwru.edu...
>
> "Greg Brewer" <nospam.greg@brewer.net> writes:
> > Pete Becker <petebecker@acm.org> wrote in message
> > news:37E9A8BC.4667B075@acm.org...
>
> > Not true.  It only does the translation when writing to an output stream
> > that is opened in text mode.
>
> As he said, "when writing it to the screen".  stdout and stderr are in
> text mode, and you can't get a binary-mode stream writing to the
> screen in strictly conforming code.

Again, not true.  I know I have seen a function somewhere that will change
the mode of a stream.   I don't believe there is anything in the standard
that disallows strictly conforming code from changing the mode of any stream
including stdout and stderr.  I personally would discourage doing so though.

Also, you can open another stream in binary-mode that will write to the
screen.

Greg Brewer
---
[ 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:

>Pete Becker wrote:
>...
>> The compiler and its runtime library come from the same vendor, and that

>Not necessarily; some C++ compilers are piggy-backed on top of whichever
>C compiler is currently installed, using that compiler's library for the
>C part of the C++ standard library. I've often wondered how they can
>claim conformance, when a large portion of their conformance depends
>upon someone else's software.

Most C++ implementations come with a C++ library that they got
somewhere else (typically from Dinkumware or Rogue Wave). Isn't
that the same situation? That is, the question is whether the
library (or whatever) is compliant, not who wrote it.

--
Steve Clamage, stephen.clamage@sun.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              ]

I wrote:
> Although I've never seen a terminal
> for which "\f" wouldn't do the same thing more succinctly.

Now to pick on myself:  It's been pointed out to me that formfeed
(usually '\f') does _not_ clear the screen on the VT100 or anything
compatible with it (e.g., `xterm').  Apparently I haven't tried writing
a formfeed to the screen since my Radio Shack days.

     - John Hauser
---
[ 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 <37EA19B4.CB3501AE@acm.org>...

>That's all fine, but so far nobody has been willing to propose anything
>non-trivial for the intent of \e.

That's because specifying the intent of an escape sequence is meaningless.

I think you (and the giants on whose shoulders we all stand) have conflated
_compile time_ issues with _run time_ issues. Since escape sequences _must_
be translated into single char objects with a value from the execution set
_at compile time_, that translation has to be defined in terms of the
execution character set; it makes no sense to talk about the behavior of
"\a"at run time, since "\a" doesn't exist at run time. This means that the
wording "\a (alert) Produces an audible or visible alert. The active
position shall not be changed." is, in principle, meaningless and
unenforcible. The only thing that can be said _at compile time_ is "\a:
Shall be translated into the code point that is defined by the execution set
to produce an audible or visible alert and not change the active position if
such a unique code point exists. Undefined otherwise."

At which point, we need to ask what is an escape sequence? The above
reasoning leads me to believe that an escape sequence is nothing more than a
notation for representing nongraphic code points in the execution set. At
which point the question arises: what's wrong with defining escape sequences
for code points in the execution set that are not meaningful to display
devices? Well, it would be meaningless if it ended up that we were defining
escape sequences that were only meaningful in one arbitrary character set.
but that's not the case. ESC is well-defined (but with different values) in
all the major execution charcter sets, and thus a prime candidate for
providing as a language feature.

The next question that arises is: what should printf do if it gets a \e? My
original thought was: exactly the same as what it now does if I feed it an
x1B. However, there's a better answer. Since \e names a code point that exis
ts in multiple execution character sets, printf's specifications can now be
written in terms of "ESC in the execution character set". This gives you
portable behavior, a big improvement over magic constants which may be
meaningful on some platforms but not others.

I'm not unsympathetic to your desire for standardized requirements for the
meanings of characters sent to standard library routines. It's just that
there are other places than standard library routines to which characters
and strings get sent. The language should support those other places as
well.

David J. Littleboy
Tokyo, Japan
davidjl <at> gol <dot> com

PS: By the way, the above compile time reasoning has frightening
implications for "locale" in both C and C++. Since character and string
literals are translated into the execution character set at _compile time_,
I suspect there is wording in both the C and C++ standards that cannot be
met, since (I think) it ends up specifying that certain decisions that have
to be made at compile time be local-dependent, and the locale has to be
switchable at run time. Ouch.
---
[ 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              ]

Kai Henningsen wrote:
>
> petebecker@acm.org (Pete Becker)  wrote on 18.09.99 in <37E3C243.6D141DF5@acm.org>:
>
> > Kai Henningsen wrote:
> > >
> > > petebecker@acm.org (Pete Becker)  wrote on 16.09.99 in
> > > <37E0F7C9.9B295B80@acm.org>:
>
> > > > Suppose I'm implementing the standard library on a system whose display
> > > > device is mapped to an 80x25 array of 16-bit storage cells that hold
> > > > character codes and color codes. I know how to write the code that deals
> > > > with \a, \t, \r, \v, etc. What code does this definition (or any other
> > > > proposed definition) require me to write to handle \e?
> > >
> > > You know that?
> > >
> > > What do you do for \a?
> > >
> > > What do you do for \t?
> > >
> > > What do you do for \v?
> > >
> > > How do you now these things?
> > >
> >
> > Once again, condensed from the C standard:
>
> I know what the standard says; I have it right here.
>
> That wasn't the question.
>
> The question was, in the situation you describe above, what do *you* do?
>
> No weaseling by pointing at the standard, please. Implementation details.

Well, it's pretty much a beginner's exercise, but if you insist, here's
a sketch:

int putc(char *str)
{
int ch;
char *s = str;
while((ch = *s++) != '\0')
switch(ch)
{
case '\a':
 beep();
 break;
case '\t':
 put(' ');
 while(col % tab != 0)
  put(' ');
 break;
case '\n':
 while(col != 0)
  put(' ');
 break;
case '\e':
 /* exercise for the reader */
 break;
....
default:
 put(ch);
}
return s - str;
}

>
> You claimed to know how to write that code; from your spec, I certainly
> don't. That is, I could write several completely different and mutually
> incompatible implementations of the above spec.

No, not if you're reading it objectively. It's possible to implement it
in ways that are superficially different, e.g. in the spacing of tabs,
but the words in the standard are pretty clear.

>
> When you show me how you select between these different ways to do it, I
> can probably show you how to do the \e part.

Now fill in the code for \e. No weaseling by writing the character
directly to the device, please. Implementation details.

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

Christopher Eltschka wrote:
>
> Pete Becker wrote:
> >
> > Al Stevens wrote:
> > >
> > > Pete Becker wrote
> > > >Suppose I'm implementing the standard library on a system whose display
> > > >device is mapped to an 80x25 array of 16-bit storage cells that hold
> > > >character codes and color codes. I know how to write the code that deals
> > > >with \a, \t, \r, \v, etc. What code does this definition (or any other
> > > >proposed definition) require me to write to handle \e?
> > >
> > > It's not an issue for standard library implementors. It's an issue for
> > > device and display protocol driver implementors. As a standard library
> > > implementor, none of those characters should be your concern.
> >
> > Sorry, but that display device that I describes is standard out, and
> > I've got to write the library code that puts characters out to it.
>
> Well then it's simple: Just make it mean what _you_ think
> it should mean. Maybe you'd like it to be VT100 compatible
> (that is, programs writing VT100 escape sequences using \e
> work as expected), then this fixes the interpretation. But
> you could also define it to just select output color by
> just using the next two letters as hex number (and ignoring
> the escape if they are not hex digits), so \e07 would set
> the attribute byte of the following outputted characters
> to 7. Or you could decide to ignore \e completely.
> That's what ESC is for: Allow to interpret some following
> characters in any way you like.

That's fine for the library implementor, but it leaves programmers out
in the cold. If it's entirely up to the implementor to decide how to
treat \e then there's no program that you can write that uses \e in a
non-trivial way but has predictable behavior. Which, oddly enough, is
exactly what you have under the C standard as it exists today -- the
standard does not put any requirements on a program that uses \e, so
it's up to your compiler vendor to decide whether to do something useful
with it, and if so, to tell you what you can do.

>
> >
> > > It's up to a
> > > lower level of abstraction (BIOS, ANSI.SYS, curses, custom device driver,
> > > whatever) to decide where the next tab is, how to get the cursor to the
> > > first column of the next line, and so on, when they see one of those
> > > characters in the stream.
> >
> > No, it's part of the language definition, so as a library implementor
> > I'm responsible for making sure that code that uses it acts in a way
> > that's consistenet with the requirements of the standard.
>
> And Escape allows you to temporarily escape from that (Well, you
> might still be bound by things like VT100).
>
> >
> > > "Implementation-defined" means just that. As a standard library implementor,
> > > you would do exactly whatever you would now do in the circumstance you
> > > described (and given the absense of support for '\e') when (assuming your
> > > display is an ASCII device) you write the code that deals with '\x1b'. Which
> > > is that you trust the programmers to know what they are doing and pass the
> > > characters along to the logical device. Just exactly as you would do with
> > > \t, \n, \v, \f, \r, \b.
> >
> > There is no prescribed value for \t, \n, \v, etc. Their definitions are
> > in terms of observable behavior, not values. That's how they differ from
> > '\x1b' or '\x07' or any other explicit value. What value should '\e'
> > have? If it's '\033' then its utility is that it saves typing two
> > characters. Hardly a valid use of all the time that's been spent on this
> > thread.
>
> The value should be the value defined as "ESC" in the execution
> character set. If the system you're on doesn't define a native
> ESC, it's your choice to do a reasonable choice (just as it is
> with \a, f.ex.)

What criteria should a compiler writer apply to decide what a
"reasonable choice" is? If nobody says what \e is supposed to do, theirs
no way to decide whether what it does is reasonable.

>
> What you are obviously missing is that \a does not only
> have an intended effect, but is also a regular character
> (you can assign it to a char variable, and it has an
> integer value you can get by assigning it to int).
> The exact value it maps to is, of course, implementation
> defined (ASCII systems will use 7, but that's outside the
> C/C++ standards).

Exactly: it's outside the standard, and on an ASCII system it may be
convenient to use 7, but you can get exactly the same effect with any
other non-printable value.

>
> int i = '\a';
>
> is legal in both C and C++, and it must result in a value.
> On ASCII systems I reasonably expect it to result in the
> value 7. That's not demanded by the standard, but it's
> the reasonable behaviour.

But to the programmer, what difference does it make what value the
compiler uses for \a? If you write \a to the display you get a beep. As
long as it works, it doesn't matter whether the internal representation
is 7, 132, or 1.

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

Kai Henningsen wrote:
>
> petebecker@acm.org (Pete Becker)  wrote on 18.09.99 in <37E3C2D8.D95C0E2D@acm.org>:
>
> > Sigh. Yes, that's what it says, and all the rest are mere words that any
> > implementor is free to ignore at their peril. The fact is that every
> > library implementor on every platform where these operations are
> > possible tries to implement what those words say.
>
> It is true that every implementation tries to convert these sequences
> according to the expectations of their users.
>
> It is also true that no implementation I know of - not a single one -
> tries to do anything at all about the behaviour of these characters, when
> output via standard library functions in the direction of a display
> device.
>

Every runtime library for DOS translates the single character \n into
two ASCII characters, CR and LF, when writing it to the screen. That's
because there is no single character that you can write to the screen
under DOS that will move the output position to the beginning of the
next 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              ]

"David J. Littleboy" wrote:
>
> Pete Becker wrote in message <37E6F2EA.BC2A01EE@acm.org>...
>
> >Why should \a map to some particular value? The standard describes what
> >effect it has. The value that's used to get that effect is noboby's
> >business.
>
> While the C++ standard has the good sense not to get into this, C90 clearly
> defines the escape sequences as shorthands for control characters that "are
> intended to produce actions on display devices".>

NO. It describes the effect of characters that occur in the source code.
Is says nothing at all about control characters.

> However, it also clearly
> states that there is a one to one correspondence between escape sequences
> and character codes in the execution character set, so both the C and C++
> standards are explicit that \a must map to a particular value, namely alert
> (BEL) in the execution character set.

It says that \a must be translated to a unique, implementation-defined
value. It says nothing about BEL.

>
> Anyway, you are correct that the C standard states that escape sequences are
> limited to representing character codes in the execution character set that
> correspond to "actions on display devices".
>
> This strikes me as a historical glitch.

It strikes me as both deliberate and useful.

> Syntactically and logically*, there
> is no reason that escape sequences should be limited to such characters, and
> since \e is clearly useful, it seems that this section needs to be
> rewritten. The C++ standard, quite correctly, says nothing about "display
> devices". Someone should write this up and send it in as a defect report to
> the C committee. (I'm not volunteering because I don't follow C, only C++
> discussions.)
>
> *: Talking about "actions on display devices" and the definitions of those
> actions are seriously inappropriate for a language standard. The langauge
> should only talk about representing the execution character set and leave
> how the execution character set is interpreted to the appropriate standards.

So, how do you communicate to users? Morse code, using \a? <g>

--
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:
>
> "Paul D. DeRocco" <pderocco@ix.netcom.com> writes:
> > Newline is a special case, and the library guarantees its behavior,
> > because it, unlike all the rest of the control characters, is
> > absolutely necessary for communicating lines of text among programs.
>
> Any particular library may guarantee it behavior, but I don't believe
> the standard does.
> That would seem to imply that writing anything to stdout invokes
> undefined behavior, since 1. there are no standard-provided means to
> determine whether stdout is connected to a display device, 2. whether
> a newline is required at the end of the last line is implementation-
> defined, and 3. the effect of writing newline to a display device is
> undefined.
> Of course, the effect of writing even printable characters to a
> display device is also expressed only as intent.
>

However, expressing "only ... intent" is a great deal more than the
standard does for, say, '\033'. So trivializing it in this way is
misleading, particularly since it seems to lead people to ignore
normative words.

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

root wrote:
>
> Yes, in that code the compiler will have translated the '\t', and call
> something like std::cout::operator <<(char).  The actual 'char' value
> which gets passed to this depends on the compiler's knowledge of the
> environment which is targetted -- if that environment doesn't support a
> horizontal tab character then I suppose (and maybe Pete Becker or other
> library implementors could comment here) that its at this level or below
> that they might intercept their chosen '\t' char and call some code to
> move the current output position suitably.

I disagree. The compiler should only translate backslash lower case t into
the execution character set's tab character. It shouldn't care anything
more specific about the environment than what its execution character set
is (i.e., ASCII or EBCDIC), because it (the compiler) cannot know what
ultimate process or device will be consuming the character. It isn't up to
the compiler, or even the standard library, to do any translation on it.

Your description of the sort of translation that the library might make
applies to \n, but that's a special case. The standard mechanism for
passing text from one program to another (e.g., Unix pipes used to
implement text-based filters) _requires_ the ability to move to the start
of the next line, and there are at least two common standards for doing
this (\n and \r\n). If the inventors of C didn't pick one, and make the
library deal with systems that disagree, then virtually every text-based
program would need special code to handle the conversion in order to be
portable.

But that's the _only_ control function that's _required_ in text-based
processing. The other control characters may have portability problems,
too, but none of them (including tab) is _necessary_ in a simple text file.
They're all for display or printer control, which is inherently somewhat
non-portable anyway, so it doesn't make sense for the library to try to
eliminate the unportability and coerce a particular behavior for any of
them.

--

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              ]

John Hauser wrote:
>
> Actually, according to ISO 6429, that's HTS (Character tabulation set),
> which sets a horizontal tab position.  Perhaps you meant
>
>     cout << "\e[H\e[2J";

You're right. I just wrote that off the top of my head, without looking it
up. I guess it's been a while!

--

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              ]

In article <VtaG3.7578$zI3.108395@iad-read.news.verio.net>,
T.E.Dickey <dickey@clark.net> wrote:
>
>In comp.std.c Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:
>
>> Nor does curses.  It assumes a particular terminal model that may be
>> the only one that you use, but is by no means the only one around
>> (even today.)  Yes, the curses library is THEORETICALLY a bit more
>> portable than the termcap/terminfo one, but in practice it isn't.
>
>not exactly - curses combines known techniques for dealing with odd
>corners of termcap/terminfo which most programmers are not inclined
>to exploit (so it is indeed a little more portable ;-)

I have never come across a terminal where termcap/terminfo could not
be implemented but curses could.  I have come across many where both
were possible, many were neither were possible, and many where both
could be done only in a crippled fashion.

Can you name one where curses could be implemented and termcap/terminfo
could not?


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:
>
> The C standard doesn't say "\t will be the execution character set's
> HT character", because the standard can't know whether the execution
> character set has a character with that name, without restricting the
> set of character sets that can be used.  (Nor can the C++ standard.)
> The value that \t is mapped to presumeably has some name, but there's
> no need or use for specifying it in the C or C++ standards.

I don't have the C standard, but the C++ standard says, "The basic source
character set consists of 96 characters: the space character, the control
characters representing horizontal tab, vertical tab, form feed, and
new-line..." (2.2 para 1) and "The basic execution character set [shall]
contain all the members of the basic source character set, plus control
characters representing alert, backspace, and carriage return, plus a null
character..." (2.2 para 3). It doesn't say what these characters must do on
any output device, but this isn't a problem because every existing standard
character set (which is to say, ASCII and EBCDIC) has corresponding
characters, and people know what they do. The same would be true of escape.

--

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              ]

Mark Wooding wrote:
>
> Pete Becker <petebecker@acm.org> wrote:
>
> > It's simply because I'm not willing to ignore words that appear as
> > normative text in the standard. If you see a conflict between those
> > words and other words in the standard then the solution is to figure out
> > a meaning that accomodates both sets of words, not to pick the one you
> > like better and declare it the winner.
>
> The normative text descibing the alphabetic escape sequences is:
>
>         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.
>
> (5.2.2, para 3, C9X draft dated 1998-08-03.)
>
> The waffle preceding that describes intent only, and imposes no
> requirements.

So why do you think the writers of the standard put those words there?
Just for fun? If they had intended to impose no requirements there is a
much easier way to say it: just say nothing, as they did for '\033'. You
cannot ignore normative words. That's what "normative" means.

--
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:
>
> Pete Becker wrote:
> >
> > Greg Brewer wrote:
> [...]
> >
> > So the reason for having \e is to save you from having to look up what
> > the ASCII code for ESC? Well, there are a bunch more ASCII codes out
> > there, too. Are they also candidates for adoption into the C standard?
> > If so, what do we do for the poor EBCDIC folks?
>
> As I've pointed out previously, the EBCDIC character set contains
> all 32 of the ASCII control characters, including ESC.  (Plus 32 more
> control codes that have no ASCII equivalents.)
>
> But we're not talking about defining all 32 ASCII control codes in
> ISO C, but only one: '\e'.
>

Please quote accurately. The text that I was responding to said

> In the course of implementing the function
> that translated the string from the entered representation to the internal
> representation, I had to go look up the code for escape.  At that time, I
> thought "gee, wouldn't it be nice if the sequence was available so I didn't
> need to look it up."

This argument applies equally to every control 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              ]

David R Tribble wrote:
>
> Christopher Eltschka wrote:
> >
> > Pete Becker wrote:
> >
> > > Once again, condensed from the C standard:
> > >
> > >     \a (alert) Produces an audible or visible alert.
> > >     \b (backspace) Moves the actrive position to the previous
> > >        position on the current line.
> > >     ...
> >
> >       \e (escape) allow a different interpretation of following
> >           characters.
>
> Jeez.  Let's just make it simple, since we can't agree on anything
> complicated:
>
>     \e (escape)  produces an implementation-defined effect.
>

So the difference would be that under the C standard as it exists today,
\e produces undefined behavior. Not much difference there: if you use it
in your program you better know what your compiler vendor will do with
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              ]

Pete Becker <petebecker@acm.org> writes:
> Right. I'm not sure at this point if you're agreeing with me or
> disagreeing. Yes, every escape character sequence is compiled to a
> value. The code that writes such values to an output device is
> responsible for making sure that those values have the appropriate
> effect. If sending the value to the device will do it, fine. If not,
> then do something else.

This is false. The runtime sometimes writes out 13 and 10 when asked
to write a 10, but this is because it is matching the C/C++ fiction
that text files contain lines terminated by a single character to the
external reality of text files which contain lines terminated by a
pair of characters.

> So what is the intent of \e? What should a sane implementor do with it?
> Emulate an ANSI drive if one isn't present?

No, assign a character value to it and deliver that value just as it
does for \a, \v, \r, and \t. Only \n is handled differently, and that
is only for files opened in text mode.


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

comeau@panix.com (Greg Comeau) writes:
> If the above is so (you have such a translator), then why is this so:
> >then I need \e because I cannot blithely include \x1B in the code.
> Your saying you don't care about portability and you'll be getting
> \x1B anyway, no?

No. He'll get \x1B *after* translation. That's why he needs \e in
the source, in order to portably specify the character which will
become \x1B, just like he uses 'a', which will become \x61 after
translation.


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

Christopher Eltschka wrote:
>
>
> If the standard demanded \e, and gave the intent, then
> you could expect code containing "\e" to work. If on your
> compiler it doesnm't work, but the execution character set
> has an ESC character, you could blame your compiler vendor
> - not to violate the standard, but to not follow the intent.
> Currently, if you want "\e" in your compiler, your position
> is not very good - there's no standard intent given, so
> there's no reason why your compiler vendor should give you \e
> and give it the intended meaning, unless you are one of the
> main customers of the compiler.

That's all fine, but so far nobody has been willing to propose anything
non-trivial for the intent of \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              ]

In article <37E99A83.8084A1C0@acm.org>,
Pete Becker  <petebecker@acm.org> wrote:
>Paul Jarc wrote:
>>
>> Those things can certainly be done, but not portably, which was Pete's
>> point.  \v etc. are no more portable according to the standard, but he
>> refuses to accept this.
>
>I refuse to accept it because it isn't so. The words that describe the
>effect of the character escape sequences are not in a note, they are not
>in an example, they are not in a footnote. They are normative text, and
>you cannot simply ignore them.

Well, you are wrong.  On two grounds.  The first being that the text
of the standard clearly states that they are INTENDED to produce
certain effects, whereas everything that the standard demands of an
implementation uses different wording.  The second is that it is not
always possible to fulfil that intent (which is why it is an intent
and not a requirement.)


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 <7sameu$juq$1@news.hal-pc.org>, Greg Brewer
<nospam.greg@brewer.net> writes
>If the program identified the escapes sequences with \e then the
>recompilation would be a snap.  Just buy some protocol converters to attach
>the Wyse terminals and we would be all set.

Well your protocol converters would work anyway.  But for recompilation
all you need is an appropriate file of #defines.



Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


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

Greg Comeau wrote:
>
> "Paul D. DeRocco" <pderocco@ix.netcom.com> writes:
> >If I need to talk to a physical device that uses ASCII
> >ESC to introduce escape sequences, and I want the program to be portable
> >to an EBCDIC machine, which has an EBCDIC to ASCII translator somewhere
> >between the program and the device,
>
> If the above is so (you have such a translator), then why is this so:
>
> >then I need \e because I cannot blithely include \x1B in the code.
>
> Your saying you don't care about portability and you'll be getting
> \x1B anyway, no?

If the compiler is an EBCDIC compiler, and I put the letter X in a string,
the compiler will put the value 0xB7 into its representation. If this goes
through an EBCDIC to ASCII converter, on the way to an ASCII printer, the
converter will translate 0xB7 into 0x58, the ASCII equivalent.

For the converter to produce 0x1B, the ASCII escape, it would need to be
given 0x27, so the compiler had better translate \e into 0x27. If it
translated it into 0x1B instead, the EBCDIC to ASCII converter wouldn't
know what to do with it, because that's the EBCDIC CU1 character, for which
there is no ASCII equivalent.

Thus, \e would be every bit as much an aid to portability as \n is.

--

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              ]

Pete Becker wrote:
...
> The compiler and its runtime library come from the same vendor, and that

Not necessarily; some C++ compilers are piggy-backed on top of whichever
C compiler is currently installed, using that compiler's library for the
C part of the C++ standard library. I've often wondered how they can
claim conformance, when a large portion of their conformance depends
upon someone else's software.


[ 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 <francis@robinton.demon.co.uk> writes:
> In article <37E7D66E.8DF0C42D@ix.netcom.com>, Paul D. DeRocco
> <pderocco@ix.netcom.com> writes
> >But if I turn out to be wrong about that, then \e must OBVIOUSLY
> >produce the escape character for that character set if there is one, or
> >generate an error message otherwise.
>
> If \e were part of the standard I do not think it would be allowed to
> produce a diagnostic.

I think a *required* diagnostic would be problematic, but a voluntary
diagnostic would be most helpful in this case.


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 <petebecker@acm.org> wrote in message
news:37E9A255.D6EFBE3D@acm.org...
> > No weaseling by pointing at the standard, please. Implementation
details.
>
> Well, it's pretty much a beginner's exercise, but if you insist, here's
> a sketch:
>
> int putc(char *str)
> {
> int ch;
> char *s = str;
> while((ch = *s++) != '\0')
> switch(ch)
> {
> case '\a':
> beep();
> break;
> case '\t':
> put(' ');
> while(col % tab != 0)
> put(' ');
> break;
> case '\n':
> while(col != 0)
> put(' ');
> break;
> case '\e':
> /* exercise for the reader */
> break;
> ....
> default:
> put(ch);
> }
> return s - str;
> }

Dear compiler vendor:

I would like a refund on the compiler I purchased from you.  It has the
following defects
1) when I execute the following program
   pgm1.c
   #include <stdio.h>
   int main(void) {
      putc("\n");
      return 0;
    }
    and execute as
       pgm1 > anyfile1.txt
   it hangs in an infinite loop.
2) when I execute the following program
   pgm2.c
   #include <stdio.h>
   int main(void) {
      putc("\txxxx");
      return 0;
   }
   and execute as
      pgm2 > anyfile2.txt
      pgm2 >> anyfile2.txt
   the program fails to put a character appropriate to my os in the file of
the \t and instead
   puts spaces in it.  This causes the alignment of the 2nd column to be
incorrect incorrectly.

3) when I execute the following program
   pgm3.c
   #include <stdio.h>
   int main(void) {
      putc("\a");
      return 0;
   }
   and execute as
      pgm3 > anyfile3.txt
   the computer beeps and nothing is stored in the file.

I cannot tell you how disappointed I am that your product fails to live up
to the high standards I have come to expect of your products.

Sincerely,
Greg Brewer




[ 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:
> No, they want it to be some particular character, depending on the
> target system, i.e. the "escape character." I suspect they would be very
> unhappy if \e were translated into 09 on an ASCII system, because then
> it would tend to cause display devices to move to the next tab stop.

And they would be just as unhappy if \b was written as \x33[D, despite
the fact that on many display devices, this will cause the output position
to back up by one 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              ]

Pete Becker <petebecker@acm.org> writes:
> the standard doesn't say that the implementation must
> unconditionally do this. That's not the same thing as saying nothing
> about it.

Effectively, it is.  You're right that implementations need not
"unconditionally do this".  But there's no conditional requirement,
either: the standard does not specify any conditions under which
implementations are required to do it.  Hence they are never
required.

> But the behavior of escape sequences is not "completely unspecified or
> even undefined." It's right there in the standard, outside of any notes,
> examples, and footnotes. It's normative text, and should not be ignored.

It's embedded within normative text, but it imposes no requirements,
so it's no straonger than a footnote or example.


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              ]

In article <37E99A83.8084A1C0@acm.org> Pete Becker <petebecker@acm.org> writes:
>> \v etc. are no more portable according to the standard, but he
>> refuses to accept this.
>
>I refuse to accept it because it isn't so. The words that describe the
>effect of the character escape sequences are not in a note, they are not
>in an example, they are not in a footnote. They are normative text, and
>you cannot simply ignore them.

I agree: usually the intent :) is that you cannot --should not-- ignore them.
But to summarize, the argument I think I'm seeing is that there is no
"shall" just "intent".  But I'm not yet convinved we should view the
words as defective, or as less, just because they are different.
Let's just called them `intention-defined' :)

Frankly, I find this thread confusing at this point, so I just went to
check the original Standard C rationale on this section.  A few points
seems to pop up here:
1) It says "These character codes are clearly modelled after ASCII
   control codes."  Hmmmm.

2) It say "they are internal codes... [and the] external rep ...
   may well differ from the internal rep BOTH in character codes and
   number of characters needed to represent a single internal code"

3) Also "Proposals to add '\e' for ASCII ESC ('\033') were not
   adopted because other popular character sets such as EBCDIC have no
   obvious equivalent."  Hasn't somebody been saying otherwise here???

4) The crux??: "To avoid the issue of whether an implementation conforms
   if it cannot properly effect vertical tabs (for instance), the
   Standard emphasizes that the semantics merely describe intent."
   Why isn't this just undefined behavior, and be done with it?

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
     Producers of Comeau C/C++ 4.2.38 -- NOTE 4.2.42 BETAS NOW AVAILABLE
    Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.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 comp.std.c Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:

> In article <VtaG3.7578$zI3.108395@iad-read.news.verio.net>,
> T.E.Dickey <dickey@clark.net> wrote:
>>
>>In comp.std.c Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:
>>
>>> Nor does curses.  It assumes a particular terminal model that may be
>>> the only one that you use, but is by no means the only one around
>>> (even today.)  Yes, the curses library is THEORETICALLY a bit more
>>> portable than the termcap/terminfo one, but in practice it isn't.
>>
>>not exactly - curses combines known techniques for dealing with odd
>>corners of termcap/terminfo which most programmers are not inclined
>>to exploit (so it is indeed a little more portable ;-)

> I have never come across a terminal where termcap/terminfo could not
> be implemented but curses could.  I have come across many where both

There was some discussion yesterday, for example, about PDCurses, which
uses direct I/O on some console devices.  That's incompatible with
terminfo and termcap.  (PDCurses also has an X Windows driver, just
in case you propose objecting on the basis that one could "always"
use ANSI.SYS - which isn't possible in some DOS-like environments
that other people on this list say they know all about ;-).

(I have other examples in mind, also, which you should be familiar
with)

--
Thomas E. Dickey
dickey@clark.net
http://www.clark.net/pub/dickey


[ 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> wrote in message
news:37E9A8BC.4667B075@acm.org...
> Every runtime library for DOS translates the single character \n into
> two ASCII characters, CR and LF, when writing it to the screen. That's
> because there is no single character that you can write to the screen
> under DOS that will move the output position to the beginning of the
> next line.

Not true.  It only does the translation when writing to an output stream
that is opened in text mode.

Greg Brewer



[ 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 <7sdq76$l11$1@pegasus.csx.cam.ac.uk> nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
>In article <37E99A83.8084A1C0@acm.org>,
>Pete Becker  <petebecker@acm.org> wrote:
>>Paul Jarc wrote:
>>> Those things can certainly be done, but not portably, which was Pete's
>>> point.  \v etc. are no more portable according to the standard, but he
>>> refuses to accept this.
>>
>>I refuse to accept it because it isn't so. The words that describe the
>>effect of the character escape sequences are not in a note, they are not
>>in an example, they are not in a footnote. They are normative text, and
>>you cannot simply ignore them.
>
>Well, you are wrong.  On two grounds.  The first being that the text
>of the standard clearly states that they are INTENDED to produce
>certain effects, whereas everything that the standard demands of an
>implementation uses different wording.

An otherwise strictly conforming app will still be strictly conforming
even if it fails to succeed in a display intent involving an escape
sequence.  So no, it doesn't seem like a requirement.  Nonetheless,
[intended] meaning and behavior are clearly detailed.

>The second is that it is not
>always possible to fulfil that intent (which is why it is an intent
>and not a requirement.)

This does not seem in dispute.  But failure to accomplish
the intent does not make the portable effect of the sequence wrong
(one can intepret to above that you are saying it does, at least I did).

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
     Producers of Comeau C/C++ 4.2.38 -- NOTE 4.2.42 BETAS NOW AVAILABLE
    Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.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              ]

"Greg Brewer" <nospam.greg@brewer.net> writes:
> Pete Becker <petebecker@acm.org> wrote in message
> news:37E9A8BC.4667B075@acm.org...
> > Every runtime library for DOS translates the single character \n into
> > two ASCII characters, CR and LF, when writing it to the screen. That's
> > because there is no single character that you can write to the screen
> > under DOS that will move the output position to the beginning of the
> > next line.
>
> Not true.  It only does the translation when writing to an output stream
> that is opened in text mode.

As he said, "when writing it to the screen".  stdout and stderr are in
text mode, and you can't get a binary-mode stream writing to the
screen in strictly conforming code.


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 <petebecker@acm.org> writes:

> David R Tribble wrote:
> >
> > Christopher Eltschka wrote:
> > >
> > > Pete Becker wrote:
> > >
> > > > Once again, condensed from the C standard:

[...]

> > >
> > >       \e (escape) allow a different interpretation of following
> > >           characters.
> >
> > Jeez.  Let's just make it simple, since we can't agree on anything
> > complicated:
> >
> >     \e (escape)  produces an implementation-defined effect.
> >
>
> So the difference would be that under the C standard as it exists today,
> \e produces undefined behavior. Not much difference there: if you use it
> in your program you better know what your compiler vendor will do with
> it.




No, it would produce implementation-defined behavior. The
implementation would be required to document what, if anything, \e
did. In particular, \e would always have the same interpretation. It
could not occasionally start WW3.


This communication is for informational purposes only.  It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction, unless specifically agreed
otherwise. All market prices, data and other information are not warranted as
to completeness or accuracy and is subject to change without notice. Any
comments or statements made herein do not necessarily reflect those of
J.P. Morgan & Co. Incorporated, its subsidiaries and affiliates.



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

comeau@panix.com (Greg Comeau) writes:
> An otherwise strictly conforming app will still be strictly conforming
> even if it fails to succeed in a display intent involving an escape
> sequence.  So no, it doesn't seem like a requirement.

Actually, this is a matter of implementation conformance, not program
conformance.  Be careful not to get them confused.

> In article <7sdq76$l11$1@pegasus.csx.cam.ac.uk> nmm1@cus.cam.ac.uk (Nick Maclaren) writes:
> >The second is that it is not
> >always possible to fulfil that intent (which is why it is an intent
> >and not a requirement.)
>
> This does not seem in dispute.  But failure to accomplish
> the intent does not make the portable effect of the sequence wrong
> (one can intepret to above that you are saying it does, at least I did).

I don't understand what you're saying here.  It sounds like you're
saying that implementations are allowed to obey the intent of the
standard, even if some do not do so.


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              ]

In article <37E9E0BD.5B2885CB@ix.netcom.com>, Paul D. DeRocco
<pderocco@ix.netcom.com> writes
>It doesn't say what these characters must do on
>any output device, but this isn't a problem because every existing standard
>character set (which is to say, ASCII and EBCDIC) has corresponding
>characters, and people know what they do. The same would be true of escape.

I wish we had some input from those that do not use the US alphabet.  I
think that the Japanese might have a different take on this.


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ 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:
> Your description of the sort of translation that the library might make
> applies to \n, but that's a special case. The standard mechanism for
> passing text from one program to another (e.g., Unix pipes used to
> implement text-based filters) _requires_ the ability to move to the start
> of the next line, and there are at least two common standards for doing
> this (\n and \r\n). If the inventors of C didn't pick one, and make the
> library deal with systems that disagree, then virtually every text-based
> program would need special code to handle the conversion in order to be
> portable.

It's even less than that. C started on UNIX, where text file line
terminators were a single character, ASCII LF. It was always the job of
the tty driver to "cook" LF into CR-LF on output, and CR into LF on
input.

When other systems with different line terminators came along, they
were faced with a large body of C code which would not correctly
process text files. Their solution was to invent a distinction between
text and binary files, and to have something in the runtime system
hide the different text line terminators into 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              ]

Pete Becker <petebecker@acm.org> writes:
> If it's entirely up to the implementor to decide how to
> treat \e then there's no program that you can write that uses \e in a
> non-trivial way but has predictable behavior.

False. If the compiler targets a system which uses ASCII or EBCDIC,
everyone would know that \e translated into ESC of the appropriate
character set, which would then be written unmodified to output
streams. Even you would know this, because you are a library
implementor, and your users would force you to code it that way :-)


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

Steve Downey <sdowney@panix.com> wrote in message
news:uu2oluzg0.fsf@sdowney.ny.jpmorgan.com...
> No, it would produce implementation-defined behavior. The
> implementation would be required to document what, if anything, \e
> did. In particular, \e would always have the same interpretation. It
> could not occasionally start WW3.

What do you mean by implementation?  If you mean that the implementation of
the C standard would have to document what it does, I would have to
disagree.  If your saying that the programmer that writes the statement
   Xmit("Do \eBnot\eN enter");
is the implementation and must document that the first causes bold text and
the second ends it when sent to a DG Scoreboard controller then I agree.

The biggest trouble we are having in the discussion is that ESC is a single
code that -- by its nature -- has no defined behavior.  I think part of it
has to do with why have such sequences in the first place.  When I was
learning to program using Pascal back in college, I wanted to formfeed my
output.  I discovered how to generate the formfeed character and place it in
my string so that I had the statement
   write('x');
where x was the code for formfeed.  When I ran the program, the output was
all nice and neat and followed up with a form feed making it convenent to
tear off of the printer.  However, when I printed by program, it didn't look
so neat because it did a formfeed in the middle of printing out that line of
text.  Having the ability of using \f would have been much preferable.  In
C, it is much easier to refer to a character using its hex or oct
representation and sending that.  However, there certain values that are so
common that it was easier for everyone to have a short hand.  I suspect that
the fact that it made it more portable was only secondary.  These short hand
values were developed in the age of tty devices and tty devices only
supported a limited number of controls.  At that time, ESC was as rare as
sending SI and SO so no one had any special need for it.  Now, we have a
plethora of specialty devices in need of fine control and ESC is the usual
character used to give these devices their special commands.

Greg Brewer




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

Steve Downey wrote:
>
> No, it would produce implementation-defined behavior. The
> implementation would be required to document what, if anything, \e
> did. In particular, \e would always have the same interpretation. It
> could not occasionally start WW3.

I agree with everything in the preceding paragraph except the first
word. What I said is that the standard today makes the behavior of \e
undefined, and one suggestion is to make it implementation defined.
Either way, you can use \e only if your vendor tells you that it will do
what you need.
Making it implementation defined requires vendors to tell you what it
does, but I suspect that this would be mostly generic, because there
really isn't much you can say about what \e does without knowing details
about how the particular system is configured. I doubt that any vendor
would go through a list of all known device drivers and tell you how
their mandated implementation of \e interacted with them.

--
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:
>
> "Paul D. DeRocco" <pderocco@ix.netcom.com> writes:
> > Newline is a special case, and the library guarantees its behavior,
> > because it, unlike all the rest of the control characters, is
> > absolutely necessary for communicating lines of text among programs.
>
> Any particular library may guarantee it behavior, but I don't believe
> the standard does.

I don't have a C standard, so I don't know. But if a compiler for a machine
that used \r\n for starting the next line didn't deal with this
incompatibility in its library, then virtually no text-mode program written
in portable C or C++ would work, not even

 #include <stdio.h>
 int main() { printf("Hello, world!\n"); return 0; }

> > But here's where your argument about the standard requiring certain
> > behavior falls apart. If I write a \v to a disk file, I expect that
> > binary value to be written to the file. If I write a \a to a disk file,
> > I don't expect an audible or visible alert, I expect that binary value
> > to be written to the file.
>
> The language about alerts and tabulation positions is talking only
> about display devices, not files.

True. But the compiler doesn't know, when it sees \a in a quoted string,
whether it will wind up in a display device or a file. It must simply turn
it into a standardized byte value within the string.

> > If the execution character set is ASCII, then \e must produce the
> > ASCII escape character.  If it is EBCDIC, then \e must produce the
> > EBCDIC escape character.
>
> The standard would almost certainly not require that.  But it would
> depend on the wording for \e, which so far has been fluid.  If \e were
> treated like the other \ characters, there would certainly be no
> requirement.

Why wouldn't it require that? The point of having backslash escapes in
C/C++ strings is to define a portable way of including certain standard
control characters in strings, without resorting to nonportable hex or
octal escapes.

--

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              ]

Francis Glassborow wrote:
>
> In article <37E7D66E.8DF0C42D@ix.netcom.com>, Paul D. DeRocco
> <pderocco@ix.netcom.com> writes
> >But if I turn out to be wrong about that, then \e must OBVIOUSLY
> >produce the escape character for that character set if there is one, or
> >generate an error message otherwise.
>
> If \e were part of the standard I do not think it would be allowed to
> produce a diagnostic.

If they wanted to allow for the infinitesimal possibility of some execution
character set that has no standard escape character in it, they could
merely allow a diagnostic in this case.

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.

--

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              ]

Jan Echternach wrote:
>
> In article <37E7DFD6.3A09AC3A@acm.org>,
>         Pete Becker <petebecker@acm.org> writes:
> [intended behaviour of alphabetic escape sequences]
> > It's simply because I'm not willing to ignore words that appear as
> > normative text in the standard.
>
> Now what?  Every compiler vendor must appear at a commitee's meeting
> and swear on the Standard that he really wanted \a to produce an
> audible or visible alert?  Or what is the meaning of "normative
> intend"?
>

Don't confuse enforceability with meaning.

--
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:
>
> Kai Henningsen wrote:
> >
> > Which C implementor has actually done *anything* about those codes, beyond
> > choosing which execution set characters to convert them into?
>
> The runtime library for every C compiler for DOS translates \n into two
> characters on output. Otherwise you end up with subsequent lines
> overwriting previous ones, because DOS requires both a carriage return
> and a linefeed to start a new line.
>

Whoops, I've described
                       the effect of sending LF
                                                to a DOS device

incorrectly.

--
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 <37E7D426.398BD5FD@ix.netcom.com> "Paul D. DeRocco" <pderocco@ix.netcom.com> writes:
>If I need to talk to a physical device that uses ASCII
>ESC to introduce escape sequences, and I want the program to be portable to
>an EBCDIC machine, which has an EBCDIC to ASCII translator somewhere
>between the program and the device,

If the above is so (you have such a translator), then why is this so:

>then I need \e because I cannot blithely include \x1B in the code.

Your saying you don't care about portability and you'll be getting
\x1B anyway, no?

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
     Producers of Comeau C/C++ 4.2.38 -- NOTE 4.2.42 BETAS NOW AVAILABLE
    Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.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              ]

Douglas A. Gwyn wrote in message <37E7B6FE.EC014800@arl.mil>...
>
>"Paul D. DeRocco" wrote:
>> One could wish, I suppose, for C escapes for all standard control
>> characters. However, I'm only suggesting \e for ESC because I think it's
>> the only one that doesn't already have a C escape, and that is commonly
>> used. I know I use it a lot.
>
>Well, there is one problem.  Scarcely anyone I know uses ESC
>in *any* form in his C code.

That a non-argument: if you look around you will notice several people right
here who think they need ESC.

>  On the few occasions when we
>are programming for "glass TTY" terminals (or emulators),
>we use the curses library, which isolates our application
>from the vagaries of terminal models.  (But more often, we
>use "dumb" text or else bitmap facilities.)  ESC itself has
>no role in portable programming.

The problem is that spitting characters at glass TTYs is only a subset of
the applications that actually output text strings to devices or libraries.
The C standard (but not the C++ standard) was written in a way that assumes
that the escape sequences are only for representing carriage control
characters. It's an obvious and natural extension to provide similar escape
sequence aliases for other control codes for other applications. (If I
remember correctly, some Japanese code sets use SI and SO, so applications
that hard-code those sequences might like a \i and a \o escape sequence as
well...)

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:
>
> Christopher Eltschka wrote:
> >
> > Pete Becker wrote:
> >
> > [...]
> >
> > > Once again, condensed from the C standard:
> > >
> > >     \a (alert) Produces an audible or visible alert.
> > >     \b (backspace) Moves the actrive position to the previous position on
> > >         the current line.
> >
> > [...]
> >
> >       \e (escape) allow a different interpretation of following
> >           characters.
>
> Please give an example of code using \e, and based on this definition,
> explain what the behavior of the program will be.

// program 1:

int main()
{
  std::cout << "x\a";
}

// program 2

int main()
{
  std::cout << "x\e\a";
}

Program 1 will output "x" and generate an alert. (Assume on
the given implementation, it does).
Program 2 will output "x", but is allowed (not required)
to interpret the \a differently (f.ex. print the character
which is displayed if you write the code of '\a' directly
to text mode video memory).

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.
---
[ 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 <yjYF3.534$F07.59387@newscene.newscene.com> "Al Stevens" <alstevens@midifitz.com> writes:
>Pete Becker wrote in message <37E7E53E.AF6C7667@acm.org>...
>>If you write a
>>string containing \t to stdout and the result is that the output
>>position moves to the top of the screen without erasing the text that
>>was already on the screen you're entitled to complain, and insist that
>>your compiler vendor make it work right.
>
>No, no, no, no, no. Not no, but heck, no. Given the following program, what
>piece of code do you think generates the several spaces that display between
>the 'a' and the 'b' on the console? Not the library and certainly not the
>compiler.

I don't believe that the Standard agrees with you on that
characterization in that last sentence, but instead leaves it open.

>At least not in a well-designed compiler suite that builds for a
>reasonable console-based target platform.

Something like that.  That is, 'reasonable' might not be the operative word,
but 'common' might be.

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
     Producers of Comeau C/C++ 4.2.38 -- NOTE 4.2.42 BETAS NOW AVAILABLE
    Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.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 <MPG.1251b4105e2c5af89896d5@news.mindspring.com>, Jerry
Coffin <jcoffin@taeus.com> writes
>This might or might not be correct.  In general it's pretty obvious
>that if somebody sends the code for (say) 'A' to the printer, they
>want it printed as an 'A', so that's what you translate to.  OTOH,
>with quite a few control characters, I'm less certain that the
>translation is nearly so obvious.
>
>In addition, you've still got the problem that there's not much you
>can reasonably DO with this, even if you're sure the correct
>translation (whatever that happens to be) takes place.

>From my experience the very last thing I want is translation of control
sequences.  Remember that I have to write device drivers in something,
and C or C++ would seem to be a pretty good candidate.  I really would
prefer not to have to use a different compiler and coding rules for this
kind of low level development.

Actually when I made my original posting I was aware that there are some
nasty features lying around and the way that printer control codes work
mean that any automatic mapping of characters is potentially hazardous.
Sending a control character to a printer (and not just ESC) affects the
interpretation of one or more subsequent characters, but how many is
context dependent.  This is why I believe that the inclusion of \e would
largely provide an illusion that masks unexpected behaviour (like
sending a CTRL Z accidentally because a control quantity just happens to
be 26 this time round.)

While I might argue that several of the currently standardised
\<character>  sequences are almost as poor, they are there and removing
them would cause uproar in some circles.  However the presence of
something for inadequate reasons should not be used as a justification
for adding yet another weak feature.


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ 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              ]

Christopher Eltschka wrote:
>
> Pete Becker wrote:
> >
> > Christopher Eltschka wrote:
...
> > > I'd expect implementors to do something reasonable where
> > > possible. So for purely ASCII systems, I'd expect \e just
> > > to map to \x1B, just as I expect \a to map to \x07.
> >
> > Why should \a map to some particular value? The standard describes what
> > effect it has. The value that's used to get that effect is noboby's
> > business.
>
> Then how do you compile
>
> #include <iostream>
>
> int main()
> {
>   char c = '\a';
>   int i = c;
>   std::cout << i << std::endl;
> }
>
> if '\a' is not mapped to any value? Let c (and therefore i)
> unspecified? Or what?

It's implementation-defined, not unspecified.

Who said anything about it not being mapped to any value? He only said
that it wasn't mapped to any particular value. He even said "The value
... is nobody's business", which clearly implies it has one.
---
[ 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:
> > Pete Becker <petebecker@acm.org> writes:
> > >       2. "You idiot, of course newline means start a new line."
> > >
> > > Now, I suspect that most folks would lean strongly toward 2.
> >
> > Yes, but not on the grounds of conformance to the standard.  It's QoI.
>
> No, on the grounds of conformance, unless you are willing to ignore the
> half page of text that describes what the effect of an escape sequence
> is supposed to be. You have to look at the entire standard, not just the
> parts that support your position.

I should say the same to you.  All the text that supports your
position is subordinate to "are intended to", not "shall".  Do you
deny this?  If not, how do you maintain that that text is normative?


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              ]

"Greg Brewer" <nospam.greg@brewer.net> writes:
> Paul Jarc <prj@po.cwru.edu> wrote in message
> news:m3hfknewss.fsf@multivac.student.cwru.edu...
> > "Greg Brewer" <nospam.greg@brewer.net> writes:
> > > Pete Becker <petebecker@acm.org> wrote in message
> > > news:37E7E53E.AF6C7667@acm.org...
> > > > If you write a string containing \t to stdout and the result is
> > > > that the output position moves to the top of the screen without
> > > > erasing the text that was already on the screen you're entitled to
> > > > complain, and insist that your compiler vendor make it work right.
> > >
> > > Huh!  So if I write a string containing \t to a file then go to the DOS
> > > prompt and use type to display that file and it behaves as you just
> > > described, I should call Inprise and complain?
> >
> > No, the standard can't do anything about what happens when the
> > contents of your file, generated from a C program, are presented to a
> > display device from outside a C program.  The flaw in Pete's argument
> > is somewhere else.
>
> I disagree; that is precisely the flaw in the argument!  He is saying that
> is I send an output string to a device and it doesn't do what it is supposed
> to do then that is the compiler's fault.

1. The standard doesn't differentiate (much) between compiler, linker,
   library, etc.  There is only "the implementation".  I suspect Pete
   meant it's the implementation (vendor)'s fault, and happened to
   call the implementation "the compiler", which is not uncommon,
   though imprecise.
2. Your previous message talked about saving \t to a file from a C
   program, and sending that to a display device from outside a C
   program.  This is different from sending it directly, and that's
   all I was picking on.  (While the handling is typically done at a
   lower level, it could be done by stdio directly.)


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 J. Littleboy" <davidjl@gol.com> writes:
> Pete Becker wrote in message <37E800AF.71C3EF8C@acm.org>...
> >Sure it does. The C standard doesn't say that the execution character
> >set has to be some pre-existing standard character set.
>
> The C++ standard certainly implies this, i.e. that there is an execution
> character set in existence at compile time. It would be pretty dizzy for it
> to be otherwise.

There has to be some character set, yes, but not necessarily a
standard one.  It need not be implemented or described anywhere else
at all.

> >So saying that \e must be the escape character in the execution
> >character set is simply stating a truism. Whatever \e is translated
> >to is, ipso facto, the escape character in the execution character
> >set.
>
> Which is exactly what everyone wants.

Pete's saying that, for example, an implementor could map \e to, say,
ACK on an otherwise normal ASCII system, and that would mean that ACK
is this character set's escape character, as far as the C standard is
concerned.  He's right, and this is not what everyone wants.  But it
also wouldn't ever happen, at least not in the form I've described.

> I'd be seriously surprised if the C standard, despite defining the standard
> behavior of these characters, implies or requires that \t be turned into
> anything other than HT in the execution character set.

The C standard doesn't say "\t will be the execution character set's
HT character", because the standard can't know whether the execution
character set has a character with that name, without restricting the
set of character sets that can be used.  (Nor can the C++ standard.)
The value that \t is mapped to presumeably has some name, but there's
no need or use for specifying it in the C or C++ standards.

> The language represents data and outputs it to libraries, devices
> whatever, which in turn interpret that data.

The standard generally doesn't talk about the language, library,
etc. as separate entities.  The implementation as a whole, which
probably consists of components from vendors who don't have anything
to do with each other, is what's required to behave as the standard
describes.

> Saying anything other than \t translates to the execution character
> set code that corresponds to HT is meaningless.

Saying even that is overly restrictive, since a character set need not
have the notion of tabulation.


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              ]

In article <37E7D66E.8DF0C42D@ix.netcom.com>, Paul D. DeRocco
<pderocco@ix.netcom.com> writes
>But if I turn out to be wrong about that, then \e must OBVIOUSLY
>produce the escape character for that character set if there is one, or
>generate an error message otherwise.

If \e were part of the standard I do not think it would be allowed to
produce a diagnostic.


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ 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> wrote:

> It's simply because I'm not willing to ignore words that appear as
> normative text in the standard. If you see a conflict between those
> words and other words in the standard then the solution is to figure out
> a meaning that accomodates both sets of words, not to pick the one you
> like better and declare it the winner.

The normative text descibing the alphabetic escape sequences is:

 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.

(5.2.2, para 3, C9X draft dated 1998-08-03.)

The waffle preceding that describes intent only, and imposes no
requirements.

As far as I can see, `\e' works quite well as a sequence producing a
unique implementation-defined value which can be stored in a single
*char* object.

[I'm just addressing the specific point raised above.  I honestly
couldn't care whether `\e' is added or not.]

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

In article <37E6EC0A.40DDF311@acm.org>,
 Pete Becker <petebecker@acm.org> writes:
> And what is the "intended behavior" of \e?

Unspecified behaviour.

> The C standard talks about intended behavior, which is more than anyone
> has been willing to do with regard to \e. Note that saying that it
> represents the escape character in the execution character set says
> nothing about behavior, only implementation.

> What should the standard say about this that it doesn't currently say?
> For those who haven't bothered to read the standard, it says that the
> behavior of \e is undefined, i.e. the standard does not impose any

It could say that \e must produce a unique implementation-defined value
that fits into a char.

--
Jan
---
[ 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:
>
> Greg Brewer wrote:
[...]
>
> So the reason for having \e is to save you from having to look up what
> the ASCII code for ESC? Well, there are a bunch more ASCII codes out
> there, too. Are they also candidates for adoption into the C standard?
> If so, what do we do for the poor EBCDIC folks?

As I've pointed out previously, the EBCDIC character set contains
all 32 of the ASCII control characters, including ESC.  (Plus 32 more
control codes that have no ASCII equivalents.)

But we're not talking about defining all 32 ASCII control codes in
ISO C, but only one: '\e'.

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

Christopher Eltschka wrote:
>
> Pete Becker wrote:
> >
> > Christopher Eltschka wrote:
> > >
> > > Pete Becker wrote:
> > > >
> > > > Hyman Rosen wrote:
> > > > >
> > > > > Pete Becker <petebecker@acm.org> writes:
> > > > > > I've been reading the C standard. Too bad the C++ standard screwed it
> > > > > > up. <g> So what do you take this to mean if the platform's character set
> > > > > > does not define NL, HT, VT, etc.?
> > > > >
> > > > > I don't take it to mean anything. Presumably the implementation on such
> > > > > a platform would ascribe some meaning to them.
> > > >
> > > > Well, you can't say both that it doesn't mean anything and that the
> > > > implementation is free to do whatever it wants. Either it's
> > > > implementation-specific or it isn't. Choose one. <g>
> > > >
> > > > >
> > > > > > Defined as what? That is, what should the implementation do if there is
> > > > > > no character whose name is ESC?
> > > > >
> > > > > The same thing it does when there is no character whose name is BEL :-)
> > > >
> > > > The C standard says: "\a (alert) Produces an audible or visual alert."
> > > >
> > > > > Since the Standard didn't see fit to further specify the behavior, I
> > > > > don't either. At worst, the implementation would just assign \e to be
> > > > > some arbitrary control character, or a printing character outside of
> > > > > the usual 96.
> > > > >
> > > >
> > > > So you'd find it acceptable for \e to be mapped, for example, to \a, and
> > > > produce an alert, and then to display the rest of the escape sequence as
> > > > ordinary characters?
> > >
> > > As acceptable as I find it for \t being two thousand spaces,
> > > \v being two hundred lines and \a putting an "alert" dialog
> > > box onto the screen.
> >
> > The first two are, of course silly. And I assume they were made up, for
> > dramatic effect. The last one isn't all that unreasonable, depending on
> > the particular system.
> >
> > >
> > > I'd expect implementors to do something reasonable where
> > > possible. So for purely ASCII systems, I'd expect \e just
> > > to map to \x1B, just as I expect \a to map to \x07.
> >
> > Why should \a map to some particular value? The standard describes what
> > effect it has. The value that's used to get that effect is noboby's
> > business.
>
> Then how do you compile
>
> #include <iostream>
>
> int main()
> {
>   char c = '\a';
>   int i = c;
>   std::cout << i << std::endl;
> }
>
> if '\a' is not mapped to any value? Let c (and therefore i)
> unspecified? Or what?

As the C standard says, it is mapped to an implementation-defined value.

> '\a' is a _character_ which, if output, is intended to have a
> certain effect (indeed, generally this is only true for some
> output targets - you won't expect outputting '\a' to a disk
> file resulting in a beep, although this would AFAIK be allowed
> as well).
> The fact that there might be an additional mapping on
> output (like \n to \r\n on DOS) is irrelevant to that.
> \n is mapped to exactly one character (\0x0A on ASCII,
> although even that isn't really demanded by the standard).
> On output, it may be re-mapped to \r\n, to \r, or
> interpreted as "++line_no; col_no=0; if (line_no>max_line)
> { scroll(1); --line_no; }", or translated into
> \x1Bcr,lf;, or whatever, but in the program it is mapped to
> one single code point (which is observable in a conforming
> program).

Right. I'm not sure at this point if you're agreeing with me or
disagreeing. Yes, every escape character sequence is compiled to a
value. The code that writes such values to an output device is
responsible for making sure that those values have the appropriate
effect. If sending the value to the device will do it, fine. If not,
then do something else.

>
> >
> > > Of course
> > > an implementation could as well map \a to \x80 (and produce
> > > an alert on that), however I'd not like that on ASCII systems
> > > where a BEL character (\x07) is already defined.
> > >
> > > On systems where the character set doesn't include an escape
> > > character, one reasonable action would be to ignore that
> > > character completely. Another reasonable action would be to
> > > interpret is as if it were an escape character, and produce
> > > f.ex. an VT100 compatible behaviour. Another reasonable
> > > behaviour would be to just make \e map to some printable
> > > character.
> >
> > So what's wrong with the current state of affairs? If you use \e as a
> > character constant the behavior of the resulting program is undefined.
> > If your compiler vendor tells you what effect \e has you can use it, and
> > if they don't, you can't.
>
> The point is that while you don't know for sure what
>
>   std::cout << '\a';
>
> results in, you at least know that it will compile, and
> you can _expect_ it to generate an alert (although you can't
> really know it).
>
> If you write
>
>   std::cout << "\e[2J";
>
> it might not even compile, and even if it does, you can only
> guess that \e maps to \x1B on at least most ASCII systems
> where it compiles, and to \x26 on most EBCDIC systems.
>
> That is, even though the standard does not make any strict
> guarantees about '\a', by demanding the sequence to be compiled
> and giving an _intent_, it makes programs using that far more
> portable, since every sane implementor will try to follow the
> intent as much as possible.
>

So what is the intent of \e? What should a sane implementor do with it?
Emulate an ANSI drive if one isn't present?

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

Christopher Eltschka wrote:
>
> Pete Becker wrote:
>
> > Once again, condensed from the C standard:
> >
> >     \a (alert) Produces an audible or visible alert.
> >     \b (backspace) Moves the actrive position to the previous
> >        position on the current line.
> >     ...
>
>       \e (escape) allow a different interpretation of following
>           characters.

Jeez.  Let's just make it simple, since we can't agree on anything
complicated:

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

Happy?

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

> Which C implementor has actually done *anything* about those codes, beyond
> choosing which execution set characters to convert them into?

To my knowledge, all implementations of C on the Macintosh attempt to
provide a hosted implementation, even though the Macintosh has no
console interface.  They all have to write code which interprets the
control characters in the standard.

                                                   --Lisa Lippincott
---
[ 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:
>
>     cout << "\eH";
>
> [...]  I
> might write such a thing if I knew that standard output was connected to an
> ANSI display, and I wanted to clear the screen and home the cursor.

Actually, according to ISO 6429, that's HTS (Character tabulation set),
which sets a horizontal tab position.  Perhaps you meant

    cout << "\e[H\e[2J";

to home the cursor with CUP (Cursor position) and then erase the
display using ED (Erase in page)?  Although I've never seen a terminal
for which "\f" wouldn't do the same thing more succinctly.

     - John Hauser
---
[ 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              ]

Kai Henningsen wrote:
>
> Which C implementor has actually done *anything* about those codes, beyond
> choosing which execution set characters to convert them into?

The runtime library for every C compiler for DOS translates \n into two
characters on output. Otherwise you end up with subsequent lines
overwriting previous ones, because DOS requires both a carriage return
and a linefeed to start a new 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              ]

David R Tribble wrote:
>=20
> Pete Becker wrote:
> >
> > Hyman Rosen wrote:
> > > In addition, 2.2=81=B63 would need to have "escape" added to the li=
st 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 ad=
d
> > > it.
> >
> > Defined as what? That is, what should the implementation do if there
> > is no character whose name is ESC?
>=20
> Um, something similar to what they would do of if there is no
> character named NL?
>=20

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

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

Kai Henningsen wrote:
>
> petebecker@acm.org (Pete Becker)  wrote on 21.09.99 in <37E6EC0A.40DDF311@acm.org>:
>
> > The C standard talks about intended behavior, which is more than anyone
> > has been willing to do with regard to \e.
>
> Untrue.
>

Sigh. Once again, please state the effect on the display of including
the character \e in a character string that is displayed with printf.
Here's a start:

#include <stdio.h>

int main()
{
printf("abcd\efg\n");
return 0;
}

We know what 'a', 'b', 'c', 'd', 'f', 'g', and '\n' should do. What is
the effect of the \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              ]

Nick Maclaren wrote:
>
> In article <37E7E0B8.1FF305C5@acm.org>,
> Pete Becker  <petebecker@acm.org> wrote:
> >
> >Nick Maclaren wrote:
> >>
> >> No more than '\v'.  As I have posted before, there is a perfectly good,
> >> portable specification of '\e', which is precisely the one specified
> >> in ASCII.
> >>
> >>     Writing a '\e' character to a text stream has an implementation-
> >>     defined effect.
> >>
> >> Please note that this is slightly MORE precise than the equivalent
> >> specification of '\v' - and I speak as a user, third-party application
> >> developer and implementor of C.
> >
> >I just don't see it. From the perspective of writing reasonably portable
> >code, a character cosntant whose only constraint is that it "has an
> >implementation-defined effect" cannot be used. A character constant
> >whose effect is to "[move] the active position to the initial position
> >of the next vertical tabulation position" is much more useful. If it
> >doesn't do that with the compiler that you're using, complain to the
> >vendor. They may have a good reason for not doing it on that particular
> >platform, which is why the standard is written the way it is, but at
> >least you have a shot at being able to use it.
>
> You have missed two points:
>
>     1) What IS "the next vertical tabulation position" in a context
> where vertical tabulation is not defined?  Yes, I have implemented
> C in such a context.

e.g. a one-line display. That's one of the "good reasons" that I
mentioned, and that's why the standard doesn't say that the
implementation must unconditionally do this. That's not the same thing
as saying nothing about it.

>
>     2) There are many aspects of C that are completely unspecified
> or even undefined, but are still regarded as useful (well, vaguely.)
> I/O errors and signal handling, to name but two.
>

But the behavior of escape sequences is not "completely unspecified or
even undefined." It's right there in the standard, outside of any notes,
examples, and footnotes. It's normative text, and should not be ignored.

--
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:
>
> Pete Becker wrote in message <37E800AF.71C3EF8C@acm.org>...
>
> >Sure it does. The C standard doesn't say that the execution character
> >set has to be some pre-existing standard character set.
>
> The C++ standard certainly implies this, i.e. that there is an execution
> character set in existence at compile time. It would be pretty dizzy for it
> to be otherwise.

Note the word "standard". The execution character set is simply the set
of characters that valid characters in the source code get translated to
when they need to appear in the executable file. When a compiler targets
a platform that uses ASCII the executable character set is a subset of
ASCII. There are ASCII characters that have no counterpart in the source
character set, and are, therefore, not in the execution character set.

>
> > The execution
> >character set is simply the set of characters that the compiler
> >translates characters into when they are part of the executable code. So
> >saying that \e must be the escape character in the execution character
> >set is simply stating a truism. Whatever \e is translated to is, ipso
> >facto, the escape character in the execution character set.
>
> Which is exactly what everyone wants.

No, they want it to be some particular character, depending on the
target system, i.e. the "escape character." I suspect they would be very
unhappy if \e were translated into 09 on an ASCII system, because then
it would tend to cause display devices to move to the next tab stop.

>
> >It's usually convenient to translate \t into a value that the display
> >driver will recognize as a tab character, but that is not required by
> >the standard. What's required (or recommended, if you insist) is that a
> >C string that contains the escape sequence \t have the effect of moving
> >the cursor position to the next tab stop when that character is
> >encountered.
>
> In terms of the C++ standard this is dead wrong. Escape sequences are
> character literals that correspond to exactly one character in the execution
> character set. If the execution character set has an HT character, that's
> what you get.

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

> The effect of that character (or of what \t gets translated
> into) on the device it is shipped to _can't_ be specified at the language
> level, since a single string could be output to multiple devices and
> libraries, all of which handle tab differently.

But the standard doesn't require that \t be shipped to an output device.
It describes the effect of using \t in a string that gets written to an
output stream. On the way out the library code can do this:

switch(ch)
{
case '\t':
 put(' ');
 while(col % tab != 0)
  put(' ');
 break;
....
default:
 put(ch);
}

That's how you do tabs when you have an output device that doesn't
support them.

>
> I'd be seriously surprised if the C standard, despite defining the standard
> behavior of these characters, implies or requires that \t be turned into
> anything other than HT in the execution character set.
>
> >> You're consistently confusing what the compiler does with what the
> library,
> >> device driver or device does.
> >
> >No, I'm not at all confused about these. I've been writing systems code
> >for ten years.
>
> And gotten yourself confused as to what the language does and what
> systems do, apparently. The language represents data and outputs it to
> libraries, devices whatever, which in turn interpret that data. The language
> definition has no right to legislate what a given character will do. That's
> the domain of the character set standard. Since most character set standards
> include an HT equivalent, \t is a convenience.
>
> (The complication here is that: the C standard limits escape sequences to
> characters that correspond to "actions on display devices". Still, the C
> standard still requires that a single escape sequence corresponds to a
> single character in the string, so the bottom line is that those definitions
> are nothing more than a wish list, since they are not binding on the
> standards for the various execution character sets and devices that might
> actually be used.)
>
> > Ultimately an application programmer's concern is that
> >the characters be displayed in the appropriate way.
>
> The programmer's concern is that she is able to represent the bits
> that she wants to represent. Whatever the C standard says, the bottom line
> is that what the target of a string output by a program does is defined by
> that target, not the C standard. Saying anything other than \t translates to
> the execution character set code that corresponds to HT is meaningless.

Not at all, as the code snippet above demonstrates. One of the issues
when implementing the standard library is making sure that the behavior
that's required by the standard is actually what happens when the
program is run, and that depends heavily on the library writer's
understanding of the C standard and the platform that the compiler is
targeting. For example, under DOS there is no single character that you
can send to the display that will create the effect of a newline, i.e.
moving the output position to the beginning of the next line. So when
the library sees that the character '\n' is being written to a text
stream it replaces it with two characters, a carriage return and a line
feed.

>
> >The place where the
> >compiler and the OS meet is the runtime library. If the characters that
> >the compiler generates aren't getting out on the display correctly the
> >place to fix it is usually in the library. So, for example, that's where
> >the single character represented by '\n' gets translated into the two
> >characters CR and LF for a DOS system.
>
> But this is (almost) right (there's no such character as NL, \n _is_ LF),

Right, there's no ASCII character NL. Not that anybody said there was...

But in C \n is new line, because that's what the C standard says:

 \n (new line) Moves the active position, etc.

Under UNIX it is usually implemented as ASCII LF, because that avoids
having to do any translation on output. On a Mac, if I remember
correctly, it's ASCII CR, because that's what the Mac treats as the
character that starts a new line. And under DOS there is no single
character that produces a new line, so it doesn't matter what the code
is, because the library has to translate it into a carriage return and a
line feed. It's usually implemented with LF, but there's no technical
reason for doing it that way.

Don't confuse what C compilers for UNIX do with what the C standard
requires. The standard shows its UNIX heritage in many places, but it
does not require that escape characer sequences be translated in the
same way that UNIX compilers traditionally handled them.

--
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:
>
> Pete Becker wrote in message <37E834B4.623C04E7@acm.org>...
> >
> >Greg Brewer wrote:
> >> [Stuff on sending ESC to various places]
> >
> >Yup. But ANSI C doesn't give you any promise that this will work, even
> >if the driver is present. The language definiton only talks about the
> >display semantics of printable characters, and '\033' is not a printable
> >character, so when you send it to puts you're outside the definition of
> >valid C. Of course, the nihilits here would reply that there are no
> >defined semantics for any character output to any device, that there's
> >only a statement of intent. But there's not even a statement of intent
> >for non-printable characters. If it works, fine. But don't count on it.
>
> I think we are finally getting down to the real basics of the issue here.
> The question is "what does it mean to be a character in a character string?"
> If I read you correctly, essentially what you are saying is that C/C++
> should _not_ support code points in execution character sets that are not
> related to doing things to displays.

No, I'm saying that the C standard (I'm avoiding the C++ standard
because I think it's seriously flawed here) does not define the
semantics of writing non-printable characters that are also not escape
sequence characters to a display device. (Phew, if you can parse that
you must be as tired as I am). That is, section 2.2.2 (old ANSI version,
if you've got the ISO standard it's somewhere else) talks about "writing
a printable character (as defined by the isprint function) to a display
device" and about the effects of "alphabetic escape sequences
representing nongraphic characters" (i.e. \a, \b, \f, \n, \r, \t, \v).
It says nothing about the effect of writing any other characters. Note
that this is entirely in reference to the source character set, not the
execution character set.

>
> I submit that this is an anachronism, and the wrong thing for these
> languages. There are a lot of other things in the world than just display
> devices, and that restriction makes C/C++ a less expressive language for
> people writing to those other things. For example, some folks (e.g.
> ISO-2022) use SI and SO. Any program that spits out (or reads in) ISO-2022
> would be far clearer if \i and \o generated those code points.
>
> In other words, if a character set standard that's used widely defines a
> name for a particular code point that is unambiguous, and that named code
> point is used, then it may be useful for C/C++ to support an escape sequence
> for that named code point. (For all the good reasons that names are better
> than magic constants.) Which such code points are worth supporting is, of
> course, open for argument.

It's not clear to me what's meant here by "support." If your compiler
vendor tells you that using \i in a character string that you send to an
output device will result in the ASCII character SI being sent to the
device, that's fine. Use it. It's up to your vendor to live up to their
promise. The issue for the standard, though, is whether that something
along that line should be required of every vendor, and, if so, how to
describe it.

>
> Fortunately, the C++ standard eschews all mention of what happens to
> characters once they leave your program, and this is only a glitch in the
> wording of the C standard.
>

Ah, there we have it: no portable semantics for writing to any display
device. That page describing what happens when you write to a display
device was just an accident, and the folks who let it slip through into
the standard are hanging their heads in shame. Unfortunately, the view
among those folks is just the opposite: they express regret that it
wasn't possible to put stronger behavioral requirements here, but they
couldn't figure out how to say it without overly constraining
implementations.

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

Al Stevens wrote:
>
> Pete Becker wrote in message <37E7E0B8.1FF305C5@acm.org>...
>
> >I just don't see it.
>
> That part is true. <g>
>
> >From the perspective of writing reasonably portable
> >code, a character cosntant whose only constraint is that it "has an
> >implementation-defined effect" cannot be used.
>
> "Reasonably portable code" is not an issue when you are writing device- or
> protocol-specific software.

In which case you're also probably not writing standard-conforming code,
since one of the major goals of the standard is to make porting easier.

>
> >A character constant
> >whose effect is to "[move] the active position to the initial position
> >of the next vertical tabulation position" is much more useful. If it
> >doesn't do that with the compiler that you're using, complain to the
> >vendor.
>
> Which vendor?

The compiler vendor.

> The compiler should simply send whatever '\v' is on that
> platform's character set to the printer (or driver). Are the compiler and
> the library and the drivers and the printers all necessarily provided by the
> same vendor?
>

The compiler and its runtime library come from the same vendor, and that
combination is what the C standard concerns itself with. The resulting
executable code is run on some hardware and software combination, which
is what the compiler vendor must be concerned with. If the compiler and
library in combination produce executable code that doesn't perform
correctly according to the standard, then they don't conform. Usually
the place to fix this is in the library -- that's the easiest place to
do the impedance matching between the strict requirements of the C
standard (\n must be only one character) and the often different
requirements of the platform (DOS requires both a carriage return and a
line feed to start a new 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              ]

Al Stevens wrote:
>
> Pete Becker wrote in message <37E7FD5A.EE264133@acm.org>...
> >
> >Al Stevens wrote:
> >> The appropriate place to be sending /e to a
> >> printer is from a program at some level in the hierarchy--not necessarily
> >> the application and not necessarily the device driver--that knows
> >> specifically which printer it is dealing with and, presumably, which
> >> character set. This is not a language issue.
> >>
> >
> >Fine: you've defined away the question. Since you never need to send \e,
> >you don't need a way of representing it.
>
> If you are addressing me only as an applications programmer, that is
> correct. But might I have another hat to wear?

No, as everyone keeps telling me, the runtime library doesn't have to do
anything here except pass the codes on to the operating system. <g>

--
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:
>
> "Greg Brewer" <nospam.greg@brewer.net> writes:
> > Pete Becker <petebecker@acm.org> wrote in message
> > news:37E7E27C.D4B61DC7@acm.org...
> > > Here's a list of the things that you can't do with such a string:
> > >
> > > 1. write it to any device other than a disk (in particular you can't
> > > display it on the screen)
> > > 2. write it to disk as part of a text file
> > > 3. read it from any device other than a disk
> > >
> > > It doesn't sound very useful.
> >
> > I agree with your list of cans; can't say the same with your list of can'ts.
>
> Those things can certainly be done, but not portably, which was Pete's
> point.  \v etc. are no more portable according to the standard, but he
> refuses to accept this.
>

I refuse to accept it because it isn't so. The words that describe the
effect of the character escape sequences are not in a note, they are not
in an example, they are not in a footnote. They are normative text, and
you cannot simply ignore them.

--
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:
>
> Pete Becker wrote:
> >
> > Please give an example of code using \e, and based on this definition,
> > explain what the behavior of the program will be.
>
>     cout << "\eH";
>
> This will write an escape and a capital H to the standard output stream. I
> might write such a thing if I knew that standard output was connected to an
> ANSI display, and I wanted to clear the screen and home the cursor. If I
> didn't know what standard output was connected to, then I wouldn't be able
> to do this, but in real life I often do know, and I often do this.
>

"write an escape and a capital H" doesn't say anything that the code
itself doesn't say. Compare it to what the C standard says about \n:

 \n (new line) Moves the active position to the initial position of the
next line.

So a description along those lines would be something like "clears the
screen and moves the active position to the initial position of the top
line of the display." Of course, since this behavior depends on having a
driver present, it might better be worded conditionally: "if the display
device responds to "\eH" by clearing the screen, clears the screen.
Otherwise it does something else."

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

jcoffin@taeus.com (Jerry Coffin) writes:
> In addition, you've still got the problem that there's not much you
> can reasonably DO with this, even if you're sure the correct
> translation (whatever that happens to be) takes place.

*You* are not doing anything with it, but the device that you send it to does.


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

Greg Brewer wrote:
>
> Pete Becker <petebecker@acm.org> wrote in message
> news:37E7E27C.D4B61DC7@acm.org...
> >
> > > void bar(const char *);
> > > void foo(void)
> > > {
> > >    const char *output = "ABC\ecba";
> > >    bar(output);
> > > }
> > My other response was a bit brusque, so here's an expanded version.
> > Here's a list of the things that it looks like you can do portably with
> > a string containing \e under this definition:
> >
> > 1. you can pass it to strlen, and \e will count as one character
> > 2. you can search for \e and replace the character that you find (which
> > will compare
> > equal to \e, but may also compare equal to some other character)
> > 3. you can write the string to a binary file, read that file back in
> > (with an executable
> > produced by the same compiler), and expect to find \e in the same place
> >
> > Here's a list of the things that you can't do with such a string:
> >
> > 1. write it to any device other than a disk (in particular you can't
> > display it on the screen)
> > 2. write it to disk as part of a text file
> > 3. read it from any device other than a disk
> >
> > It doesn't sound very useful.
>
> I agree with your list of cans; can't say the same with your list of can'ts.
> 1)  In my DOS programs, I send such strings to printers all the time.
> I have sent such strings to the display in the past when I was programming in
> QuickC and its library didn't define a clearscreen function.  Ansi.sys
> defines an escape sequence that clears the screen so I sent it.

Yup. But ANSI C doesn't give you any promise that this will work, even
if the driver is present. The language definiton only talks about the
display semantics of printable characters, and '\033' is not a printable
character, so when you send it to puts you're outside the definition of
valid C. Of course, the nihilits here would reply that there are no
defined semantics for any character output to any device, that there's
only a statement of intent. But there's not even a statement of intent
for non-printable characters. If it works, fine. But don't count on it.

>
> 2) Again, I have done it alot.  No big deal.  I'm not sure why you would
> think this could possibly be a problem.

It often works. That doesn't mean that the standard requires it to work.

>
> 3)  Can't say I've ever had the occassion to need to read it from any other
> device than a disk.  I take that back, the keyboard produces an escape
> character and I have read that back in my DOS days.  Oh, and I once tried to
> write a terminal emulation program that read escape characters -- along with
> lots of others -- from the serial port.  I really don't see what relevance
> the lack of sources for receiving \e has on its usefulness as a coding
> standard.
>

There's a well-defined set of characters that can be read from input
devices. Most control characters are not in that set. Your definition
does not put \e into that set.

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

Greg Brewer wrote:
>
> Pete Becker <petebecker@acm.org> wrote in message
> news:37E7E53E.AF6C7667@acm.org...
> > Sigh. Someone has to decide, and there has to be code somewhere to deal
> > with the character that says "move to the next tab stop." If you write a
> > string containing \t to stdout and the result is that the output
> > position moves to the top of the screen without erasing the text that
> > was already on the screen you're entitled to complain, and insist that
> > your compiler vendor make it work right.
>
> Huh!  So if I write a string containing \t to a file then go to the DOS
> prompt and use type to display that file and it behaves as you just
> described, I should call Inprise and complain?
>

No, the requirements of the C standard only apply to a C program, not to
DOS commands.

--
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> wrote in message
news:37E7FCAB.2642508E@acm.org...
> > You are wrong.  A printer looking for ASCII escape characters will react
> > properly to a valid EBCDIC string containing an EBCDIC escape character.
It
> > will react properly because it will receive ASCII characters including
an
> > ASCII escape character.   Just as it will react properly when an EBCDIC
'A'
> > is sent to the printer; it will receive an ASCII 'A'.
> Seriously, you seem to be talking about some sort of driver that
> translates EBCDIC to ASCII. That makes it work, of course, but it
> doesn't change what the printer sees. If you're sending the wrong
> characters to the printer you have to do something to fix them or it
> won't work.

Actually, I'm talking about a piece of hardware called a protocol converter.
And yes, it does change what the printer sees.  IBM only supports IBM
printers -- at least back when I worked in that environment -- and EBCDIC is
what is coming down the coax.  Unless you change it, you will not get
anything legable on the paper.  Sending the right character is the point.
If you want to send the right escape character to an Ascii printer attached
to an IBM mainframe through a protocol converted, you had better be sending
an EBCDIC escape.

Greg Brewer


[ 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 <37E7FCAB.2642508E@acm.org>,
 Pete Becker <petebecker@acm.org> writes:
> Seriously, you seem to be talking about some sort of driver that
> translates EBCDIC to ASCII. That makes it work, of course, but it

How do you expect a

  printf ("Hello, world!\n");

to work if it get's displayed on an ASCII printer that is attached to a
EBCDIC machine?

If that printf works, you may also expect that

  printf ("\e");

let's the printer see an ASCII ESC, not an EBCDIC ESC.

On the other hand, as Jerry Coffin already pointed out, it is more
likely that all hardware looks like typical EBCDIC hardware from the
viewpoint of a C application on an EBCDIC machine. And that can include
conversion of complete escape sequences and not just single escape
characters, or even more invasive protocol converters.

--
Jan


[ 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:

> "Brian B. McGuinness" wrote:
> >
> > So the simplest solution would be to define '\e' as the ESC character and
> > not worry about what its effect might be on any specific device; let the
> > device driver's designer worry about that.
> >
> > For clarity, we could specify:
> >
> > In ASCII, '\e' = '\x1B'
> > In EBCDIC, '\e' = '\x27'
> > ... (mention any other cases here) ...
> > In other codesets the meaning of '\e' is implementation-dependent.
> >
> > This should be simple enough for any compiler writer to implement and
> > would cause '\e' to have the effect that most people would expect.
> >
>
> When I recompile my printer driver with a compiler that targets EBCDIC
> it would stop working, because the printer is looking for '\033', and \e
> now means something else. I assume that that's not really what "most
> people would expect."

Ok, so in this special case it is necessary to specify the value as '\033'
instead of '\e'.  This is not a big deal, since you have exactly the same
problem with '\t', '\v', etc.  Since the driver is responsible for performing
translations between character sets, one would expect to have to use
explicit numeric constants in this situation.

So far, nobody has made an argument against \e that doesn't apply to
'\t', etc. equally well.  I have defined \e above in a way that clearly
expresses the intent of most people requesting this feature.  This
definition is clear enough for compiler writers to implement it
unambiguously.  For those desiring a statement of intent, retain the
above definition and simply add the statement that this character is
intended to support escape sequences such as ANSI [insert the
appropriate designation here] which control the behavior of output
devices such as monitors and printers.  '\e' has been criticised as
being useless, but one could complain that '\t' is equally useless
since you can specify:

#define TAB '\011'

or

const char TAB='\011';

and use TAB instead of '\t' in C or C++ programs.  The proposed '\e'
character would be used at least as widely (and most likely far more
widely) than the existing '\v'.  Adding this feature does no harm to
existing programs, or to the standard, yet many programmers would
find it convenient.  Moreover, the character sequence '\\', 'e' is easier
to remember than '\\','0','3','3', so there is less of a chance of
introducing bugs by typing the wrong sequence, say '\\','0','3','2'.  No
one would be forced to use this feature; those who didn't like it could
simply omit it from their code.

So arguments against the inclusion of this feature seem to be based
more on a personal sense of aesthetics than on logical objections.

--- Brian



[ 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 thompson <david.thompson@trintech.com> writes:
> Stability is a good thing in a standard, though not the only
> good thing.  I agree the proposed \e would be as adequately
> defined as say \v, but it provides little benefit and the
> alternatives work well enough; it's not worth the trouble.

It provides benefits to people who want to write clear escape
sequences in their code, and it causes absolutely no trouble
for anyone else.


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

petebecker@acm.org (Pete Becker)  wrote on 21.09.99 in <37E6EC0A.40DDF311@acm.org>:

> The C standard talks about intended behavior, which is more than anyone
> has been willing to do with regard to \e.

Untrue.


Kai
--
http://www.westfalen.de/private/khms/
"... by God I *KNOW* what this network is for, and you can't have it."
  - Russ Allbery (rra@stanford.edu)


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

petebecker@acm.org (Pete Becker)  wrote on 19.09.99 in <37E4F17C.2526557D@acm.org>:

> Paul Jarc wrote:
> >
> > Pete Becker <petebecker@acm.org> writes:
> > > Paul Jarc wrote:
> > > > You handle \e however you like, the same as for the others.  You
> > > > aren't *required* to do anything in particular with the others, so why
> > > > do you expect a requirement for \e?
> > >
> > > If someone puts \t into a character string and my code clears the
> > > screen, they're going to complain loudly and justifiably. First, because
> > > it's not what most people expect \t to mean, and second, because the C
> > > standard describes what this ought to do. I'm not convinced that there
> > > is no requirement whatsoever here, but even if there isn't, hiding
> > > behind legalisms is a good way to go bankrupt.
> >
> > All you've said is that it's not commercially viable to surprise the
> > user.  No one said anything to the contrary.  Handle \e the way your
> > users expect it to be handled.  That's what you do for the others.
>
> No, for "the others" I do what the standard says I should do.

You do?

Which C implementor has actually done *anything* about those codes, beyond
choosing which execution set characters to convert them into?

Or did you allude to the fact that the standard actually *doesn't* say
what you should do?

>What
> should I do for \e? Poll users to figure out what they think the
> definition is?

If you're using a variant of ASCII, it has ESC.
If you're using a variant of EBCDIC, it has ESC.
If you're using something exotic, well, I wouldn't know what to do about
the other \x sequences either before investigating.

Kai
--
http://www.westfalen.de/private/khms/
"... by God I *KNOW* what this network is for, and you can't have it."
  - Russ Allbery (rra@stanford.edu)


[ 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:
>
> "Brian B. McGuinness" wrote:
> >
> > "Paul D. DeRocco" wrote:
> >
> > > Why are we making this so difficult? In ASCII there is an ESC character. In
> > > EBCDIC there is an ESC character. I don't believe there are any other
> > > execution character sets, for which anyone will actually write a C++
> > > compiler, that don't have an ESC character. If I'm wrong about this, then
> > > I'd be surprised if this character set I'm as yet unaware of didn't also
> > > have analogous problems with other missing control characters that are
> > > already mentioned in the C++ standard.
> >
> > So the simplest solution would be to define '\e' as the ESC character and
> > not worry about what its effect might be on any specific device; let the
> > device driver's designer worry about that.
> >
> > For clarity, we could specify:
> >
> > In ASCII, '\e' = '\x1B'
> > In EBCDIC, '\e' = '\x27'
> > ... (mention any other cases here) ...
> > In other codesets the meaning of '\e' is implementation-dependent.
> >
> > This should be simple enough for any compiler writer to implement and
> > would cause '\e' to have the effect that most people would expect.
> >
>
> When I recompile my printer driver with a compiler that targets EBCDIC
> it would stop working, because the printer is looking for '\033', and \e
> now means something else. I assume that that's not really what "most
> people would expect."

And if you give an EBCDIC "X" directly to the printer, the printer
will not generate an "X".
Which does _not_ show that '\e' and 'X' don't work, but that
using an ASCII printer on an EBCDIC system requires translating
EBCDIC characters into ASCII characters at some stage - that's
true for X as well as ESC.
If your printer driver outputs _directly_ to the printer, without
an intermediate codeset translation routine, I can tell you
that breaking escape sequences will be the least problem.
Output of a simple X will not work either.
If there's an additional codeset translation put after it,
your printer driver will be able to output "X" and ESC
just as well. However, code using "\x1B" will most probably
fail, since "\x1B" will be interpreted as EBCDIC character and
translated to the corresponding ASCII character.

To conclude:
- Without additional codeset translation, your printer
  driver won't work at all. Using \x1B instead of \e
  won't help much.
- With additional codeset translation, \e will work, but
  \x1B will *not* work (since it's translated to something
  different).


[ 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:
> >
> >
> > On systems where the character set doesn't include an escape
> > character, one reasonable action would be to ignore that
> > character completely. Another reasonable action would be to
> > interpret is as if it were an escape character, and produce
> > f.ex. an VT100 compatible behaviour. Another reasonable
> > behaviour would be to just make \e map to some printable
> > character.
>
> Would you also consider this reasonable for all of the other escape
> characters when the character set doesn't include that character? The
> character set that I have in mind is ASCII, which has no newline
> character.

We have to distinguish between two things:

(1) The escape sequence in the source code is translated into
    a single character (numeric value in the char range)
    of the execution character set
(2) On output, each character is interpreted by the output system
    (where printable charactes are intended to be interpreted in
    a way such that a glyph is produced that commonly is interpreted
    as that character by humans). If possible and sensible, the
    interpretation should follow the intent given in the
    standard.

Now, to your question:

I certainly expect in (1) '\n' to translate to an ASCII
codepoint other than newline, since ASCII doesn't _have_
a newline.
I also expect in (2) the implementor to see that ASCII
has a well defined way to express the intended behaviour,
namely by sending the two characters CR and LF. Therefore
I'd expect the vendor to translate '\n' - whatever codepoint
is made up for it - into CR LF on output.
Now, I'd also expect the implementor to do a reasonable
choice in (1). Now what's reasonable of course is system
dependant; if there's an unused non-ASCII codepoint, I
would find it completely reasonable in isolation to use
that for '\n' (so that the ASCII characters CR and LF
can be used independant of that, if desired). However,
given that there's a widely used variant of ASCII which
uses the ASCII LF character as NL character, the only
reasonable choice I see is to follow that. (There's also
a widely used variant of ASCII that uses the CR character
as NL, but since the \r character description already
fits the CR ASCII character - and should therefore be
used for it -, and since \r and \n have to be different
characters (code points), this option is the only
reasonable.
Also, if all allowed character values are already occupied
(as f.ex. in the IBM PC character sets), it's unreasonable
to use one of them for '\n' (because this way the usage of
the corresponding character would be impossible), so the
only reasonable choice here (i.e. the only not yet
output-mapped character) is LF. This also makes LF a
reasonable choice even on systems where free code points
exist, for compatibility reasons.

Therefore: No, I wouldn't think mapping '\n' to a printable
character in (2) on ASCII would be reasonable (since there's
a standard way to say "new line" in ASCII, although it's not
a single character), and no, I wouldn't think mapping '\n'
to a single character in (1) on ASCII would be reasonable,
since the LF codepoint is better suited.
If all ASCII based systems had a free codepoint and there
were no tradition of using LF as NL, the most reasonable
behaviour on ASCII systems would *not* be to map '\n'
to LF, but to map it to that unused codepoint.

Now to the more general question (not involving ASCII):
Depending on the system and the output capabilities,
it *may* be a reasonable choice.
Think of a one line telegram ticker, where there's no
concept of "new line". Here it could be reasonable to
map '\n' to a character/set of characters to
indicate a new line. A good candidate, if available,
would be the sign commonly printed on return keys.
Maybe the output of \n could even be customizable
(perhaps with escape sequences).
Now if the implementation chooses a single fixed
character not otherwise used in the execution
character set to represent '\n', it's reasonable
to map '\n' directly to that character. If not,
'\n' should be mapped to an unused codepoint,
and translated on output. If there's no unused code
point, there's a tradeoff between eating a code point
for flexibility (which could be brought back through
an escape sequence, though) and hard-coding a single
character.

So to sum up:

On ASCII, mapping '\n' to a printable character is IMHO
not reasonable.
Generally, mapping escape sequences (including '\n')
to a printable character _may_ be reasonable (but
need not to be). It all depends on the system.


[ 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 in message
news:m3hfknewss.fsf@multivac.student.cwru.edu...
> "Greg Brewer" <nospam.greg@brewer.net> writes:
> > Pete Becker <petebecker@acm.org> wrote in message
> > news:37E7E53E.AF6C7667@acm.org...
> > > If you write a string containing \t to stdout and the result is
> > > that the output position moves to the top of the screen without
> > > erasing the text that was already on the screen you're entitled to
> > > complain, and insist that your compiler vendor make it work right.
> >
> > Huh!  So if I write a string containing \t to a file then go to the DOS
> > prompt and use type to display that file and it behaves as you just
> > described, I should call Inprise and complain?
>
> No, the standard can't do anything about what happens when the
> contents of your file, generated from a C program, are presented to a
> display device from outside a C program.  The flaw in Pete's argument
> is somewhere else.

I disagree; that is precisely the flaw in the argument!  He is saying that
is I send an output string to a device and it doesn't do what it is supposed
to do then that is the compiler's fault.  If I send a \t to a library
routine that is supposed to respond by moving the input cursor to the next
input field and it doesn't, that is the library vendor's problem not the
compiler vendor's.  And if I send that same character to standard output and
the display acts as Pete describes that is a problem with either the device
connected to standard output, the device driver for the device, the OS, or
the library routine for writing to standard out.  Although the last in the
list and the compiler vendor are probably one and the same, it is not in
general the compiler vendor's problem unless it can be determined that the
compiler is not substituting an appropriate character for \t.

Greg Brewer


[ 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:
> >
> > Pete Becker wrote:
> > >
> > > Hyman Rosen wrote:
> > > >
> > > > Pete Becker <petebecker@acm.org> writes:
> > > > > I've been reading the C standard. Too bad the C++ standard screwed it
> > > > > up. <g> So what do you take this to mean if the platform's character set
> > > > > does not define NL, HT, VT, etc.?
> > > >
> > > > I don't take it to mean anything. Presumably the implementation on such
> > > > a platform would ascribe some meaning to them.
> > >
> > > Well, you can't say both that it doesn't mean anything and that the
> > > implementation is free to do whatever it wants. Either it's
> > > implementation-specific or it isn't. Choose one. <g>
> > >
> > > >
> > > > > Defined as what? That is, what should the implementation do if there is
> > > > > no character whose name is ESC?
> > > >
> > > > The same thing it does when there is no character whose name is BEL :-)
> > >
> > > The C standard says: "\a (alert) Produces an audible or visual alert."
> > >
> > > > Since the Standard didn't see fit to further specify the behavior, I
> > > > don't either. At worst, the implementation would just assign \e to be
> > > > some arbitrary control character, or a printing character outside of
> > > > the usual 96.
> > > >
> > >
> > > So you'd find it acceptable for \e to be mapped, for example, to \a, and
> > > produce an alert, and then to display the rest of the escape sequence as
> > > ordinary characters?
> >
> > As acceptable as I find it for \t being two thousand spaces,
> > \v being two hundred lines and \a putting an "alert" dialog
> > box onto the screen.
>
> The first two are, of course silly. And I assume they were made up, for
> dramatic effect. The last one isn't all that unreasonable, depending on
> the particular system.
>
> >
> > I'd expect implementors to do something reasonable where
> > possible. So for purely ASCII systems, I'd expect \e just
> > to map to \x1B, just as I expect \a to map to \x07.
>
> Why should \a map to some particular value? The standard describes what
> effect it has. The value that's used to get that effect is noboby's
> business.

Then how do you compile

#include <iostream>

int main()
{
  char c = '\a';
  int i = c;
  std::cout << i << std::endl;
}

if '\a' is not mapped to any value? Let c (and therefore i)
unspecified? Or what?
'\a' is a _character_ which, if output, is intended to have a
certain effect (indeed, generally this is only true for some
output targets - you won't expect outputting '\a' to a disk
file resulting in a beep, although this would AFAIK be allowed
as well).
The fact that there might be an additional mapping on
output (like \n to \r\n on DOS) is irrelevant to that.
\n is mapped to exactly one character (\0x0A on ASCII,
although even that isn't really demanded by the standard).
On output, it may be re-mapped to \r\n, to \r, or
interpreted as "++line_no; col_no=0; if (line_no>max_line)
{ scroll(1); --line_no; }", or translated into
\x1Bcr,lf;, or whatever, but in the program it is mapped to
one single code point (which is observable in a conforming
program).

>
> > Of course
> > an implementation could as well map \a to \x80 (and produce
> > an alert on that), however I'd not like that on ASCII systems
> > where a BEL character (\x07) is already defined.
> >
> > On systems where the character set doesn't include an escape
> > character, one reasonable action would be to ignore that
> > character completely. Another reasonable action would be to
> > interpret is as if it were an escape character, and produce
> > f.ex. an VT100 compatible behaviour. Another reasonable
> > behaviour would be to just make \e map to some printable
> > character.
>
> So what's wrong with the current state of affairs? If you use \e as a
> character constant the behavior of the resulting program is undefined.
> If your compiler vendor tells you what effect \e has you can use it, and
> if they don't, you can't.

The point is that while you don't know for sure what

  std::cout << '\a';

results in, you at least know that it will compile, and
you can _expect_ it to generate an alert (although you can't
really know it).

If you write

  std::cout << "\e[2J";

it might not even compile, and even if it does, you can only
guess that \e maps to \x1B on at least most ASCII systems
where it compiles, and to \x26 on most EBCDIC systems.

That is, even though the standard does not make any strict
guarantees about '\a', by demanding the sequence to be compiled
and giving an _intent_, it makes programs using that far more
portable, since every sane implementor will try to follow the
intent as much as possible.


[ 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:
>
> Al Stevens wrote:
> >
> > Pete Becker wrote
> > >Suppose I'm implementing the standard library on a system whose display
> > >device is mapped to an 80x25 array of 16-bit storage cells that hold
> > >character codes and color codes. I know how to write the code that deals
> > >with \a, \t, \r, \v, etc. What code does this definition (or any other
> > >proposed definition) require me to write to handle \e?
> >
> > It's not an issue for standard library implementors. It's an issue for
> > device and display protocol driver implementors. As a standard library
> > implementor, none of those characters should be your concern.
>
> Sorry, but that display device that I describes is standard out, and
> I've got to write the library code that puts characters out to it.

Well then it's simple: Just make it mean what _you_ think
it should mean. Maybe you'd like it to be VT100 compatible
(that is, programs writing VT100 escape sequences using \e
work as expected), then this fixes the interpretation. But
you could also define it to just select output color by
just using the next two letters as hex number (and ignoring
the escape if they are not hex digits), so \e07 would set
the attribute byte of the following outputted characters
to 7. Or you could decide to ignore \e completely.
That's what ESC is for: Allow to interpret some following
characters in any way you like.

>
> > It's up to a
> > lower level of abstraction (BIOS, ANSI.SYS, curses, custom device driver,
> > whatever) to decide where the next tab is, how to get the cursor to the
> > first column of the next line, and so on, when they see one of those
> > characters in the stream.
>
> No, it's part of the language definition, so as a library implementor
> I'm responsible for making sure that code that uses it acts in a way
> that's consistenet with the requirements of the standard.

And Escape allows you to temporarily escape from that (Well, you
might still be bound by things like VT100).

>
> > "Implementation-defined" means just that. As a standard library implementor,
> > you would do exactly whatever you would now do in the circumstance you
> > described (and given the absense of support for '\e') when (assuming your
> > display is an ASCII device) you write the code that deals with '\x1b'. Which
> > is that you trust the programmers to know what they are doing and pass the
> > characters along to the logical device. Just exactly as you would do with
> > \t, \n, \v, \f, \r, \b.
>
> There is no prescribed value for \t, \n, \v, etc. Their definitions are
> in terms of observable behavior, not values. That's how they differ from
> '\x1b' or '\x07' or any other explicit value. What value should '\e'
> have? If it's '\033' then its utility is that it saves typing two
> characters. Hardly a valid use of all the time that's been spent on this
> thread.

The value should be the value defined as "ESC" in the execution
character set. If the system you're on doesn't define a native
ESC, it's your choice to do a reasonable choice (just as it is
with \a, f.ex.)

What you are obviously missing is that \a does not only
have an intended effect, but is also a regular character
(you can assign it to a char variable, and it has an
integer value you can get by assigning it to int).
The exact value it maps to is, of course, implementation
defined (ASCII systems will use 7, but that's outside the
C/C++ standards).

int i = '\a';

is legal in both C and C++, and it must result in a value.
On ASCII systems I reasonably expect it to result in the
value 7. That's not demanded by the standard, but it's
the reasonable behaviour.


[ 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 <yjYF3.534$F07.59387@newscene.newscene.com>,
Al Stevens <alstevens@midifitz.com> wrote:
>
>Pete Becker wrote in message <37E7E53E.AF6C7667@acm.org>...
>
>>If you write a
>>string containing \t to stdout and the result is that the output
>>position moves to the top of the screen without erasing the text that
>>was already on the screen you're entitled to complain, and insist that
>>your compiler vendor make it work right.
>
>No, no, no, no, no. Not no, but heck, no. Given the following program, what
>piece of code do you think generates the several spaces that display between
>the 'a' and the 'b' on the console? Not the library and certainly not the
>compiler. At least not in a well-designed compiler suite that builds for a
>reasonable console-based target platform. ...

Yes, quite often the library.  Sorry.  The interpretation of control
characters can be done in the language library, in the "device driver"
component of the "operating system" or in the "device".  I have written
run-time systems that interpreted control characters, and had good
reason for doing so.  The language standards quite correctly leave it
unspecified as to which component does what mangling to make the
language I/O model match that of the system and device.

This is completely irrelevant to the point being discussed, of course.
Or would be, if C (and perhaps C++) had not compounded the Unix error
of confusing the control character HT with a sort of alternate space
data character.  That is simply wrong.



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              ]

petebecker@acm.org (Pete Becker)  wrote on 18.09.99 in <37E3C243.6D141DF5@acm.org>:

> Kai Henningsen wrote:
> >
> > petebecker@acm.org (Pete Becker)  wrote on 16.09.99 in
> > <37E0F7C9.9B295B80@acm.org>:

> > > Suppose I'm implementing the standard library on a system whose display
> > > device is mapped to an 80x25 array of 16-bit storage cells that hold
> > > character codes and color codes. I know how to write the code that deals
> > > with \a, \t, \r, \v, etc. What code does this definition (or any other
> > > proposed definition) require me to write to handle \e?
> >
> > You know that?
> >
> > What do you do for \a?
> >
> > What do you do for \t?
> >
> > What do you do for \v?
> >
> > How do you now these things?
> >
>
> Once again, condensed from the C standard:

I know what the standard says; I have it right here.

That wasn't the question.

The question was, in the situation you describe above, what do *you* do?

No weaseling by pointing at the standard, please. Implementation details.

You claimed to know how to write that code; from your spec, I certainly
don't. That is, I could write several completely different and mutually
incompatible implementations of the above spec.

When you show me how you select between these different ways to do it, I
can probably show you how to do the \e part.

Kai
--
http://www.westfalen.de/private/khms/
"... by God I *KNOW* what this network is for, and you can't have it."
  - Russ Allbery (rra@stanford.edu)


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

petebecker@acm.org (Pete Becker)  wrote on 18.09.99 in <37E3C2D8.D95C0E2D@acm.org>:

> Sigh. Yes, that's what it says, and all the rest are mere words that any
> implementor is free to ignore at their peril. The fact is that every
> library implementor on every platform where these operations are
> possible tries to implement what those words say.

It is true that every implementation tries to convert these sequences
according to the expectations of their users.

It is also true that no implementation I know of - not a single one -
tries to do anything at all about the behaviour of these characters, when
output via standard library functions in the direction of a display
device.

That is, your "fact" is false.

Kai
--
http://www.westfalen.de/private/khms/
"... by God I *KNOW* what this network is for, and you can't have it."
  - Russ Allbery (rra@stanford.edu)


[ 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 comp.std.c Nick Maclaren <nmm1@cus.cam.ac.uk> wrote:

> Nor does curses.  It assumes a particular terminal model that may be
> the only one that you use, but is by no means the only one around
> (even today.)  Yes, the curses library is THEORETICALLY a bit more
> portable than the termcap/terminfo one, but in practice it isn't.

not exactly - curses combines known techniques for dealing with odd
corners of termcap/terminfo which most programmers are not inclined
to exploit (so it is indeed a little more portable ;-)

--
Thomas E. Dickey
dickey@clark.net
http://www.clark.net/pub/dickey


[ 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:
> Newline is a special case, and the library guarantees its behavior,
> because it, unlike all the rest of the control characters, is
> absolutely necessary for communicating lines of text among programs.

Any particular library may guarantee it behavior, but I don't believe
the standard does.
That would seem to imply that writing anything to stdout invokes
undefined behavior, since 1. there are no standard-provided means to
determine whether stdout is connected to a display device, 2. whether
a newline is required at the end of the last line is implementation-
defined, and 3. the effect of writing newline to a display device is
undefined.
Of course, the effect of writing even printable characters to a
display device is also expressed only as intent.

> But here's where your argument about the standard requiring certain
> behavior falls apart. If I write a \v to a disk file, I expect that binary
> value to be written to the file. If I write a \a to a disk file, I don't
> expect an audible or visible alert, I expect that binary value to be
> written to the file.

The language about alerts and tabulation positions is talking only
about display devices, not files.

> If the execution character set is ASCII, then \e must produce the
> ASCII escape character.  If it is EBCDIC, then \e must produce the
> EBCDIC escape character.

The standard would almost certainly not require that.  But it would
depend on the wording for \e, which so far has been fluid.  If \e were
treated like the other \ characters, there would certainly be no
requirement.


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              ]

Such confusion; smart folk adamant that the library shouldn't have anything to
do with \e, smart folk claiming that the library *does* need to be involved.
I'll be arguing that the library doesn't need to be involved, and that this is
a difference between \e and other similar chars such as \t and \n.  Hence,
although their conclusion may not win out, the folk who are arguing that the
library needs to be involved are correct to do so, until someone gives a clear
enough definition, in Standardese, of \e which indicates that this is *not* a
run-time issue.  If anyone feels up to the job, read on...

Al Stevens wrote:

> Pete Becker wrote in message <37E7E53E.AF6C7667@acm.org>...
>
> >If you write a
> >string containing \t to stdout and the result is that the output
> >position moves to the top of the screen without erasing the text that
> >was already on the screen you're entitled to complain, and insist that
> >your compiler vendor make it work right.
>
> No, no, no, no, no. Not no, but heck, no. Given the following program, what
> piece of code do you think generates the several spaces that display between
> the 'a' and the 'b' on the console? Not the library and certainly not the
> compiler. At least not in a well-designed compiler suite that builds for a
> reasonable console-based target platform. I repeat, what to do with the
> proposed \e beyond translating it in literals to a value specific to the
> character set is not a language issue. I add that it is not a library issue
> either.
>
> #include <iostream>
> main()
> {
>  std::cout << 'a' << '\t' << 'b' << '\n';
> }
>

Yes, in that code the compiler will have translated the '\t', and call
something like
std::cout::operator <<(char).  The actual 'char' value which gets passed to
this depends on the compiler's knowledge of the environment which is targetted
-- if that environment doesn't support a horizontal tab character then I
suppose (and maybe Pete Becker or other library implementors could comment
here) that its at this level or below that they might intercept their chosen
'\t' char and call some code to move the current output position suitably.  The
library implementor has the additional advantage over a compiler writer that
their code is compiled to run on the execution platform (please!), so they can
safely test in the code if (ch == '\t') and then go do their thing.  The
compiler will map the '\t' in the library source to the same character it will
apply to any other source code, and there will be smiles all round.

So; the compiler maps '\t' to a value of type char, which the runtime library
is responsible for mapping to the action of a horizontal tab.  Granted, in nice
clean systems, passing the character through to the host OS unchanged -- but
not for all.  And "most" systems (in some sense) require the library to get in
the way of '\n' because there's no single byte which can be written to their
console to have the desired effect.

I'd really hope that if I opened a file in "binary" mode that the library would
not be allowed to make any such translation.  I want the codes I send to a
binary stream to get through to wherever they're headed (usually a file or,
outside the domain of the C++ Standard, a socket) exactly as I sent them.  For
text streams, I could accept any translations which the library implementor
found necessary to get \t, \e etc. to work.

The *only* odd thing about \e is that we should explicitly require the library
to leave it the hell alone.  Let the compiler map it to the ESC character which
makes sense on the target platform, and pass that on unchanged.  Now our
friendly library implementor should be happy, as he needs to be *no work at
all* to implement this feature.

I'm no expect in Standardese.  I don't know how to describe the fact that '\e'
should have special meaning only to the compiler and not to the run-time
library.  In fact, I openly acknowledge that couching it in terms of a compiler
is evidently unacceptable if the Standard is to allow for interpreted
implementations.  I would hope that some of you are, however, able to wrap the
appropriate words around this.

Without trying to start a vote, I'd think that this is a reasonable thing to
add to a future C++ standard (though I can't see that I'd ever have a use for
it in my line of work).
1.  It would make one less incompatibility between C and C++.   ("As close as
possible...").
2.  It would make some (probably non-portable) code more readable.
3.  It has clearly-defined semantics.
4.  It would not break any existing code.

The strongest argument among these, to my taste, is number 1.  Why differ from
C in handling of \e if we gain nothing by doing so?

>
> >> Why does it have to have a prescribed value, since, as you said, the
> others
> >> do not?
> >
> >Because that's what's being asked for.
>
> Not in any of the messages I've read here. All that's been asked for is ESC
> just as HT, FF, CR, etc. are supported. Those are not prescribed values.
>
> And with that I will withdraw and give someone else the last word. As
> someone said in another thread, these are issues about which reasonable
> people can disagree. On this one I shall resign my position as president of
> the dead horse molester's society and let someone else take over. <g>

I fear the horse is still twitching... would somebody care to correct my
thoughts as stated above?

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

"Douglas A. Gwyn" wrote:
>
> "Paul D. DeRocco" wrote:
> > One could wish, I suppose, for C escapes for all standard control
> > characters. However, I'm only suggesting \e for ESC because I think
> > it's the only one that doesn't already have a C escape, and that is
> > commonly used. I know I use it a lot.
>
> Well, there is one problem.  Scarcely anyone I know uses ESC
> in *any* form in his C code.  On the few occasions when we
> are programming for "glass TTY" terminals (or emulators),
> we use the curses library, which isolates our application
> from the vagaries of terminal models.  (But more often, we
> use "dumb" text or else bitmap facilities.)  ESC itself has
> no role in portable programming.

What does the curses source code, which I assume is portable, use
for ESC?

-- 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 in message <37E834B4.623C04E7@acm.org>...
>
>Greg Brewer wrote:
>> [Stuff on sending ESC to various places]
>
>Yup. But ANSI C doesn't give you any promise that this will work, even
>if the driver is present. The language definiton only talks about the
>display semantics of printable characters, and '\033' is not a printable
>character, so when you send it to puts you're outside the definition of
>valid C. Of course, the nihilits here would reply that there are no
>defined semantics for any character output to any device, that there's
>only a statement of intent. But there's not even a statement of intent
>for non-printable characters. If it works, fine. But don't count on it.

I think we are finally getting down to the real basics of the issue here.
The question is "what does it mean to be a character in a character string?"
If I read you correctly, essentially what you are saying is that C/C++
should _not_ support code points in execution character sets that are not
related to doing things to displays.

I submit that this is an anachronism, and the wrong thing for these
languages. There are a lot of other things in the world than just display
devices, and that restriction makes C/C++ a less expressive language for
people writing to those other things. For example, some folks (e.g.
ISO-2022) use SI and SO. Any program that spits out (or reads in) ISO-2022
would be far clearer if \i and \o generated those code points.

In other words, if a character set standard that's used widely defines a
name for a particular code point that is unambiguous, and that named code
point is used, then it may be useful for C/C++ to support an escape sequence
for that named code point. (For all the good reasons that names are better
than magic constants.) Which such code points are worth supporting is, of
course, open for argument.

Fortunately, the C++ standard eschews all mention of what happens to
characters once they leave your program, and this is only a glitch in the
wording of the C standard.

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

-- 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 <37E7DFD6.3A09AC3A@acm.org>,
 Pete Becker <petebecker@acm.org> writes:
[intended behaviour of alphabetic escape sequences]
> It's simply because I'm not willing to ignore words that appear as
> normative text in the standard.

Now what?  Every compiler vendor must appear at a commitee's meeting
and swear on the Standard that he really wanted \a to produce an
audible or visible alert?  Or what is the meaning of "normative
intend"?

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

Jerry Coffin <jcoffin@taeus.com> wrote in message
news:MPG.1251b579ddbb53679896d6@news.mindspring.com...
> In article <7s8ohu$2bh7$1@news.hal-pc.org>, nospam.greg@brewer.net
> says...
>
> [ ... ]
>
> > You are wrong.  A printer looking for ASCII escape characters will react
> > properly to a valid EBCDIC string containing an EBCDIC escape character.
It
> > will react properly because it will receive ASCII characters including
an
> > ASCII escape character.   Just as it will react properly when an EBCDIC
'A'
> > is sent to the printer; it will receive an ASCII 'A'.
>
> The question is what it'll really receive.  I'd expect (for example)
> that if you connected (just to pick out random examples) a VT-100 (or
> emulation thereof) to an IBM mainframe, it wouldn't just do a
> character by character translation.  Instead, it'd have something to
> emulate 3270 commands, and translate them to VT-100 commands.  e.g. if
> you send the sequence that clears the screen on a 3270, it'd end up
> clearing the screen on your VT-100.
>
> Unfortunately, I don't see a \e (or whatever) built into the language
> helping this much: you've still got to get complete strings that carry
> out particular commands on a particular device, and those complete
> strings are going to have to be translated to be of any real use, and
> you're going to have to somehow figure out what strings correspond to
> some particular piece of hardware before you can do that.
>
> I suppose it's possible to hard-code these into a program, but offhand
> that seems like just about the single worst possible way to do things.
> While I realize that neither C nor C++ makes an attempt makes much
> attempt at making a programmer do things in the best possible way, I
> DO think it's a bit odd (at best) to standardize something that
> appears useful ONLY in implementing what appears to be the worst
> possible solution to a particular problem.

What is wrong with that!  Let me give you an example from my shop.  We use a
unix minicomputer; but, let us say that we were using an IBM mainframe.  My
company receives charts of natural gas flow, digitizes them, and information
on the results are then printed on the chart using the same kind of printer
banks use to do deposit slips.  To perform this operation, we have Wyse
terminals with an attached printer.  In order to print to the attached
printer, it is necessary to send an escape sequence to the terminal and a
second to stop printing.  If we wished to perform the same operation from an
IBM mainframe, we would have to recompile our integration program on the
mainframe and edit all the escape sequences because they are sending the
wrong sequence.

If the program identified the escapes sequences with \e then the
recompilation would be a snap.  Just buy some protocol converters to attach
the Wyse terminals and we would be all set.

Can you still maintain that this is the worst solution to a particular
problem?

Greg Brewer
---
[ 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:
>
> Jan Echternach wrote:
> >
> > In article <37E3C668.E219EA07@acm.org>,
> >         Pete Becker <petebecker@acm.org> writes:
> > > This is a description, not a specification. That is, an implementation
> > > that interpreted the first character following \e as a request to reboot
> > > the system satisfies these requirements. I suspect that folks have
> > > something a little narrower in mind.
> >
> > And the specification of \v only specifies "intended" behaviour. And even
> > that looks rather undefined, from 1999-01-18 draft of C9x:
> >
> > | 5.2.2 Character display semantics
> > |
> > | 2 Alphabetic escape sequences representing nongraphic characters in the
> > | execution character set are intended to produce actions on display
> > | devices as follows:
> > |
> > | [...]
> > |
> > | \v (vertical tab) Moves the active position to the initial position of
> > | the next vertical tabulation position. If the active position is at or
> > | past the last defined vertical tabulation position, the behavior is
> > | unspecified.
> >
> > It is undefined if there are any vertical tabulation positions (at
> > least I haven't found anything about them in the draft, except that the
> > semantics of \v relies on them). Thus, the only guaranteed intention is
> > unspecified behaviour, which isn't much.
> >
> > IMHO it isn't even unspecified, but only undefined behaviour, because
> > the definition of unspecified behaviour in 3.19 requires that two or
> > more possibilities are provided by the Standard, but the description of
> > what happens after the last defined vertical tabulation position
> > doesn't provide any possibilities.  However, I'm not a standards lawyer
> > and may be very wrong here.
>
> If your conclusion requires you to ignore half a page of text desribing
> what escape sequences are supposed to do, then you are, indeed, very
> wrong. Those words aren't in there just as spares. They tell you what
> the various escape sequences are supposed to do. The underlying issue is
> that some systems don't support those operations, so the wording of the
> standard has to hedge here. There's no way to say in standardese that
> implementors must do it this way unless they can't.
>
> Try this thought experiment: suppose you've just bought a brand new
> compiler for your top of the line desktop workstation. The first thing
> you try is this program:
>
> #include <stdio.h>
>
> int main()
> {
> printf("Hello, world\n");
> printf("Hello, world\n");
> printf("Hello, world\n");
> return 0;
> }
>
> When you run it, at the top of the screen you see the following text:
>
>         Hello, worldHello, worldHello, world
>
> You call the compiler vendor to complain, and they explain that that
> half page of text describing the effects of escape sequences is merely
> advisory, and that the effect of using a newline character in a C
> program is, in fact, undefined, so they are being kind to you by
> ignoring it rather than crashing your system.
>
> Your reaction will probably be somewhere between these two extremes:
>
>         1. "I understand it much better now. Thank you for explaining it so
> clearly."
>         2. "You idiot, of course newline means start a new line."
>
> Now, I suspect that most folks would lean strongly toward 2. Using
> newline to indicate the end of a line and the start of a new one is
> pretty firmly embedded in every C programmer's thinking, and with good
> reason. That's what the standard says it's supposed to do.

Now assume that you buy an Unix compiler, try this program,
and find it prints nothing. Now you call your compiler vendor
and say "Your compiler is buggy, it doesn't print."

Now your compiler vendor answers: "Well, it does print,
but out default output device is /dev/null, that's the
reason why you don't see anything."
Now what would yor reaction be:

1. "I understand it much better now. Thank you..."
2. "You idiot, of course standard output is meant to be
   /dev/tty on Unix, unless I've redirected it."

Well, I'd say you'd do 2, but you would _not_ try to use
the standard to prove that you are right. You would use
common sense and existing practise. And you would probably
use another compiler in future.
Market pressure will ensure that this compiler will either
behave as expected, or die (regardless of it's standard
conformance).

Now, the standard expresses an *intent* of what \n
should do. It could also express an intent what \e
should do. Even if on some systems that intent cannot
be followed, it's no problem - the same may be true
for \b. The intent is *not* binding, but nevertheless
a way to get compiler vendors do the right thing.

If the standard demanded \e, and gave the intent, then
you could expect code containing "\e" to work. If on your
compiler it doesnm't work, but the execution character set
has an ESC character, you could blame your compiler vendor
- not to violate the standard, but to not follow the intent.
Currently, if you want "\e" in your compiler, your position
is not very good - there's no standard intent given, so
there's no reason why your compiler vendor should give you \e
and give it the intended meaning, unless you are one of the
main customers of the compiler.
---
[ 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:

[...]

> Once again, condensed from the C standard:
>
>     \a (alert) Produces an audible or visible alert.
>     \b (backspace) Moves the actrive position to the previous position on
>         the current line.

[...]

      \e (escape) allow a different interpretation of following
          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              ]

In article <37E3C668.E219EA07@acm.org>,
 Pete Becker <petebecker@acm.org> writes:
> This is a description, not a specification. That is, an implementation
> that interpreted the first character following \e as a request to reboot
> the system satisfies these requirements. I suspect that folks have
> something a little narrower in mind.

And the specification of \v only specifies "intended" behaviour. And even
that looks rather undefined, from 1999-01-18 draft of C9x:

| 5.2.2 Character display semantics
|
| 2 Alphabetic escape sequences representing nongraphic characters in the
| execution character set are intended to produce actions on display
| devices as follows:
|
| [...]
|
| \v (vertical tab) Moves the active position to the initial position of
| the next vertical tabulation position. If the active position is at or
| past the last defined vertical tabulation position, the behavior is
| unspecified.

It is undefined if there are any vertical tabulation positions (at
least I haven't found anything about them in the draft, except that the
semantics of \v relies on them). Thus, the only guaranteed intention is
unspecified behaviour, which isn't much.

IMHO it isn't even unspecified, but only undefined behaviour, because
the definition of unspecified behaviour in 3.19 requires that two or
more possibilities are provided by the Standard, but the description of
what happens after the last defined vertical tabulation position
doesn't provide any possibilities.  However, I'm not a standards lawyer
and may be very wrong here.

> But then the behavior depends on the particular device that the code is
> talking to, which makes it impossible for the implementor to predict
> what will happen. So the characters following \e cannot be interpreted
> "in an implementation defined way," because the implementation cannot
> define what the behavior is.

Which can also be said about \v. Note that the Standard doesn't define
behaviour, it only defines intentions.

> Maybe. But ultimately it seems to me that this boils down to a request
> that '\e' be shorthand for '033'. I don't see any reasonable way to give
> it more content than that. That's only useful with the ASCII codeset,
> and it provides very little benefit even then.

Yes, it can only be an implementation-defined shorthand. And the only
guaranteed feature of \v is exactly this: it produces a single char. I
think \e defined this way would be more useful than \v has ever been.

I can only see two valid positions:

a) \e should not be in the Standard for the same reason \v and other
escape sequences should not be there: The Standard can't specify any
required behaviour. But now \v is already there and stays in the
Standard because there is no need to break any existing code.

b) \e gets into the Standard. The intention of \e is to produce the
escape character of the execution character set, if it has one.

--
Jan


[ 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 <37E57B68.93B891E1@ix.netcom.com>, Paul D. DeRocco
<pderocco@ix.netcom.com> writes
>But this is no worse than the situation for printable characters. If I
>write a C or C++ program containing "X", compile it for an EBCDIC machine,
>and send the output to an ASCII printer, I'm assuming that there's a device
>driver that's doing EBCDIC to ASCII conversion. I would expect it to do the
>same thing for EBCDIC ESC as I would for EBCDIC "X", which is to say,
>translate it into the ASCII equivalent.

That kind of translation for control characters would be, IMO, extremely
unfriendly.  I once had a lot of problem on an MSDOS system trying to
send an ASCII 26 to a printer without having to deal with control
characters metamorphosing behind my back.


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ 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
>Suppose I'm implementing the standard library on a system whose display
>device is mapped to an 80x25 array of 16-bit storage cells that hold
>character codes and color codes. I know how to write the code that deals
>with \a, \t, \r, \v, etc. What code does this definition (or any other
>proposed definition) require me to write to handle \e?

It's not an issue for standard library implementors. It's an issue for
device and display protocol driver implementors. As a standard library
implementor, none of those characters should be your concern. It's up to a
lower level of abstraction (BIOS, ANSI.SYS, curses, custom device driver,
whatever) to decide where the next tab is, how to get the cursor to the
first column of the next line, and so on, when they see one of those
characters in the stream.

"Implementation-defined" means just that. As a standard library implementor,
you would do exactly whatever you would now do in the circumstance you
described (and given the absense of support for '\e') when (assuming your
display is an ASCII device) you write the code that deals with '\x1b'. Which
is that you trust the programmers to know what they are doing and pass the
characters along to the logical device. Just exactly as you would do with
\t, \n, \v, \f, \r, \b.
---
[ 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 <francis@robinton.demon.co.uk> wrote in message
news:9O56fBAAk943Ewyl@robinton.demon.co.uk...
>
  > Actually I think it is worse than that.  One common use of ESC is to
 > prefix info being sent to a printer.  The correct code is dependent on
 > the printer and not on the platform you are using.  I can imagine
 > programmers getting into serious confusion by assuming that \e was the
 > same as an ASCII ESC in all circumstances.  If you need to send 033 to
 > your printer it will not help if this is replaced by the EBCDIC code for
 > ESC.

In my experience, most uses for ESC where to send an escape sequence to an
ASCII printer attached to an IBM mainframe using a protocol converter.  The
protocol converter converts EBCDIC ESC to ASCII ESC so EBCDIC ESC is what I
would want.

Greg Brewer
---
[ 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> wrote in message
news:37E3C3F2.390C6BAE@acm.org...
> I don't want you to repeat it at all. I want you to tell me what \e
> does, so that as a library implementor I can do a reasonable job of
> writing code to implement it.

Why would you, as a library implementor, care what \e does?  A library
implementor does not implement \e; that is the compilers job.  A \e may be
embeded in a string passed to a library function; however, there is no
requirement that the library function do anything with it.

As I noted in the original post for this thread, I needed for my users to be
able to embed an escape character into a typed string on a dialog.  Since
pressing the escape key would dismiss the dialog rather than enter a
character, I instructed the users to enter \e.  I gave similar instructions
for \t, \n, \a, and so forth.  In the course of implementing the function
that translated the string from the entered representation to the internal
representation, I had to go look up the code for escape.  At that time, I
thought "gee, wouldn't it be nice if the sequence was available so I didn't
need to look it up."

> From the ANSI C standard, cl. 2.2.2:
>
>     \a (alert) Produces an audible or visible alert. The active position
shall
>     not be changed.
>
>     \b (backspace) Moves the active position to the previous position on
the
>     current line. If the active position is at the initial position of
>     a line, the behavior is unspecified.
>     ....

Just to satisfy Pete, here is a definition.

\e (escape)  Does nothing!  Neither the active position nor the current line
is changed.  May not be 0.

Personally, I think we are wasting our time trying to convince Pete.  Since
such a thing is of no use to him, his mind is closed and he wants no one to
have it.  Thousands would benefit and there is no way it could hurt Pete;
but, he can't use it so no one gets it.

Greg Brewer
---
[ 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:
>
> I've programmed in C for a BBC micro based system. It doesn't have an
> ESC character.

I'm curious.  Does this BBC micro based system not have printers attached to
it?  If so, can you not attach a laserjet or inkjet printer to it?  If so,
how to you control the printer?

I have strong doubts that you would be porting anything to it that contains
a \e.  I guess that if someone was trying to attach a laserjet printer to it
and they had a C program that worked on some other system to control it,
they might think that it would work on the BBC micro system and try
compiling and running it there.  I don't see how the results would be any
different than if the C program controls the printer using strings that
contain \e or \x1b or any other sequence.  On the other hand, if this BBC
micro based system has a character code other than \x1b that you don't know
about that its parallel port driver will send out as an ASCII escape and the
compiler writer knows about this code then the program may actually work.

Greg Brewer
---
[ 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 <37E3C11A.84FEB325@acm.org>,
 Pete Becker <petebecker@acm.org> writes:
> From the C standard:
>
>  \v (vertical tab) Moves the active position to the initial position
>  of the next vertical tabulation position.

Unless the C9x draft that I have differs in this point, you missed some
important words: Your quote is only "intended" behaviour.

> But even if you're into this sort of
> dodging, how long do you think you'll continue to have customers if your
> library clears the screen when it encounters a \t and mine moves to the
> next tab position?

That's a problem with the customers, not with the C Standard. The C
Standard just reflects common expectations when it talks about intended
behaviour. It doesn't restrict implementations to any specific
semantics.

You were asking how \e must behave: Well, if your customers already
have some expectations about \e, you may want to implement these.
Otherwise, just ignore \e, or clear the screen or treat it like a
space, or whatever.

--
Jan
---
[ 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:
> No, for "the others" I do what the standard says I should do.

More likely, the terminal driver (or whatever) handles the \
characters the way the standard suggests.  Your implementation
probably doesn't do anything special with them on output.  And the
code that actually handles these characters also handles the escape
character for whatever character set you're using, doesn't it?

> What should I do for \e? Poll users to figure out what they think
> the definition is?

No, because you already know what they expect, even though the
standard wouldn't spell it out for you.

> > I repeat: why do you expect a requirement for \e?
>
> Because a standard imposes requirements. That's what it's for.

Most of the time.  But there are no requirements for the existing \
characters, and you aren't complaining about them.  Why the
inconsistency?


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              ]

In article <37E56D1D.582B9BFF@ix.netcom.com>, pderocco@ix.netcom.com
says...
> Pete Becker wrote:
> >
> > No, for "the others" I do what the standard says I should do. What
> > should I do for \e? Poll users to figure out what they think the
> > definition is?
>
> \e should translate into the character set's escape character. This is \x1B
> for ASCII, \x26 for EBCDIC. If the character set doesn't have an escape
> character (if such a character set actually exists), then generate an error
> message.

I've stayed out of this one until now, but I think I'll jump in for a
moment.

I don't see where this accomplishes anything useful.  Even if you
could theoretically generate an escape character portably, it seems to
me that you can't DO anything useful with it portably anyway.

AFAIK, an escape character is used primarily with various peripherals,
and different peripherals require different escape sequences.  To do
anything useful at all with an escape character, you have to know
quite a bit about the peripheral in question, including not only the
exact value it uses for its escape character, but what things can
legally follow that and what each set of following characters
accomplishes.  In short, being able to portably generate something
that maps to an escape character under both ASCII and EBCDIC (to use
your two examples) isn't of much real use: before any real use can be
made of this, I have to know (for example) what sorts of strings I can
send to this particular device on the ASCII system -- for example, if
I send an ANSI (more or less similar to VT-100) escape sequence to a
typical laser printer, it's not going to accomplish anything useful.

Likewise, if I have (for example) an ASCII laser printer attached to
an IBM mainframe, chances are that if I use '\e' (or whatever) I
actually want an ASCII escape character sent to the laser printer, not
an EBCDIC escape character.  Until you have a fairly complete spec on
the system as a whole, it's hard to guess how to accomplish that;
chances are it'll depend at least a little bit on how the printer
driver is set to act.

This general area has been discussed and dealt with before, and the
result was termios and similar stuff: you look up a complete string
based on 1) the device you're talking to, and 2) the logical action
you want to accomplish.

While most who've used it can attest that this is far from perfect, it
at least allows you to accomplish quite a few useful things.  The
ability to generate something called an escape character, by itself,
seems unlikely to me to allow you to accomplish ANYTHING portably that
you can't right now.

--
    Later,
    Jerry.

The Universe is a figment of its own imagination.
---
[ 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:
>
> Pete Becker wrote:
> >
> > I don't want you to repeat it at all. I want you to tell me what \e
> > does, so that as a library implementor I can do a reasonable job of
> > writing code to implement it.
>
> I don't think it has anything to do with library implementation. I've never
> seen a C or C++ standard library that attempted to do anything with \t,
> other than pass it through to the OS device driver. In fact, the library
> really couldn't "obey" tabs without either providing a standard means for
> setting tabs, or providing a standard fixed set of tab stops.

It has everyting to do with library implementation. If I write an IO
library that relies on some low level driver that doesn't handle tabs
correctly then my implementation of the standard library doesn't conform
to the standard. It doesn't matter that I tried to pass responsibility
off to some other part of the system. It's my job to make it work right.

>
> The only exception to this is the processing of \n. This is a special case,
> because every text output system (beyond a single-line display) needs a
> means of starting a new line, while only some need escapes or vertical
> tabs, and there are several widely-used standards for starting a new line.
>
> Other than that, the meanings of the backslash escapes are only an issue
> for the compiler writer, and then only a problem if the execution character
> set lacks a suitable single character for the function that the backslash
> escape is supposed to represent. This, however, is a mythical problem, not
> a real one.

Except, of course, for the not-so-mythical systems that require two
characters to move the output position to the beginning of the next
line. That's done in the library.

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

Christopher Eltschka wrote:
>
> Pete Becker wrote:
> >
> > Hyman Rosen wrote:
> > >
> > > Pete Becker <petebecker@acm.org> writes:
> > > > I've been reading the C standard. Too bad the C++ standard screwed it
> > > > up. <g> So what do you take this to mean if the platform's character set
> > > > does not define NL, HT, VT, etc.?
> > >
> > > I don't take it to mean anything. Presumably the implementation on such
> > > a platform would ascribe some meaning to them.
> >
> > Well, you can't say both that it doesn't mean anything and that the
> > implementation is free to do whatever it wants. Either it's
> > implementation-specific or it isn't. Choose one. <g>
> >
> > >
> > > > Defined as what? That is, what should the implementation do if there is
> > > > no character whose name is ESC?
> > >
> > > The same thing it does when there is no character whose name is BEL :-)
> >
> > The C standard says: "\a (alert) Produces an audible or visual alert."
> >
> > > Since the Standard didn't see fit to further specify the behavior, I
> > > don't either. At worst, the implementation would just assign \e to be
> > > some arbitrary control character, or a printing character outside of
> > > the usual 96.
> > >
> >
> > So you'd find it acceptable for \e to be mapped, for example, to \a, and
> > produce an alert, and then to display the rest of the escape sequence as
> > ordinary characters?
>
> As acceptable as I find it for \t being two thousand spaces,
> \v being two hundred lines and \a putting an "alert" dialog
> box onto the screen.

The first two are, of course silly. And I assume they were made up, for
dramatic effect. The last one isn't all that unreasonable, depending on
the particular system.

>
> I'd expect implementors to do something reasonable where
> possible. So for purely ASCII systems, I'd expect \e just
> to map to \x1B, just as I expect \a to map to \x07.

Why should \a map to some particular value? The standard describes what
effect it has. The value that's used to get that effect is noboby's
business.

> Of course
> an implementation could as well map \a to \x80 (and produce
> an alert on that), however I'd not like that on ASCII systems
> where a BEL character (\x07) is already defined.
>
> On systems where the character set doesn't include an escape
> character, one reasonable action would be to ignore that
> character completely. Another reasonable action would be to
> interpret is as if it were an escape character, and produce
> f.ex. an VT100 compatible behaviour. Another reasonable
> behaviour would be to just make \e map to some printable
> character.

So what's wrong with the current state of affairs? If you use \e as a
character constant the behavior of the resulting program is undefined.
If your compiler vendor tells you what effect \e has you can use it, and
if they don't, you can't.

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

Jerry Coffin wrote:
>
> I don't see where this accomplishes anything useful.  Even if you
> could theoretically generate an escape character portably, it seems to
> me that you can't DO anything useful with it portably anyway.

I don't want to do anything with it portably. I merely want a shorthand for
ASCII esc, since occasionally I find myself writing code that has lots of
\x1B in strings, which are harder to type and read. My argument is merely
that the two widely used character sets, ASCII and EBCDIC, both have ESC
characters, so defining \e as the character set's ESC character doesn't
cause any problems with portability.

> Likewise, if I have (for example) an ASCII laser printer attached to
> an IBM mainframe, chances are that if I use '\e' (or whatever) I
> actually want an ASCII escape character sent to the laser printer, not
> an EBCDIC escape character.

Yes, and chances are I actually want ASCII printables to be sent to the
laser printer, not EBCDIC printables. If I'm typing quoted strings in a
C/C++ program on an EBCDIC machine, and not explicit hex codes for ASCII
characters, then I'm counting on there being some device driver that does
EBCDIC to ASCII translation. Such a driver ought to be able to translate
EBCDIC control characters into ASCII, not just the printables.

> The ability to generate something called an escape character, by itself,
> seems unlikely to me to allow you to accomplish ANYTHING portably that
> you can't right now.

Not all software writing is, or has any reason to be, portable. Almost none
has to be portable to non-ASCII machines. I just want something to make
escape sequences more readable and easier to type.

--

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              ]

Christopher Eltschka wrote:
>
> Pete Becker wrote:
>
> [...]
>
> > Once again, condensed from the C standard:
> >
> >     \a (alert) Produces an audible or visible alert.
> >     \b (backspace) Moves the actrive position to the previous position on
> >         the current line.
>
> [...]
>
>       \e (escape) allow a different interpretation of following
>           characters.

Please give an example of code using \e, and based on this definition,
explain what the behavior of the program will be.

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

Al Stevens wrote:
>
> Pete Becker wrote
> >Suppose I'm implementing the standard library on a system whose display
> >device is mapped to an 80x25 array of 16-bit storage cells that hold
> >character codes and color codes. I know how to write the code that deals
> >with \a, \t, \r, \v, etc. What code does this definition (or any other
> >proposed definition) require me to write to handle \e?
>
> It's not an issue for standard library implementors. It's an issue for
> device and display protocol driver implementors. As a standard library
> implementor, none of those characters should be your concern.

Sorry, but that display device that I describes is standard out, and
I've got to write the library code that puts characters out to it.

> It's up to a
> lower level of abstraction (BIOS, ANSI.SYS, curses, custom device driver,
> whatever) to decide where the next tab is, how to get the cursor to the
> first column of the next line, and so on, when they see one of those
> characters in the stream.

No, it's part of the language definition, so as a library implementor
I'm responsible for making sure that code that uses it acts in a way
that's consistenet with the requirements of the standard.

>
> "Implementation-defined" means just that. As a standard library implementor,
> you would do exactly whatever you would now do in the circumstance you
> described (and given the absense of support for '\e') when (assuming your
> display is an ASCII device) you write the code that deals with '\x1b'. Which
> is that you trust the programmers to know what they are doing and pass the
> characters along to the logical device. Just exactly as you would do with
> \t, \n, \v, \f, \r, \b.

There is no prescribed value for \t, \n, \v, etc. Their definitions are
in terms of observable behavior, not values. That's how they differ from
'\x1b' or '\x07' or any other explicit value. What value should '\e'
have? If it's '\033' then its utility is that it saves typing two
characters. Hardly a valid use of all the time that's been spent on this
thread.

--
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:
>
> Pete Becker wrote:
> >
> > Once again, condensed from the C standard:
> >
> >     \a (alert) Produces an audible or visible alert.
> >     \b (backspace) Moves the actrive position to the previous position on
> >         the current line.
> >     \f (form feed) Moves the active position to the initial position at
> >         the start of the next logical page.
> >     \n (new line) Moves the active position to the initial position of
> >         the next line.
> >     \r (carriage return) Moves the active position to the initial
> >         position of the current line.
> >     \t (horizontal tab) Moves the active position to the next horizontal
> >         tabulation position on the current line.
> >     \v (vertical tab) Moves the active position to the initial position
> >         of the next vertical tabulation position.
>
> I don't believe these clauses require that such a construct in a string
> _must_ actually do those things. In some environment, it may, for instance,
> be impossible to do one or more of those things without generating more
> than one character, while the above constructs must translate into single
> character codes. (In fact, many real-world environments turn \n into a line
> feed without a carriage return, in binary mode, requiring \r\n to do both.)
> The standard is merely saying that each construct translates into the
> single character code from the character set that conventionally has the
> described function.

No, it says nothing at all about translating to a single character. As
in your example, \n sometimes is translated into two characters. What
the standard describes is the OBSERVABLE BEHAVIOR of a program that uses
these characters.

>
> I don't think anyone would actually have any trouble should \e be added,
> described as "Introduces an escape sequence." Everyone knows what that
> means.

Really? Tell that to my Hayes modem, whose escape sequence is "+++", or
to a SLIP implementation, whose escape sequence is the value 219, or to
ANSI.SYS, whose escape sequence is the value 27. Now, which of these is
the "escape sequence" that \e represents?

> If a particular data consumer doesn't understand any escape
> sequences, one wouldn't have any reason to put \e into a string; similary,
> if a data consumer doesn't have vertical tab stops, one wouldn't have any
> reason to put \v into a string.

In other words, this would be an ASCII-only part of the standard. The
only one. Doesn't sound like much of an aid to portability...

--
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:
> > No, for "the others" I do what the standard says I should do.
>
> More likely, the terminal driver (or whatever) handles the \
> characters the way the standard suggests.  Your implementation
> probably doesn't do anything special with them on output.

Several messages back I asked about how to go about writing output code
for a 25x80 memory mapped display. Pushing responsibility off on the
driver is an evasion, not an answer.

> And the
> code that actually handles these characters also handles the escape
> character for whatever character set you're using, doesn't it?

Not when I send characters to a printer which expects a particular value
as an escape character, regardless of what character set the compiler
thinks is being used.

>
> > What should I do for \e? Poll users to figure out what they think
> > the definition is?
>
> No, because you already know what they expect, even though the
> standard wouldn't spell it out for you.

No, I don't know what they expect. That's why I keep asking. And if the
best answer you can give is "you know what I mean," then you haven't got
a chance of getting this adopted into the language.

>
> > > I repeat: why do you expect a requirement for \e?
> >
> > Because a standard imposes requirements. That's what it's for.
>
> Most of the time.  But there are no requirements for the existing \
> characters, and you aren't complaining about them.  Why the
> inconsistency?
>

The claim that "there are no requirements for the existing \ characters"
is false. I've quoted the text of the C standard several times in
earlier messages to show the requirements that it imposes.

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

Jan Echternach wrote:
>
> In article <37E3C11A.84FEB325@acm.org>,
>         Pete Becker <petebecker@acm.org> writes:
> > From the C standard:
> >
> >       \v (vertical tab) Moves the active position to the initial position
> >       of the next vertical tabulation position.
>
> Unless the C9x draft that I have differs in this point, you missed some
> important words: Your quote is only "intended" behaviour.

And what is the "intended behavior" of \e?

>
> > But even if you're into this sort of
> > dodging, how long do you think you'll continue to have customers if your
> > library clears the screen when it encounters a \t and mine moves to the
> > next tab position?
>
> That's a problem with the customers, not with the C Standard. The C
> Standard just reflects common expectations when it talks about intended
> behaviour. It doesn't restrict implementations to any specific
> semantics.

The C standard talks about intended behavior, which is more than anyone
has been willing to do with regard to \e. Note that saying that it
represents the escape character in the execution character set says
nothing about behavior, only implementation.

>
> You were asking how \e must behave: Well, if your customers already
> have some expectations about \e, you may want to implement these.
> Otherwise, just ignore \e, or clear the screen or treat it like a
> space, or whatever.

What should the standard say about this that it doesn't currently say?
For those who haven't bothered to read the standard, it says that the
behavior of \e is undefined, i.e. the standard does not impose any
requirement on a compiler when code uses \e as a character constant. So
if your compiler vendor documents what it does and you like what they
say you can use it. Otherwise you better stay away 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              ]

"Paul D. DeRocco" wrote:
>
> Pete Becker wrote:
> >
> > No, for "the others" I do what the standard says I should do. What
> > should I do for \e? Poll users to figure out what they think the
> > definition is?
>
> \e should translate into the character set's escape character. This is \x1B
> for ASCII, \x26 for EBCDIC. If the character set doesn't have an escape
> character (if such a character set actually exists), then generate an error
> message.

As Francis Glassborow pointed out in another message, this produces
rather surprising results for someone who uses \e as the beginning of an
escape sequence for a printer, which doesn't change its escape character
just because someone attaches it to a different computer.

--
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> wrote in message
news:37E6EDCE.BC9C1EBF@acm.org...
> Christopher Eltschka wrote:
> >
> Please give an example of code using \e, and based on this definition,
> explain what the behavior of the program will be.

Okay, I'll give a shot.

void bar(const char *);
void foo(void)
{
   const char *output = "ABC\ecba";
   bar(output);
}

Okay, that's the code.  Now, I want the function foo to call the function
bar passing it the address of a memory location containing the first of 8
characters.

Simple enough, right.

Greg Brewer




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

Jan Echternach wrote:
>
> In article <37E3C668.E219EA07@acm.org>,
>         Pete Becker <petebecker@acm.org> writes:
> > This is a description, not a specification. That is, an implementation
> > that interpreted the first character following \e as a request to reboot
> > the system satisfies these requirements. I suspect that folks have
> > something a little narrower in mind.
>
> And the specification of \v only specifies "intended" behaviour. And even
> that looks rather undefined, from 1999-01-18 draft of C9x:
>
> | 5.2.2 Character display semantics
> |
> | 2 Alphabetic escape sequences representing nongraphic characters in the
> | execution character set are intended to produce actions on display
> | devices as follows:
> |
> | [...]
> |
> | \v (vertical tab) Moves the active position to the initial position of
> | the next vertical tabulation position. If the active position is at or
> | past the last defined vertical tabulation position, the behavior is
> | unspecified.
>
> It is undefined if there are any vertical tabulation positions (at
> least I haven't found anything about them in the draft, except that the
> semantics of \v relies on them). Thus, the only guaranteed intention is
> unspecified behaviour, which isn't much.
>
> IMHO it isn't even unspecified, but only undefined behaviour, because
> the definition of unspecified behaviour in 3.19 requires that two or
> more possibilities are provided by the Standard, but the description of
> what happens after the last defined vertical tabulation position
> doesn't provide any possibilities.  However, I'm not a standards lawyer
> and may be very wrong here.

If your conclusion requires you to ignore half a page of text desribing
what escape sequences are supposed to do, then you are, indeed, very
wrong. Those words aren't in there just as spares. They tell you what
the various escape sequences are supposed to do. The underlying issue is
that some systems don't support those operations, so the wording of the
standard has to hedge here. There's no way to say in standardese that
implementors must do it this way unless they can't.

Try this thought experiment: suppose you've just bought a brand new
compiler for your top of the line desktop workstation. The first thing
you try is this program:

#include <stdio.h>

int main()
{
printf("Hello, world\n");
printf("Hello, world\n");
printf("Hello, world\n");
return 0;
}

When you run it, at the top of the screen you see the following text:

 Hello, worldHello, worldHello, world

You call the compiler vendor to complain, and they explain that that
half page of text describing the effects of escape sequences is merely
advisory, and that the effect of using a newline character in a C
program is, in fact, undefined, so they are being kind to you by
ignoring it rather than crashing your system.

Your reaction will probably be somewhere between these two extremes:

 1. "I understand it much better now. Thank you for explaining it so
clearly."
 2. "You idiot, of course newline means start a new line."

Now, I suspect that most folks would lean strongly toward 2. Using
newline to indicate the end of a line and the start of a new one is
pretty firmly embedded in every C programmer's thinking, and with good
reason. That's what the standard says it's supposed to do.

>
> > But then the behavior depends on the particular device that the code is
> > talking to, which makes it impossible for the implementor to predict
> > what will happen. So the characters following \e cannot be interpreted
> > "in an implementation defined way," because the implementation cannot
> > define what the behavior is.
>
> Which can also be said about \v. Note that the Standard doesn't define
> behaviour, it only defines intentions.

No, it defines behavior: /v "Moves the active position to the initial
position of the next vertical tabulation position."

>
> > Maybe. But ultimately it seems to me that this boils down to a request
> > that '\e' be shorthand for '033'. I don't see any reasonable way to give
> > it more content than that. That's only useful with the ASCII codeset,
> > and it provides very little benefit even then.
>
> Yes, it can only be an implementation-defined shorthand. And the only
> guaranteed feature of \v is exactly this: it produces a single char.

Not if you're right that its behavior is undefined.

> I
> think \e defined this way would be more useful than \v has ever been.
>
> I can only see two valid positions:
>
> a) \e should not be in the Standard for the same reason \v and other
> escape sequences should not be there: The Standard can't specify any
> required behaviour. But now \v is already there and stays in the
> Standard because there is no need to break any existing code.
>
> b) \e gets into the Standard. The intention of \e is to produce the
> escape character of the execution character set, if it has one.
>

Be careful here: the "execution character set" is simply a bag holding
all of the characters that the translator can use in code that it
generates. It is not required to be all of the characters in some
well-defined character standard. Saying that \e produces the escape
character of the execution character set means only that it produces
whatever character it produces.

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

Greg Brewer wrote:
>
> Pete Becker <petebecker@acm.org> wrote in message
> news:37E3C3F2.390C6BAE@acm.org...
> > I don't want you to repeat it at all. I want you to tell me what \e
> > does, so that as a library implementor I can do a reasonable job of
> > writing code to implement it.
>
> Why would you, as a library implementor, care what \e does?  A library
> implementor does not implement \e; that is the compilers job.  A \e may be
> embeded in a string passed to a library function; however, there is no
> requirement that the library function do anything with it.
>
> As I noted in the original post for this thread, I needed for my users to be
> able to embed an escape character into a typed string on a dialog.  Since
> pressing the escape key would dismiss the dialog rather than enter a
> character, I instructed the users to enter \e.  I gave similar instructions
> for \t, \n, \a, and so forth.  In the course of implementing the function
> that translated the string from the entered representation to the internal
> representation, I had to go look up the code for escape.  At that time, I
> thought "gee, wouldn't it be nice if the sequence was available so I didn't
> need to look it up."

So the reason for having \e is to save you from having to look up what
the ASCII code for ESC? Well, there are a bunch more ASCII codes out
there, too. Are they also candidates for adoption into the C standard?
If so, what do we do for the poor EBCDIC folks?

>
> > From the ANSI C standard, cl. 2.2.2:
> >
> >     \a (alert) Produces an audible or visible alert. The active position
> shall
> >     not be changed.
> >
> >     \b (backspace) Moves the active position to the previous position on
> the
> >     current line. If the active position is at the initial position of
> >     a line, the behavior is unspecified.
> >     ....
>
> Just to satisfy Pete, here is a definition.
>
> \e (escape)  Does nothing!  Neither the active position nor the current line
> is changed.  May not be 0.

Now please write a program that uses \e, and from this "definition,"
tell me what the program should do, and why \e was necessary to do it.

>
> Personally, I think we are wasting our time trying to convince Pete.  Since
> such a thing is of no use to him, his mind is closed and he wants no one to
> have it.  Thousands would benefit and there is no way it could hurt Pete;
> but, he can't use it so no one gets it.

Now you're turning to ad hominem arguments. That's inappropriate, and
the moderator should have struck that out.

--
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:
>  2. "You idiot, of course newline means start a new line."
>
> Now, I suspect that most folks would lean strongly toward 2.

Yes, but not on the grounds of conformance to the standard.  It's QoI.

> Jan Echternach wrote:
> > Yes, it can only be an implementation-defined shorthand. And the only
> > guaranteed feature of \v is exactly this: it produces a single char.
>
> Not if you're right that its behavior is undefined.

If you could be bothered to read the following paragraph, you would
see this:

# Each of these escape sequences shall produce a unique
# implementation-defined value which can be stored in a single char
# object.

See the "shall"?  That's a requirement.  "are intended to", which
appears in the preceding paragraph, is not a requirement, and all the
text you're relying on is subordinate to "are intended to".


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 D. DeRocco" wrote:
> One could wish, I suppose, for C escapes for all standard control
> characters. However, I'm only suggesting \e for ESC because I think it's
> the only one that doesn't already have a C escape, and that is commonly
> used. I know I use it a lot.

Well, there is one problem.  Scarcely anyone I know uses ESC
in *any* form in his C code.  On the few occasions when we
are programming for "glass TTY" terminals (or emulators),
we use the curses library, which isolates our application
from the vagaries of terminal models.  (But more often, we
use "dumb" text or else bitmap facilities.)  ESC itself has
no role in portable programming.


[ 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 <37E6EF72.7D106C8F@acm.org>...

>Sorry, but that display device that I describes is standard out, and
>I've got to write the library code that puts characters out to it.

Exactly. "...puts characters out to it." Then the logical device driver
decides what to do with them. The logical device driver is a part of your
platform and supported by the runtime that you distribute, but it shouldn't
be considered part of the "standard library."

>> It's up to a
>> lower level of abstraction (BIOS, ANSI.SYS, curses, custom device driver,
>> whatever) to decide where the next tab is, how to get the cursor to the
>> first column of the next line, and so on, when they see one of those
>> characters in the stream.
>
>No, it's part of the language definition, so as a library implementor
>I'm responsible for making sure that code that uses it acts in a way
>that's consistenet with the requirements of the standard.

Wrong. Where the next tab is and how to move the cursor are not part of the
language definition and should not be.

>There is no prescribed value for \t, \n, \v, etc. Their definitions are
>in terms of observable behavior, not values. That's how they differ from
>'\x1b' or '\x07' or any other explicit value. What value should '\e'
>have?

Why does it have to have a prescribed value, since, as you said, the others
do not?


>If it's '\033' then its utility is that it saves typing two characters.
>Hardly a valid use of all the time that's been spent on this
>thread.

Then use your time in ways that you find more appropriate. I, for one, have
found this discussion to be most entertaining and enlightening and prefer to
determine for myself the validity of the way I spend my time. <g>
---
[ 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 <37E6F076.2603BF8C@acm.org>...
>It has everyting to do with library implementation. If I write an IO
>library that relies on some low level driver that doesn't handle tabs
>correctly...

"correctly" is not defined by the standard in this case.

>... then my implementation of the standard library doesn't conform
>to the standard.

What part of the standard does it not conform to?
---
[ 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 <37E6ED12.63B3A301@acm.org>, Pete Becker <petebecker@acm.org> writes:
|>
|> No, it says nothing at all about translating to a single character. As
|> in your example, \n sometimes is translated into two characters. What
|> the standard describes is the OBSERVABLE BEHAVIOR of a program that uses
|> these characters.

Or something that isn't a character at all, such as a record terminator
under MVS.

|> > I don't think anyone would actually have any trouble should \e be added,
|> > described as "Introduces an escape sequence." Everyone knows what that
|> > means.
|>
|> Really? Tell that to my Hayes modem, whose escape sequence is "+++", or
|> to a SLIP implementation, whose escape sequence is the value 219, or to
|> ANSI.SYS, whose escape sequence is the value 27. Now, which of these is
|> the "escape sequence" that \e represents?

Or one of a set of defined bypass characters, as in TPUT FULLSCR under
MVS :-)  That is not a good specification, because it assumes a
particular 'escape sequence' model.

|> > If a particular data consumer doesn't understand any escape
|> > sequences, one wouldn't have any reason to put \e into a string; similary,
|> > if a data consumer doesn't have vertical tab stops, one wouldn't have any
|> > reason to put \v into a string.
|>
|> In other words, this would be an ASCII-only part of the standard. The
|> only one. Doesn't sound like much of an aid to portability...

No more than '\v'.  As I have posted before, there is a perfectly good,
portable specification of '\e', which is precisely the one specified
in ASCII.

    Writing a '\e' character to a text stream has an implementation-
    defined effect.

Please note that this is slightly MORE precise than the equivalent
specification of '\v' - and I speak as a user, third-party application
developer and implementor of C.


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 D. DeRocco" wrote:
>
> Jerry Coffin wrote:
> >
> > I don't see where this accomplishes anything useful.  Even if you
> > could theoretically generate an escape character portably, it seems to
> > me that you can't DO anything useful with it portably anyway.
>
> I don't want to do anything with it portably. I merely want a shorthand for
> ASCII esc, since occasionally I find myself writing code that has lots of
> \x1B in strings, which are harder to type and read. My argument is merely
> that the two widely used character sets, ASCII and EBCDIC, both have ESC
> characters, so defining \e as the character set's ESC character doesn't
> cause any problems with portability.
>

But it does: your printer that looks for ASCII ESC characters won't
respond the same way to EBCDIC escape characters. It wants a particular
value, not whatever value happens to be named ESC.

--
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:
> Paul Jarc wrote:
> > More likely, the terminal driver (or whatever) handles the \
> > characters the way the standard suggests.  Your implementation
> > probably doesn't do anything special with them on output.
>
> Several messages back I asked about how to go about writing output code
> for a 25x80 memory mapped display. Pushing responsibility off on the
> driver is an evasion, not an answer.

I'm just trying to clarify where the handling actually takes place.
It's generally done at a level where you don't know or care whether
the output is coming from a C program, and it generally handles an
escape character.

> > And the
> > code that actually handles these characters also handles the escape
> > character for whatever character set you're using, doesn't it?
>
> Not when I send characters to a printer which expects a particular value
> as an escape character, regardless of what character set the compiler
> thinks is being used.

Still, there is an escape character, and it is handled with the rest.
Translation between character sets, and whether to translate control
characters, is a separate issue.

> > > What should I do for \e? Poll users to figure out what they think
> > > the definition is?
> >
> > No, because you already know what they expect, even though the
> > standard wouldn't spell it out for you.
>
> No, I don't know what they expect. That's why I keep asking.

Well, then, poll the users.  Or guess.  Or ignore it, since this would
only be intent.

> And if the best answer you can give is "you know what I mean," then
> you haven't got a chance of getting this adopted into the language.

I'm not pushing to get \e in the language.  My position is not the
bare "\e belongs in standard C", but rather "\e belongs in standard C
about as much as the other \ characters".

> The claim that "there are no requirements for the existing \ characters"
> is false. I've quoted the text of the C standard several times in
> earlier messages to show the requirements that it imposes.

And I've quoted you back, showing that those are not requirements at
all.  I can't imagine why you're so reluctant to accept this.


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              ]

[Moderator's note: apologies if you see this message twice. -moderator (fjh).]

In article <37E6E958.221A7C8@acm.org>, Pete Becker <petebecker@acm.org> writes:
|>
|> "Paul D. DeRocco" wrote:
|> >
|> > Pete Becker wrote:
|> > >
|> > > No, for "the others" I do what the standard says I should do. What
|> > > should I do for \e? Poll users to figure out what they think the
|> > > definition is?
|> >
|> > \e should translate into the character set's escape character. This is \x1B
|> > for ASCII, \x26 for EBCDIC. If the character set doesn't have an escape
|> > character (if such a character set actually exists), then generate an error
|> > message.
|>
|> As Francis Glassborow pointed out in another message, this produces
|> rather surprising results for someone who uses \e as the beginning of an
|> escape sequence for a printer, which doesn't change its escape character
|> just because someone attaches it to a different computer.

I am afraid that he was mistaken.  Firstly, EXACTLY the same problem
applies to every other character, printing and non-printing.  Secondly,
the standard ways of driving ASCII devices from EBCDIC systems always
have been via a translation table.  You therefore get the RIGHT result
if it is EBCDIC ESC and the WRONG result if it is ASCII ESC.  In
general, that is.

He is perfectly correct that there is a problem when trying to send
characters with specific code values from EBCDIC to ASCII, which I
could describe if people REALLY want.


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              ]

Christopher Eltschka wrote:
>
>
> On systems where the character set doesn't include an escape
> character, one reasonable action would be to ignore that
> character completely. Another reasonable action would be to
> interpret is as if it were an escape character, and produce
> f.ex. an VT100 compatible behaviour. Another reasonable
> behaviour would be to just make \e map to some printable
> character.

Would you also consider this reasonable for all of the other escape
characters when the character set doesn't include that character? The
character set that I have in mind is ASCII, which has no newline
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              ]

"Brian B. McGuinness" wrote:
>
> "Paul D. DeRocco" wrote:
>
> > Why are we making this so difficult? In ASCII there is an ESC character. In
> > EBCDIC there is an ESC character. I don't believe there are any other
> > execution character sets, for which anyone will actually write a C++
> > compiler, that don't have an ESC character. If I'm wrong about this, then
> > I'd be surprised if this character set I'm as yet unaware of didn't also
> > have analogous problems with other missing control characters that are
> > already mentioned in the C++ standard.
>
> So the simplest solution would be to define '\e' as the ESC character and
> not worry about what its effect might be on any specific device; let the
> device driver's designer worry about that.
>
> For clarity, we could specify:
>
> In ASCII, '\e' = '\x1B'
> In EBCDIC, '\e' = '\x27'
> ... (mention any other cases here) ...
> In other codesets the meaning of '\e' is implementation-dependent.
>
> This should be simple enough for any compiler writer to implement and
> would cause '\e' to have the effect that most people would expect.
>

When I recompile my printer driver with a compiler that targets EBCDIC
it would stop working, because the printer is looking for '\033', and \e
now means something else. I assume that that's not really what "most
people would expect."

--
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 <37E6EF72.7D106C8F@acm.org>,
 Pete Becker <petebecker@acm.org> writes:
> No, it's part of the language definition, so as a library implementor
> I'm responsible for making sure that code that uses it acts in a way
> that's consistenet with the requirements of the standard.

The Standards (both C and C++) don't have any requirements regarding
behaviour of alphabetic escape sequences. The C Standard has some
intentions, but not more.

> There is no prescribed value for \t, \n, \v, etc. Their definitions are
> in terms of observable behavior, not values. That's how they differ from

No, 5.2.2p2 of the 1999-01-18 draft of C9x does not contain any
requirements, and 5.2.2p3 says:

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

There are values for \t, \n etc. They are, however,
implementation-defined.

> '\x1b' or '\x07' or any other explicit value. What value should '\e'
> have? If it's '\033' then its utility is that it saves typing two

An implementation-defined value, just like all other alphabetic escape
sequences.

BTW, I would extend 5.2.2p2 of C9x as follows:

    \e (escape) Produces unspecified behaviour.

Maybe the greatest benefit of \e would be to end this discussion. ;)

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

Greg Brewer wrote:
>
> Pete Becker <petebecker@acm.org> wrote in message
> news:37E6EDCE.BC9C1EBF@acm.org...
> > Christopher Eltschka wrote:
> > >
> > Please give an example of code using \e, and based on this definition,
> > explain what the behavior of the program will be.
>
> Okay, I'll give a shot.
>
> void bar(const char *);
> void foo(void)
> {
>    const char *output = "ABC\ecba";
>    bar(output);
> }
>
> Okay, that's the code.  Now, I want the function foo to call the function
> bar passing it the address of a memory location containing the first of 8
> characters.
>
> Simple enough, right.
>

Well, that's a start, but what does the code do? So far it has no
visible side effects. The exact same description would apply if the
string were "ABCDcba". It doesn't demonstrate the effect of using '\e'
in a string, unless all you want \e to be is a character constant with
no particular meaning.

--
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:
> Err, umm, well, the part that you snipped was when you said:
> > At worst, the implementation would just assign \e to be
> > some arbitrary control character, or a printing character outside of
> > the usual 96.
> I take it that this proposed definition is no longer proposed?

I said that should be the implementation "at worst", that is, when the
execution character set has no reasonable definition of ESC.

As someone else already pointed out, the definition of '\e' is for the
compiler, not the library. The compiler will change all uses of \e
into some character value, and the library will see only characters of
that value, with no information as to whether they came from a \e or
from a \x. On ASCII character sets, the library will continue doing
whatever it is that it does when it gets a \x1B, just like it executes
\n behavior when it's given a plain old \xA.


[ 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:
>
> No more than '\v'.  As I have posted before, there is a perfectly good,
> portable specification of '\e', which is precisely the one specified
> in ASCII.
>
>     Writing a '\e' character to a text stream has an implementation-
>     defined effect.
>
> Please note that this is slightly MORE precise than the equivalent
> specification of '\v' - and I speak as a user, third-party application
> developer and implementor of C.
>

I just don't see it. From the perspective of writing reasonably portable
code, a character cosntant whose only constraint is that it "has an
implementation-defined effect" cannot be used. A character constant
whose effect is to "[move] the active position to the initial position
of the next vertical tabulation position" is much more useful. If it
doesn't do that with the compiler that you're using, complain to the
vendor. They may have a good reason for not doing it on that particular
platform, which is why the standard is written the way it is, but at
least you have a shot at being able to use 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              ]

Pete Becker wrote:

> No, it says nothing at all about translating to a single character. As
> in your example, \n sometimes is translated into two characters. What
> the standard describes is the OBSERVABLE BEHAVIOR of a program that uses
> these characters.

No, the compiler _must_ translate the two characters backslash and lower
case n, when appearing in a quoted string, into a single character. The
library or a device driver may then translate \n into \r\n. But the
appearance of \n in a string represents a single byte of memory. A language
standard has no business _defining_ what a character must do, other than to
associate it with a standard conventional meaning. The C or C++ standard
has neither the right nor the power to require that a device implement,
say, the tab character. All it can do is say the backslash lower case t be
translated into the single character in the execution character set that is
conventionally used for that purpose. And no one has any problem with that.
No one expects a C or C++ compiler magically to ensure that some downstream
device understand the tab character.

> Really? Tell that to my Hayes modem, whose escape sequence is "+++", or
> to a SLIP implementation, whose escape sequence is the value 219, or to
> ANSI.SYS, whose escape sequence is the value 27. Now, which of these is
> the "escape sequence" that \e represents?

The last one. If the execution character set that the compiler is compiling
for is ASCII, then \e represents \x1B. If it is EBCDIC, then it is \x26.
The Hayes command set is an ASCII command set, even though it invents its
own mechanism for introducing out-of-band data. And in fact, the Hayes
escape isn't merely "+++", it's "+++" preceded and followed by a certain
amount of idle time on the line. But that has nothing to do with the issue
at hand.

You're consistently confusing what the compiler does with what the library,
device driver or device does. All requests for \e to be added to the
standard are merely requests that the compiler translate this pair of
characters into the single character from the execution character set that
is called the "escape" character. The standard may describe what an
"escape" character conventionally does, just as it describes what the other
control characters normally do, but such clauses can only describe
something which is specified elsewhere, not incorporate such things into
the standard.

> In other words, this would be an ASCII-only part of the standard. The
> only one. Doesn't sound like much of an aid to portability...

No, it's an ASCII plus EBCDIC plus any other character set that includes an
escape character part of the standard. And to the extent that someone wants
to write strings containing escape characters that are portable among such
character sets, it is a definite aid, because, as I previously wrote, any
device driver that translates EBCDIC from a program running on an IBM
computer into ASCII for an external device will know how to translate
control characters, not just the printables.

We're talking about character sets, not the languages (Hayes command set,
SLIP, ANSI display control, or whatever) that may be implemented with those
character sets.

--

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              ]

In article <37E2E93B.88CCAFD1@ix.netcom.com>, Paul D. DeRocco
<pderocco@ix.netcom.com> writes
>> I've programmed in C for a BBC micro based system. It doesn't have an
>> ESC character.

>Interesting. What is a BBC micro, and where can I get info on it? I'd like
>to see what it's character set is.

It's a 6502 based microcomputer first sold in or around 1980. It was
also used as the I/O subsystem of a CP/M-compatible micro and then of a
low-end Unix system.

Character codes 1 to 31 had various effects on the display. For example,
23 redefined the appearance of a character based on the next 9 octets,
and 31 changed the cursor position based on the next 2. Codes 32 to 255
were printable characters except in one display mode, where 128 to 159
altered the colour and other attributes of following characters. The
system software normally treated 32 to 126 as if they had the same
meaning as in ISO 8859-1, but in one mode some character were changed
(I think 96 was pound sterling).

Several emulators are available on the Internet.

>>>I've got modules in production code that have literally hundreds of
>>>instances of \x1B in strings
>>
>> What's wrong with:
>>
>>     #define ESC "\x1B"
>>
>> for ASCII, if that's what you're on ?
>
>I might as well just type out \x1B, or for that matter \xC for form feed.
>But this is harder to type and harder to read. And hex escapes are
>error-prone because they may inadvertently be followed by hex digits.

Nonsense.

#ifdef THIS_IS_ASCII
#define ESC "\x1B"
#elif defined (THIS_IS_EBCDIC)
#define ESC "\x33"   // or whatever it is
#endif

.....

printf (ESC "[B%d,%d", x, y);

or whatever.

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

Pete Becker <petebecker@acm.org> wrote in message
news:37E76A3E.42B95BC@acm.org...
> "Paul D. DeRocco" wrote:
> > characters, so defining \e as the character set's ESC character doesn't
> > cause any problems with portability.
> But it does: your printer that looks for ASCII ESC characters won't
> respond the same way to EBCDIC escape characters. It wants a particular
> value, not whatever value happens to be named ESC.

You are wrong.  A printer looking for ASCII escape characters will react
properly to a valid EBCDIC string containing an EBCDIC escape character.  It
will react properly because it will receive ASCII characters including an
ASCII escape character.   Just as it will react properly when an EBCDIC 'A'
is sent to the printer; it will receive an ASCII 'A'.

Greg Brewer




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

Al Stevens wrote:
>
> Pete Becker wrote in message <37E6EF72.7D106C8F@acm.org>...
>
> >Sorry, but that display device that I describes is standard out, and
> >I've got to write the library code that puts characters out to it.
>
> Exactly. "...puts characters out to it." Then the logical device driver
> decides what to do with them. The logical device driver is a part of your
> platform and supported by the runtime that you distribute, but it shouldn't
> be considered part of the "standard library."

This is a subtle distinction that escapes me. If the code produced by
the compiler and library doesn't do what it's supposed to do, it's
wrong, regardless of whether the problem arises in the code, the
library, the OS, or some third-party driver. Library vendors, in
particular, spend a great deal of time working around OS bugs and
quirks. For example, under DOS, most compilers generate the character
whose value is 0x0D (ASCII CR) when they encounter the character
constant \n. If the output system simply passes that value down into the
display driver the result will be that subsequent lines overwrite
previous ones. When the output code in the runtime library sees the
value 0x0D it has to send two characters to the display driver: 0x0D and
0x0A (ASCII LF).

>
> >> It's up to a
> >> lower level of abstraction (BIOS, ANSI.SYS, curses, custom device driver,
> >> whatever) to decide where the next tab is, how to get the cursor to the
> >> first column of the next line, and so on, when they see one of those
> >> characters in the stream.
> >
> >No, it's part of the language definition, so as a library implementor
> >I'm responsible for making sure that code that uses it acts in a way
> >that's consistenet with the requirements of the standard.
>
> Wrong. Where the next tab is and how to move the cursor are not part of the
> language definition and should not be.

Sigh. Someone has to decide, and there has to be code somewhere to deal
with the character that says "move to the next tab stop." If you write a
string containing \t to stdout and the result is that the output
position moves to the top of the screen without erasing the text that
was already on the screen you're entitled to complain, and insist that
your compiler vendor make it work right.

>
> >There is no prescribed value for \t, \n, \v, etc. Their definitions are
> >in terms of observable behavior, not values. That's how they differ from
> >'\x1b' or '\x07' or any other explicit value. What value should '\e'
> >have?
>
> Why does it have to have a prescribed value, since, as you said, the others
> do not?

Because that's what's being asked for.

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

Greg Brewer wrote:
>
> Pete Becker <petebecker@acm.org> wrote in message
> news:37E6EDCE.BC9C1EBF@acm.org...
> > Christopher Eltschka wrote:
> > >
> > Please give an example of code using \e, and based on this definition,
> > explain what the behavior of the program will be.
>
> Okay, I'll give a shot.
>
> void bar(const char *);
> void foo(void)
> {
>    const char *output = "ABC\ecba";
>    bar(output);
> }
>
> Okay, that's the code.  Now, I want the function foo to call the function
> bar passing it the address of a memory location containing the first of 8
> characters.
>
> Simple enough, right.
>

My other response was a bit brusque, so here's an expanded version.
Here's a list of the things that it looks like you can do portably with
a string containing \e under this definition:

1. you can pass it to strlen, and \e will count as one character
2. you can search for \e and replace the character that you find (which
will compare
 equal to \e, but may also compare equal to some other character)
3. you can write the string to a binary file, read that file back in
(with an executable
 produced by the same compiler), and expect to find \e in the same place

Here's a list of the things that you can't do with such a string:

1. write it to any device other than a disk (in particular you can't
display it on the screen)
2. write it to disk as part of a text file
3. read it from any device other than a disk

It doesn't sound very useful.

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

Al Stevens wrote:
>
> Pete Becker wrote in message <37E6F076.2603BF8C@acm.org>...
> >It has everyting to do with library implementation. If I write an IO
> >library that relies on some low level driver that doesn't handle tabs
> >correctly...
>
> "correctly" is not defined by the standard in this case.
>
> >... then my implementation of the standard library doesn't conform
> >to the standard.
>
> What part of the standard does it not conform to?

 \t (horizontal tab) Moves the active position to the initial position
of the next
  vertical 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              ]

Pete Becker <petebecker@acm.org> wrote in message
news:37E7BED0.CD38C829@acm.org...
> Greg Brewer wrote:
> >
> > Pete Becker <petebecker@acm.org> wrote in message
> > news:37E6EDCE.BC9C1EBF@acm.org...
> > > Christopher Eltschka wrote:
> > > >
> > > Please give an example of code using \e, and based on this definition,
> > > explain what the behavior of the program will be.
> >
> > Okay, I'll give a shot.
> >
> > void bar(const char *);
> > void foo(void)
> > {
> >    const char *output = "ABC\ecba";
> >    bar(output);
> > }
> >
> > Okay, that's the code.  Now, I want the function foo to call the function
> > bar passing it the address of a memory location containing the first of 8
> > characters.
> >
> > Simple enough, right.
> >
> Well, that's a start, but what does the code do? So far it has no
> visible side effects. The exact same description would apply if the
> string were "ABCDcba". It doesn't demonstrate the effect of using '\e'
> in a string, unless all you want \e to be is a character constant with
> no particular meaning.

What does it do?  It passes the address of an 8 character array to a
function named bar.  That was covered in the little paragraph after the
function.  It does demonstrate using '\e' in a string.  If you look closely
then you will see that it is in the center of the string array that is
assigned to the char pointer output.  \e is a character constant with a
particular value.  What more do you want?

Greg Brewer



[ 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 <37E6E958.221A7C8@acm.org>...
>As Francis Glassborow pointed out in another message, this produces
>rather surprising results for someone who uses \e as the beginning of an
>escape sequence for a printer, which doesn't change its escape character
>just because someone attaches it to a different computer.


The appropriate place for that translation would be in somewhere between the
application and to and possibly including the device driver. When you attach
a printer to a computer you must also install a device driver. The compiler
and the application in a truly device-independent platform, such as Win32
tries to be, do not care about the printer other than to read parameters
about margins, and so on. The appropriate place to be sending /e to a
printer is from a program at some level in the hierarchy--not necessarily
the application and not necessarily the device driver--that knows
specifically which printer it is dealing with and, presumably, which
character set. This is not a language issue.





[ 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> wrote in message
news:37E7E27C.D4B61DC7@acm.org...
>
> > void bar(const char *);
> > void foo(void)
> > {
> >    const char *output = "ABC\ecba";
> >    bar(output);
> > }
> My other response was a bit brusque, so here's an expanded version.
> Here's a list of the things that it looks like you can do portably with
> a string containing \e under this definition:
>
> 1. you can pass it to strlen, and \e will count as one character
> 2. you can search for \e and replace the character that you find (which
> will compare
> equal to \e, but may also compare equal to some other character)
> 3. you can write the string to a binary file, read that file back in
> (with an executable
> produced by the same compiler), and expect to find \e in the same place
>
> Here's a list of the things that you can't do with such a string:
>
> 1. write it to any device other than a disk (in particular you can't
> display it on the screen)
> 2. write it to disk as part of a text file
> 3. read it from any device other than a disk
>
> It doesn't sound very useful.

I agree with your list of cans; can't say the same with your list of can'ts.
1)  In my DOS programs, I send such strings to printers all the time.  I
have sent such strings to the display in the past when I was programming in
QuickC and its library didn't define a clearscreen function.  Ansi.sys
defines an escape sequence that clears the screen so I sent it.

2) Again, I have done it alot.  No big deal.  I'm not sure why you would
think this could possibly be a problem.

3)  Can't say I've ever had the occassion to need to read it from any other
device than a disk.  I take that back, the keyboard produces an escape
character and I have read that back in my DOS days.  Oh, and I once tried to
write a terminal emulation program that read escape characters -- along with
lots of others -- from the serial port.  I really don't see what relevance
the lack of sources for receiving \e has on its usefulness as a coding
standard.

Greg Brewer



[ 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> wrote in message
news:37E7E53E.AF6C7667@acm.org...
> Sigh. Someone has to decide, and there has to be code somewhere to deal
> with the character that says "move to the next tab stop." If you write a
> string containing \t to stdout and the result is that the output
> position moves to the top of the screen without erasing the text that
> was already on the screen you're entitled to complain, and insist that
> your compiler vendor make it work right.

Huh!  So if I write a string containing \t to a file then go to the DOS
prompt and use type to display that file and it behaves as you just
described, I should call Inprise and complain?


Greg Brewer


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

Greg Brewer wrote:
>
> Pete Becker <petebecker@acm.org> wrote in message
> news:37E76A3E.42B95BC@acm.org...
> > "Paul D. DeRocco" wrote:
> > > characters, so defining \e as the character set's ESC character doesn't
> > > cause any problems with portability.
> > But it does: your printer that looks for ASCII ESC characters won't
> > respond the same way to EBCDIC escape characters. It wants a particular
> > value, not whatever value happens to be named ESC.
>
> You are wrong.  A printer looking for ASCII escape characters will react
> properly to a valid EBCDIC string containing an EBCDIC escape character.  It
> will react properly because it will receive ASCII characters including an
> ASCII escape character.   Just as it will react properly when an EBCDIC 'A'
> is sent to the printer; it will receive an ASCII 'A'.
>

Does the printer read the tag bits on each character to determine
whether the value that it sees should be interpreted as ASCII or EBCDIC,
or does it look at its color?

Seriously, you seem to be talking about some sort of driver that
translates EBCDIC to ASCII. That makes it work, of course, but it
doesn't change what the printer sees. If you're sending the wrong
characters to the printer you have to do something to fix them or it
won't work.

--
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:
>
> Pete Becker wrote:
>
> > No, it says nothing at all about translating to a single character. As
> > in your example, \n sometimes is translated into two characters. What
> > the standard describes is the OBSERVABLE BEHAVIOR of a program that uses
> > these characters.
>
> No, the compiler _must_ translate the two characters backslash and lower
> case n, when appearing in a quoted string, into a single character. The
> library or a device driver may then translate \n into \r\n. But the
> appearance of \n in a string represents a single byte of memory. A language
> standard has no business _defining_ what a character must do, other than to
> associate it with a standard conventional meaning. The C or C++ standard
> has neither the right nor the power to require that a device implement,
> say, the tab character. All it can do is say the backslash lower case t be
> translated into the single character in the execution character set that is
> conventionally used for that purpose. And no one has any problem with that.
> No one expects a C or C++ compiler magically to ensure that some downstream
> device understand the tab character.
>
> > Really? Tell that to my Hayes modem, whose escape sequence is "+++", or
> > to a SLIP implementation, whose escape sequence is the value 219, or to
> > ANSI.SYS, whose escape sequence is the value 27. Now, which of these is
> > the "escape sequence" that \e represents?
>
> The last one. If the execution character set that the compiler is compiling
> for is ASCII, then \e represents \x1B. If it is EBCDIC, then it is \x26.
> The Hayes command set is an ASCII command set, even though it invents its
> own mechanism for introducing out-of-band data. And in fact, the Hayes
> escape isn't merely "+++", it's "+++" preceded and followed by a certain
> amount of idle time on the line. But that has nothing to do with the issue
> at hand.

Sure it does. The C standard doesn't say that the execution character
set has to be some pre-existing standard character set. The execution
character set is simply the set of characters that the compiler
translates characters into when they are part of the executable code. So
saying that \e must be the escape character in the execution character
set is simply stating a truism. Whatever \e is translated to is, ipso
facto, the escape character in the execution character set.

It's usually convenient to translate \t into a value that the display
driver will recognize as a tab character, but that is not required by
the standard. What's required (or recommended, if you insist) is that a
C string that contains the escape sequence \t have the effect of moving
the cursor position to the next tab stop when that character is
encountered.

>
> You're consistently confusing what the compiler does with what the library,
> device driver or device does.

No, I'm not at all confused about these. I've been writing systems code
for ten years. Ultimately an application programmer's concern is that
the characters be displayed in the appropriate way. The place where the
compiler and the OS meet is the runtime library. If the characters that
the compiler generates aren't getting out on the display correctly the
place to fix it is usually in the library. So, for example, that's where
the single character represented by '\n' gets translated into the two
characters CR and LF for a DOS system.

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

Al Stevens wrote:
>
> Pete Becker wrote in message <37E6E958.221A7C8@acm.org>...
> >As Francis Glassborow pointed out in another message, this produces
> >rather surprising results for someone who uses \e as the beginning of an
> >escape sequence for a printer, which doesn't change its escape character
> >just because someone attaches it to a different computer.
>
> The appropriate place for that translation would be in somewhere between the
> application and to and possibly including the device driver. When you attach
> a printer to a computer you must also install a device driver. The compiler
> and the application in a truly device-independent platform, such as Win32
> tries to be, do not care about the printer other than to read parameters
> about margins, and so on.
> The appropriate place to be sending /e to a
> printer is from a program at some level in the hierarchy--not necessarily
> the application and not necessarily the device driver--that knows
> specifically which printer it is dealing with and, presumably, which
> character set. This is not a language issue.
>

Fine: you've defined away the question. Since you never need to send \e,
you don't need a way of representing 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              ]

In article <pgpmoose.199909220426.3665@murlibobo.cs.mu.OZ.AU>,
nmm1@cus.cam.ac.uk says...

[ ... ]

> I am afraid that he was mistaken.  Firstly, EXACTLY the same problem
> applies to every other character, printing and non-printing.  Secondly,
> the standard ways of driving ASCII devices from EBCDIC systems always
> have been via a translation table.  You therefore get the RIGHT result
> if it is EBCDIC ESC and the WRONG result if it is ASCII ESC.  In
> general, that is.

This might or might not be correct.  In general it's pretty obvious
that if somebody sends the code for (say) 'A' to the printer, they
want it printed as an 'A', so that's what you translate to.  OTOH,
with quite a few control characters, I'm less certain that the
translation is nearly so obvious.

In addition, you've still got the problem that there's not much you
can reasonably DO with this, even if you're sure the correct
translation (whatever that happens to be) takes place.

--
    Later,
    Jerry.

The Universe is a figment of its own imagination.


[ 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:
> >       2. "You idiot, of course newline means start a new line."
> >
> > Now, I suspect that most folks would lean strongly toward 2.
>
> Yes, but not on the grounds of conformance to the standard.  It's QoI.

No, on the grounds of conformance, unless you are willing to ignore the
half page of text that describes what the effect of an escape sequence
is supposed to be. You have to look at the entire standard, not just the
parts that support your position.

--
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:
>
> Please give an example of code using \e, and based on this definition,
> explain what the behavior of the program will be.

    cout << "\eH";

This will write an escape and a capital H to the standard output stream. I
might write such a thing if I knew that standard output was connected to an
ANSI display, and I wanted to clear the screen and home the cursor. If I
didn't know what standard output was connected to, then I wouldn't be able
to do this, but in real life I often do know, and I often do this.

--

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              ]

"Douglas A. Gwyn" wrote:
>
> Well, there is one problem.  Scarcely anyone I know uses ESC
> in *any* form in his C code.  On the few occasions when we
> are programming for "glass TTY" terminals (or emulators),
> we use the curses library, which isolates our application
> from the vagaries of terminal models.  (But more often, we
> use "dumb" text or else bitmap facilities.)  ESC itself has
> no role in portable programming.

First of all, why do you continue to insist that the only programming
worthy of consideration in the design of a language be "portable
programming?" I use ESC all the time. I write DOS/Windows command line apps
that expect to talk to ANSI displays or PCL printers. I write embedded code
that uses ANSI escapes to control LCD text displays.

But even so, there's a need for \e in portable programming as well, as I've
mentioned elsewhere. If I need to talk to a physical device that uses ASCII
ESC to introduce escape sequences, and I want the program to be portable to
an EBCDIC machine, which has an EBCDIC to ASCII translator somewhere
between the program and the device, then I need \e because I cannot
blithely include \x1B in the code. The same issue might arise with other
control characters (SI and SO for instance), but those are far less common
than ESC, which is the only reason no one is suggesting adding support for
them to the language.

--

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              ]

Pete Becker wrote:
>
> Try this thought experiment: suppose you've just bought a brand new
> compiler for your top of the line desktop workstation. The first thing
> you try is this program:
>
> #include <stdio.h>
>
> int main()
> {
> printf("Hello, world\n");
> printf("Hello, world\n");
> printf("Hello, world\n");
> return 0;
> }
>
> When you run it, at the top of the screen you see the following text:
>
>         Hello, worldHello, worldHello, world
>
> You call the compiler vendor to complain, and they explain that that
> half page of text describing the effects of escape sequences is merely
> advisory, and that the effect of using a newline character in a C
> program is, in fact, undefined, so they are being kind to you by
> ignoring it rather than crashing your system.

This is a red herring. Every two-dimensional text display _is_ capable of
interpreting newline in the conventional manner. But if I write "x\ty\tz"
to the screen, I have no right to expect that the compiler will do anything
in particular with the tab characters. I may see "xyz", as though tabs were
set at every character position, or "x       y       z", if they're set at
every eight character positions, or anything else. If I write "\f" to the
screen, it might clear the screen, or it might write a funny graphics
character, or it might do nothing. Newline is a special case, and the
library guarantees its behavior, because it, unlike all the rest of the
control characters, is absolutely necessary for communicating lines of text
among programs.

> > Yes, it can only be an implementation-defined shorthand. And the only
> > guaranteed feature of \v is exactly this: it produces a single char.
>
> Not if you're right that its behavior is undefined.

The compiler must translate backslash lower case v into a single character.
What that does when written to a device is undefined.

But here's where your argument about the standard requiring certain
behavior falls apart. If I write a \v to a disk file, I expect that binary
value to be written to the file. If I write a \a to a disk file, I don't
expect an audible or visible alert, I expect that binary value to be
written to the file.

> Be careful here: the "execution character set" is simply a bag holding
> all of the characters that the translator can use in code that it
> generates. It is not required to be all of the characters in some
> well-defined character standard. Saying that \e produces the escape
> character of the execution character set means only that it produces
> whatever character it produces.

Nobody writes compilers for anything other than "some well-defined
character standard." If the execution character set is ASCII, then \e must
produce the ASCII escape character. If it is EBCDIC, then \e must produce
the EBCDIC escape character. If it is some other character set, then it may
reformat your hard disk for all I care, because there are no other
character sets for which anyone will write a standard-conforming C++
compiler. But if I turn out to be wrong about that, then \e must OBVIOUSLY
produce the escape character for that character set if there is one, or
generate an error message otherwise.

--

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              ]

Paul Jarc wrote:
>
> > The claim that "there are no requirements for the existing \ characters"
> > is false. I've quoted the text of the C standard several times in
> > earlier messages to show the requirements that it imposes.
>
> And I've quoted you back, showing that those are not requirements at
> all.  I can't imagine why you're so reluctant to accept this.

It's simply because I'm not willing to ignore words that appear as
normative text in the standard. If you see a conflict between those
words and other words in the standard then the solution is to figure out
a meaning that accomodates both sets of words, not to pick the one you
like better and declare it the winner.

--
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 <37E7E0B8.1FF305C5@acm.org>,
Pete Becker  <petebecker@acm.org> wrote:
>
>Nick Maclaren wrote:
>>
>> No more than '\v'.  As I have posted before, there is a perfectly good,
>> portable specification of '\e', which is precisely the one specified
>> in ASCII.
>>
>>     Writing a '\e' character to a text stream has an implementation-
>>     defined effect.
>>
>> Please note that this is slightly MORE precise than the equivalent
>> specification of '\v' - and I speak as a user, third-party application
>> developer and implementor of C.
>
>I just don't see it. From the perspective of writing reasonably portable
>code, a character cosntant whose only constraint is that it "has an
>implementation-defined effect" cannot be used. A character constant
>whose effect is to "[move] the active position to the initial position
>of the next vertical tabulation position" is much more useful. If it
>doesn't do that with the compiler that you're using, complain to the
>vendor. They may have a good reason for not doing it on that particular
>platform, which is why the standard is written the way it is, but at
>least you have a shot at being able to use it.

You have missed two points:

    1) What IS "the next vertical tabulation position" in a context
where vertical tabulation is not defined?  Yes, I have implemented
C in such a context.

    2) There are many aspects of C that are completely unspecified
or even undefined, but are still regarded as useful (well, vaguely.)
I/O errors and signal handling, to name but two.


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 <rPuF3.10459$Jb.487734@newscene.newscene.com> "Al Stevens" <alstevens@midifitz.com> writes:
>Pete Becker wrote
>>Suppose I'm implementing the standard library on a system whose display
>>device is mapped to an 80x25 array of 16-bit storage cells that hold
>>character codes and color codes. I know how to write the code that deals
>>with \a, \t, \r, \v, etc. What code does this definition (or any other
>>proposed definition) require me to write to handle \e?
>
>It's not an issue for standard library implementors. It's an issue for
>device and display protocol driver implementors. As a standard library
>implementor, none of those characters should be your concern. It's up to a
>lower level of abstraction (BIOS, ANSI.SYS, curses, custom device driver,
>whatever) to decide where the next tab is, how to get the cursor to the
>first column of the next line, and so on, when they see one of those
>characters in the stream.
>
>"Implementation-defined" means just that. As a standard library implementor,
>you would do exactly whatever you would now do in the circumstance you
>described (and given the absense of support for '\e') when (assuming your
>display is an ASCII device) you write the code that deals with '\x1b'. Which
>is that you trust the programmers to know what they are doing and pass the
>characters along to the logical device. Just exactly as you would do with
>\t, \n, \v, \f, \r, \b.

I do not see the original post on this, but it seems to me that although
this would seem to be true for many systems, it doesn't have to be for all.
That is to say, to say it isn't an issue for lib implementors because they
should pass it along to the driver implies for instance that there is a
driver, but I don't see where the standard places any such constraint.
Therefore, although this might be rare, something such as a freestanding
app just might need to be concerned about this, and hence a lib implementor
too.  We have logical mapping but it can be physical too, at least I
believe so.  Like you say: it's implementation-defined.

- Greg
--
       Comeau Computing, 91-34 120th Street, Richmond Hill, NY, 11418-3214
     Producers of Comeau C/C++ 4.2.38 -- NOTE 4.2.42 BETAS NOW AVAILABLE
    Email: comeau@comeaucomputing.com / Voice:718-945-0009 / Fax:718-441-2310
                *** WEB: http://www.comeaucomputing.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              ]

"Greg Brewer" <nospam.greg@brewer.net> writes:
> Pete Becker <petebecker@acm.org> wrote in message
> news:37E7E27C.D4B61DC7@acm.org...
> > Here's a list of the things that you can't do with such a string:
> >
> > 1. write it to any device other than a disk (in particular you can't
> > display it on the screen)
> > 2. write it to disk as part of a text file
> > 3. read it from any device other than a disk
> >
> > It doesn't sound very useful.
>
> I agree with your list of cans; can't say the same with your list of can'ts.

Those things can certainly be done, but not portably, which was Pete's
point.  \v etc. are no more portable according to the standard, but he
refuses to accept this.


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              ]

"Greg Brewer" <nospam.greg@brewer.net> writes:
> Pete Becker <petebecker@acm.org> wrote in message
> news:37E7E53E.AF6C7667@acm.org...
> > If you write a string containing \t to stdout and the result is
> > that the output position moves to the top of the screen without
> > erasing the text that was already on the screen you're entitled to
> > complain, and insist that your compiler vendor make it work right.
>
> Huh!  So if I write a string containing \t to a file then go to the DOS
> prompt and use type to display that file and it behaves as you just
> described, I should call Inprise and complain?

No, the standard can't do anything about what happens when the
contents of your file, generated from a C program, are presented to a
display device from outside a C program.  The flaw in Pete's argument
is somewhere else.


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              ]

In article <7s8ohu$2bh7$1@news.hal-pc.org>, nospam.greg@brewer.net
says...

[ ... ]

> You are wrong.  A printer looking for ASCII escape characters will react
> properly to a valid EBCDIC string containing an EBCDIC escape character.  It
> will react properly because it will receive ASCII characters including an
> ASCII escape character.   Just as it will react properly when an EBCDIC 'A'
> is sent to the printer; it will receive an ASCII 'A'.

The question is what it'll really receive.  I'd expect (for example)
that if you connected (just to pick out random examples) a VT-100 (or
emulation thereof) to an IBM mainframe, it wouldn't just do a
character by character translation.  Instead, it'd have something to
emulate 3270 commands, and translate them to VT-100 commands.  e.g. if
you send the sequence that clears the screen on a 3270, it'd end up
clearing the screen on your VT-100.

Unfortunately, I don't see a \e (or whatever) built into the language
helping this much: you've still got to get complete strings that carry
out particular commands on a particular device, and those complete
strings are going to have to be translated to be of any real use, and
you're going to have to somehow figure out what strings correspond to
some particular piece of hardware before you can do that.

I suppose it's possible to hard-code these into a program, but offhand
that seems like just about the single worst possible way to do things.
While I realize that neither C nor C++ makes an attempt makes much
attempt at making a programmer do things in the best possible way, I
DO think it's a bit odd (at best) to standardize something that
appears useful ONLY in implementing what appears to be the worst
possible solution to a particular problem.

--
    Later,
    Jerry.

The Universe is a figment of its own imagination.
---
[ 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 <37E7FD5A.EE264133@acm.org>...
>
>Al Stevens wrote:
>> The appropriate place to be sending /e to a
>> printer is from a program at some level in the hierarchy--not necessarily
>> the application and not necessarily the device driver--that knows
>> specifically which printer it is dealing with and, presumably, which
>> character set. This is not a language issue.
>>
>
>Fine: you've defined away the question. Since you never need to send \e,
>you don't need a way of representing it.

If you are addressing me only as an applications programmer, that is
correct. But might I have another hat to wear?
---
[ 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              ]

17 Sep 99 04:33:05 GMT, scjones@thor.sdrc.com (Larry Jones)
added to the everexpanding, funguslike \e debate:

> David R Tribble (david@tribble.com) wrote [quoting the C89 Rationale]:
> >   The C89 Committee considered proposals to add the character
> >   constant '\e' to represent the ASCII ESC ('\033') character. This
> >   proposal was based upon the use of ESC as the initial character
> >   of most control sequences in common terminal driving disciplines
> >   such as ANSI X3.64. However, this usage has no obvious counterpart
> >   in other popular character codes such as EBCDIC.
> >
> > Which is a lie - EBCDIC damn well does contain every single control
> > character from ASCII, including ESC (0x27).  This comment also
> > implies, incorrectly, that "other popular character sets" all contain
> > a \v character.
>
> I raised the same objection.  The response was that it didn't say that
> the *character* has no obvious counterpart, but rather that the *usage*
> doesn't.  That is, no one uses escape sequences in an EBCDIC
> environment, they use channel control programs and other esoterica
> instead.  While this still isn't strictly true, it comes much closer.

I recall some device-control uses of ESC in EBCDIC, but
never the full X3.64 structure CSI param ; param cmd.
On the other hand, I have seen plenty of ASCII devices
use ESC in non-X3.64 ways too.

> (I still don't think it's a particularly good reason for rejecting the
> proposal, but the rules of the game are that the committee needs a good
> reason for accepting something, not for rejecting it.)
>
Stability is a good thing in a standard, though not the only
good thing.  I agree the proposed \e would be as adequately
defined as say \v, but it provides little benefit and the
alternatives work well enough; it's not worth the trouble.

- david.thompson at but not for trintech.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 in message <37E800AF.71C3EF8C@acm.org>...

>Sure it does. The C standard doesn't say that the execution character
>set has to be some pre-existing standard character set.

The C++ standard certainly implies this, i.e. that there is an execution
character set in existence at compile time. It would be pretty dizzy for it
to be otherwise.

> The execution
>character set is simply the set of characters that the compiler
>translates characters into when they are part of the executable code. So
>saying that \e must be the escape character in the execution character
>set is simply stating a truism. Whatever \e is translated to is, ipso
>facto, the escape character in the execution character set.

Which is exactly what everyone wants.

>It's usually convenient to translate \t into a value that the display
>driver will recognize as a tab character, but that is not required by
>the standard. What's required (or recommended, if you insist) is that a
>C string that contains the escape sequence \t have the effect of moving
>the cursor position to the next tab stop when that character is
>encountered.

In terms of the C++ standard this is dead wrong. Escape sequences are
character literals that correspond to exactly one character in the execution
character set. If the execution character set has an HT character, that's
what you get. The effect of that character (or of what \t gets translated
into) on the device it is shipped to _can't_ be specified at the language
level, since a single string could be output to multiple devices and
libraries, all of which handle tab differently.

I'd be seriously surprised if the C standard, despite defining the standard
behavior of these characters, implies or requires that \t be turned into
anything other than HT in the execution character set.

>> You're consistently confusing what the compiler does with what the
library,
>> device driver or device does.
>
>No, I'm not at all confused about these. I've been writing systems code
>for ten years.


And gotten yourself confused as to what the language does and what
systems do, apparently. The language represents data and outputs it to
libraries, devices whatever, which in turn interpret that data. The language
definition has no right to legislate what a given character will do. That's
the domain of the character set standard. Since most character set standards
include an HT equivalent, \t is a convenience.

(The complication here is that: the C standard limits escape sequences to
characters that correspond to "actions on display devices". Still, the C
standard still requires that a single escape sequence corresponds to a
single character in the string, so the bottom line is that those definitions
are nothing more than a wish list, since they are not binding on the
standards for the various execution character sets and devices that might
actually be used.)

> Ultimately an application programmer's concern is that
>the characters be displayed in the appropriate way.

The programmer's concern is that she is able to represent the bits
that she wants to represent. Whatever the C standard says, the bottom line
is that what the target of a string output by a program does is defined by
that target, not the C standard. Saying anything other than \t translates to
the execution character set code that corresponds to HT is meaningless.

>The place where the
>compiler and the OS meet is the runtime library. If the characters that
>the compiler generates aren't getting out on the display correctly the
>place to fix it is usually in the library. So, for example, that's where
>the single character represented by '\n' gets translated into the two
>characters CR and LF for a DOS system.

But this is (almost) right (there's no such character as NL, \n _is_ LF),
and is why if a programmer thinks she needs to send ESC to a library, the
language ought to provide it. In other words, the language's problem is to
represent the execution character set. The library's problem is to interpret
it.

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 <petebecker@acm.org> writes:
> When I recompile my printer driver with a compiler that targets EBCDIC
> it would stop working, because the printer is looking for '\033', and \e
> now means something else. I assume that that's not really what "most
> people would expect."

You mean like what would happen if you sent an 'A'? If your device is
expecting a particular character set, your program had better be using
the same one, or sending its output through a protocol converter!


[ 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 <37E7E0B8.1FF305C5@acm.org>...

>I just don't see it.

That part is true. <g>

>From the perspective of writing reasonably portable
>code, a character cosntant whose only constraint is that it "has an
>implementation-defined effect" cannot be used.

"Reasonably portable code" is not an issue when you are writing device- or
protocol-specific software.

>A character constant
>whose effect is to "[move] the active position to the initial position
>of the next vertical tabulation position" is much more useful. If it
>doesn't do that with the compiler that you're using, complain to the
>vendor.

Which vendor? The compiler should simply send whatever '\v' is on that
platform's character set to the printer (or driver). Are the compiler and
the library and the drivers and the printers all necessarily provided by the
same vendor?




[ 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 <37E7E53E.AF6C7667@acm.org>...

>If you write a
>string containing \t to stdout and the result is that the output
>position moves to the top of the screen without erasing the text that
>was already on the screen you're entitled to complain, and insist that
>your compiler vendor make it work right.

No, no, no, no, no. Not no, but heck, no. Given the following program, what
piece of code do you think generates the several spaces that display between
the 'a' and the 'b' on the console? Not the library and certainly not the
compiler. At least not in a well-designed compiler suite that builds for a
reasonable console-based target platform. I repeat, what to do with the
proposed \e beyond translating it in literals to a value specific to the
character set is not a language issue. I add that it is not a library issue
either.

#include <iostream>
main()
{
 std::cout << 'a' << '\t' << 'b' << '\n';
}

>> Why does it have to have a prescribed value, since, as you said, the
others
>> do not?
>
>Because that's what's being asked for.

Not in any of the messages I've read here. All that's been asked for is ESC
just as HT, FF, CR, etc. are supported. Those are not prescribed values.

And with that I will withdraw and give someone else the last word. As
someone said in another thread, these are issues about which reasonable
people can disagree. On this one I shall resign my position as president of
the dead horse molester's society and let someone else take over. <g>




[ 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 <37E6F2EA.BC2A01EE@acm.org>...

>Why should \a map to some particular value? The standard describes what
>effect it has. The value that's used to get that effect is noboby's
>business.

While the C++ standard has the good sense not to get into this, C90 clearly
defines the escape sequences as shorthands for control characters that "are
intended to produce actions on display devices". However, it also clearly
states that there is a one to one correspondence between escape sequences
and character codes in the execution character set, so both the C and C++
standards are explicit that \a must map to a particular value, namely alert
(BEL) in the execution character set.

Anyway, you are correct that the C standard states that escape sequences are
limited to representing character codes in the execution character set that
correspond to "actions on display devices".

This strikes me as a historical glitch. Syntactically and logically*, there
is no reason that escape sequences should be limited to such characters, and
since \e is clearly useful, it seems that this section needs to be
rewritten. The C++ standard, quite correctly, says nothing about "display
devices". Someone should write this up and send it in as a defect report to
the C committee. (I'm not volunteering because I don't follow C, only C++
discussions.)

*: Talking about "actions on display devices" and the definitions of those
actions are seriously inappropriate for a language standard. The langauge
should only talk about representing the execution character set and leave
how the execution character set is interpreted to the appropriate standards.

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              ]

In article <MPG.1251b4105e2c5af89896d5@news.mindspring.com>,
Jerry Coffin <jcoffin@taeus.com> wrote:
>
>In article <pgpmoose.199909220426.3665@murlibobo.cs.mu.OZ.AU>,
>nmm1@cus.cam.ac.uk says...
>
>[ ... ]
>
>> I am afraid that he was mistaken.  Firstly, EXACTLY the same problem
>> applies to every other character, printing and non-printing.  Secondly,
>> the standard ways of driving ASCII devices from EBCDIC systems always
>> have been via a translation table.  You therefore get the RIGHT result
>> if it is EBCDIC ESC and the WRONG result if it is ASCII ESC.  In
>> general, that is.
>
>This might or might not be correct.  In general it's pretty obvious
>that if somebody sends the code for (say) 'A' to the printer, they
>want it printed as an 'A', so that's what you translate to.  OTOH,
>with quite a few control characters, I'm less certain that the
>translation is nearly so obvious.

I was referring specifically to the EBCDIC to ASCII case.  The control
character translation has always been agreed, with NO variants, and
has been documented since the early 1970s.  The same is not true for
the printing characters.  And my description is precisely how TPUT
(the main place that this occurs) works.  I regret to say that I
cannot remember how ANSI labelled tapes were handled :-)

>In addition, you've still got the problem that there's not much you
>can reasonably DO with this, even if you're sure the correct
>translation (whatever that happens to be) takes place.

That is not true.  We drove graphics devices for years using precisely
that mechanism - and I ported several programs from other systems
that drove things like VT-100s from ASCII machines.  I got them at
least half-working with minimal changes using precisely the method
that I described.  And I was not the only person who did so, nor
was Cambridge the only site.

But I quite agree that there were some pretty horrible problems
lurking in dark corners waiting to jump out at you :-)


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 <37E7B6FE.EC014800@arl.mil>, Douglas A. Gwyn <gwyn@arl.mil> wrote:
>
>"Paul D. DeRocco" wrote:
>> One could wish, I suppose, for C escapes for all standard control
>> characters. However, I'm only suggesting \e for ESC because I think it's
>> the only one that doesn't already have a C escape, and that is commonly
>> used. I know I use it a lot.
>
>Well, there is one problem.  Scarcely anyone I know uses ESC
>in *any* form in his C code.  On the few occasions when we
>are programming for "glass TTY" terminals (or emulators),
>we use the curses library, which isolates our application
>from the vagaries of terminal models.  (But more often, we
>use "dumb" text or else bitmap facilities.)  ESC itself has
>no role in portable programming.

Nor does curses.  It assumes a particular terminal model that may be
the only one that you use, but is by no means the only one around
(even today.)  Yes, the curses library is THEORETICALLY a bit more
portable than the termcap/terminfo one, but in practice it isn't.
If you can't write a termcap/terminfo entry for a particular type of
terminal, you are unlikely to be able to use curses successfully.

This ignores the fact that curses is only HALF of a terminal access
mechanism, of course, and you have to hack up the input as best you
can.  And, if you are using a terminal model where interrupts are
first-level actions, then you have them to deal with them as well.

You are correct that ESC cannot be used portably.  But nor can VT
or even HT (despite the standard's claim in 7.19.2 paragraph 2).
But it can be DEFINED portably, at least up to the level of VT,
and its interpretation left as implementation-defined - which is
precisely the way that it was originally intended to be used!


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              ]

Pete Becker wrote in message <37E76BEE.FAD2BE8B@acm.org>...

>When I recompile my printer driver with a compiler that targets EBCDIC
>it would stop working, because the printer is looking for '\033', and \e
>now means something else. I assume that that's not really what "most
>people would expect."

It's certainly what I would expect. Since your hypothetical printer is
expecting ASCII, one would expect _every_ character in every character or
string constant (including the printing characters) in your driver to have
the wrong value. That's what "targets EBCDIC" means. In particular, not only
are the escape sequences aliases for single characters in the execution set,
all the other characters that appear in a character string constant are
aliases for code values as defined by the execution set.

The other thing that "targets EBCDIC" means is that when you apply isupper()
to data that your clients send you, it does the wrong thing if your clients
send you ASCII.

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              ]

In article <37E3C3F2.390C6BAE@acm.org>,
Pete Becker  <petebecker@acm.org> wrote:
>Kai Henningsen wrote:
>>
>> petebecker@acm.org (Pete Becker)  wrote on 14.09.99 in <37DE5025.A1D9E60E@acm.org>:
>>
>> > Kai Henningsen wrote:
>> > >
>> > > francis@robinton.demon.co.uk (Francis Glassborow)  wrote on 11.09.99 in
>> > > <egKSkRA3Dj23EwF$@robinton.demon.co.uk>:
>> > >
>> > > > BTW exactly what would be the definition of \e?  I know exactly what \a,
>> > > > \t etc. do (even though some systems may provide trivial meanings to
>> > > > some of them)
>> > >
>> > > Does that "etc." include \v? And can you explain to me what, exactly, \v
>> > > does in any kind of non-printer context?
>> > >
>> > > \e would be the codeset escape function. I certainly know what *that* is.
>> >
>> > Do you? Please explain what '\e' would do.
>>
>> How many times do you want me to repeat that definition?
>
>I don't want you to repeat it at all. I want you to tell me what \e
>does, so that as a library implementor I can do a reasonable job of
>writing code to implement it.

Oh, for heaven's sake!  The ASCII specification says that it does
something implementation-defined.  Choose some action, such as ignoring
the next N characters where N is the time in seconds since the last
minute, or executing the HCF instruction (Halt and Catch Fire), and
document it.

There has never been a serious proposal to specify the behaviour of
'\e' in the C standard - merely to define the escape sequence.  The
same sort of remark applies to '\v', because there are plenty of
systems where the behaviour on receiving one of those is definitely
arbitrary - e.g. MVS output to the usual files with either ANSI or
no control characters.


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              ]

Pete Becker <petebecker@acm.org> writes:
> Paul Jarc wrote:
> > You handle \e however you like, the same as for the others.  You
> > aren't *required* to do anything in particular with the others, so why
> > do you expect a requirement for \e?
>
> If someone puts \t into a character string and my code clears the
> screen, they're going to complain loudly and justifiably. First, because
> it's not what most people expect \t to mean, and second, because the C
> standard describes what this ought to do. I'm not convinced that there
> is no requirement whatsoever here, but even if there isn't, hiding
> behind legalisms is a good way to go bankrupt.

All you've said is that it's not commercially viable to surprise the
user.  No one said anything to the contrary.  Handle \e the way your
users expect it to be handled.  That's what you do for the others.  I
repeat: why do you expect a requirement for \e?


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              ]

In article <37E3C668.E219EA07@acm.org>, Pete Becker <petebecker@acm.org>
writes
>Maybe. But ultimately it seems to me that this boils down to a request
>that '\e' be shorthand for '033'. I don't see any reasonable way to give
>it more content than that. That's only useful with the ASCII codeset,
>and it provides very little benefit even then.

Actually I think it is worse than that.  One common use of ESC is to
prefix info being sent to a printer.  The correct code is dependent on
the printer and not on the platform you are using.  I can imagine
programmers getting into serious confusion by assuming that \e was the
same as an ASCII ESC in all circumstances.  If you need to send 033 to
your printer it will not help if this is replaced by the EBCDIC code for
ESC.




Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ 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:
> > > You handle \e however you like, the same as for the others.  You
> > > aren't *required* to do anything in particular with the others, so why
> > > do you expect a requirement for \e?
> >
> > If someone puts \t into a character string and my code clears the
> > screen, they're going to complain loudly and justifiably. First, because
> > it's not what most people expect \t to mean, and second, because the C
> > standard describes what this ought to do. I'm not convinced that there
> > is no requirement whatsoever here, but even if there isn't, hiding
> > behind legalisms is a good way to go bankrupt.
>
> All you've said is that it's not commercially viable to surprise the
> user.  No one said anything to the contrary.  Handle \e the way your
> users expect it to be handled.  That's what you do for the others.

No, for "the others" I do what the standard says I should do. What
should I do for \e? Poll users to figure out what they think the
definition is?

> I repeat: why do you expect a requirement for \e?
>

Because a standard imposes requirements. That's what it's for.

--
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:
>
> No, for "the others" I do what the standard says I should do. What
> should I do for \e? Poll users to figure out what they think the
> definition is?

\e should translate into the character set's escape character. This is \x1B
for ASCII, \x26 for EBCDIC. If the character set doesn't have an escape
character (if such a character set actually exists), then generate an error
message.

--

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              ]

Pete Becker wrote:
>
> Once again, condensed from the C standard:
>
>     \a (alert) Produces an audible or visible alert.
>     \b (backspace) Moves the actrive position to the previous position on
>         the current line.
>     \f (form feed) Moves the active position to the initial position at
>         the start of the next logical page.
>     \n (new line) Moves the active position to the initial position of
>         the next line.
>     \r (carriage return) Moves the active position to the initial
>         position of the current line.
>     \t (horizontal tab) Moves the active position to the next horizontal
>         tabulation position on the current line.
>     \v (vertical tab) Moves the active position to the initial position
>         of the next vertical tabulation position.

I don't believe these clauses require that such a construct in a string
_must_ actually do those things. In some environment, it may, for instance,
be impossible to do one or more of those things without generating more
than one character, while the above constructs must translate into single
character codes. (In fact, many real-world environments turn \n into a line
feed without a carriage return, in binary mode, requiring \r\n to do both.)
The standard is merely saying that each construct translates into the
single character code from the character set that conventionally has the
described function.

I don't think anyone would actually have any trouble should \e be added,
described as "Introduces an escape sequence." Everyone knows what that
means. If a particular data consumer doesn't understand any escape
sequences, one wouldn't have any reason to put \e into a string; similary,
if a data consumer doesn't have vertical tab stops, one wouldn't have any
reason to put \v into a string.

--

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              ]

Francis Glassborow wrote:
>
> Actually I think it is worse than that.  One common use of ESC is to
> prefix info being sent to a printer.  The correct code is dependent on
> the printer and not on the platform you are using.  I can imagine
> programmers getting into serious confusion by assuming that \e was the
> same as an ASCII ESC in all circumstances.  If you need to send 033 to
> your printer it will not help if this is replaced by the EBCDIC code for
> ESC.

But this is no worse than the situation for printable characters. If I
write a C or C++ program containing "X", compile it for an EBCDIC machine,
and send the output to an ASCII printer, I'm assuming that there's a device
driver that's doing EBCDIC to ASCII conversion. I would expect it to do the
same thing for EBCDIC ESC as I would for EBCDIC "X", which is to say,
translate it into the ASCII equivalent.

--

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              ]

Pete Becker wrote:
>
> I don't want you to repeat it at all. I want you to tell me what \e
> does, so that as a library implementor I can do a reasonable job of
> writing code to implement it.

I don't think it has anything to do with library implementation. I've never
seen a C or C++ standard library that attempted to do anything with \t,
other than pass it through to the OS device driver. In fact, the library
really couldn't "obey" tabs without either providing a standard means for
setting tabs, or providing a standard fixed set of tab stops.

The only exception to this is the processing of \n. This is a special case,
because every text output system (beyond a single-line display) needs a
means of starting a new line, while only some need escapes or vertical
tabs, and there are several widely-used standards for starting a new line.

Other than that, the meanings of the backslash escapes are only an issue
for the compiler writer, and then only a problem if the execution character
set lacks a suitable single character for the function that the backslash
escape is supposed to represent. This, however, is a mythical problem, not
a real one.

--

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              ]

Pete Becker wrote:
>
> Hyman Rosen wrote:
> >
> > Pete Becker <petebecker@acm.org> writes:
> > > I've been reading the C standard. Too bad the C++ standard screwed it
> > > up. <g> So what do you take this to mean if the platform's character set
> > > does not define NL, HT, VT, etc.?
> >
> > I don't take it to mean anything. Presumably the implementation on such
> > a platform would ascribe some meaning to them.
>
> Well, you can't say both that it doesn't mean anything and that the
> implementation is free to do whatever it wants. Either it's
> implementation-specific or it isn't. Choose one. <g>
>
> >
> > > Defined as what? That is, what should the implementation do if there is
> > > no character whose name is ESC?
> >
> > The same thing it does when there is no character whose name is BEL :-)
>
> The C standard says: "\a (alert) Produces an audible or visual alert."
>
> > Since the Standard didn't see fit to further specify the behavior, I
> > don't either. At worst, the implementation would just assign \e to be
> > some arbitrary control character, or a printing character outside of
> > the usual 96.
> >
>
> So you'd find it acceptable for \e to be mapped, for example, to \a, and
> produce an alert, and then to display the rest of the escape sequence as
> ordinary characters?

As acceptable as I find it for \t being two thousand spaces,
\v being two hundred lines and \a putting an "alert" dialog
box onto the screen.

I'd expect implementors to do something reasonable where
possible. So for purely ASCII systems, I'd expect \e just
to map to \x1B, just as I expect \a to map to \x07. Of course
an implementation could as well map \a to \x80 (and produce
an alert on that), however I'd not like that on ASCII systems
where a BEL character (\x07) is already defined.

On systems where the character set doesn't include an escape
character, one reasonable action would be to ignore that
character completely. Another reasonable action would be to
interpret is as if it were an escape character, and produce
f.ex. an VT100 compatible behaviour. Another reasonable
behaviour would be to just make \e map to some printable
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> wrote in message
news:RwaSEWLNnr43Ew1e@romana.davros.org...
>
> In article <7roqa9$a8i$1@news.hal-pc.org>, Greg Brewer
> <nospam.greg@brewer.net> writes
> >Well, you threw away everything I wanted to standardize then tell me that it
> >is a bad candidate for standardization.
> Exactly.

Darn, I was hoping one of us was missing something.  Actually, one of us is
but I'm not starting a flame war.

> >I even grant that the 50,
> >33, and 66 values may not be good values to use in most cases.
>
> Okay, so they need parameterising. You've just admitted that your
> function isn't any use in most cases.

No, it doesn't.  It needs discussion and the results of the discussion
should produce values that will form the standard.  If the standard doesn't
meet your needs, write your own function.

> >I think that a
> >standard function would result in the uniform operation of everyone's code.
> >If the standard does not meet an individual need then don't use the standard
> >function; write your own.
> This is an area where it is really bad to have "uniform operation". The
> problem of handling 2 digit dates is one that programmers have to
> *think* about, not just pick a quick answer off the shelf. So they
> should at the very least be thinking about the boundaries for switching,
> not just saying "50, 33, and 66" for everything.

How so?  I expect standard values would work in >90% of all cases.
Programmers would have to "*think*" about whether the standard values meet
their needs.  Most of the functions I have written are all over the place
depending totally on my mood at the time.  I would expect this to be common.
I think the users of my software would benefit if I had to decide whether
the standard values did the job or if a deviation was in order rather than
just me coming up with some arbitrary date because I can't remember the last
one I used.

> >It occurs to me that if you are entering a value in a calendar
> >program then converting a 2 digit year to a 4 digit year using a +/- 50 year
> >range centering on the current year makes sense.
>
> I disagree. If I'm entering something into *my* calendar, I won't be
> interested in dates before I was born. I probably won't be interested in
> dates before last year.

Okay, but you might be more interested in a year 5 years ago instead of a
year 95 years in the future.  You are older than 5 aren't you?

> And this is the whole point - *every* use of dates has to be thought
> about, and there is no one right solution.

No, but there are solutions that fit the vast majority of the cases!

Greg Brewer


[ 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:
> Al Stevens wrote:
> > Could you point me to those places I overlooked where that behavior is
> > specified?
>
> From the ANSI C standard, cl. 2.2.2:
>
>     \a (alert) Produces an audible or visible alert. The active position shall
>      not be changed.
>
>     \b (backspace) Moves the active position to the previous position on the
>      current line. If the active position is at the initial position of
>      a line, the behavior is unspecified.
>     ....

But the beginning of that paragraph, which you have consistently
ignored, says (in C9X 5.2.2p2):

# Alphabetic escape sequences representing nongraphic characters in
# the execution character set are intended to produce actions on
# display devices as follows:

What you quoted does *not* define how these escape sequences are
handled.  It specifies intent only.


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              ]

In article <7roqa9$a8i$1@news.hal-pc.org>, Greg Brewer
<nospam.greg@brewer.net> writes
>> So we now have a function which can be written in portable code in about
>> 10% of the space required to actually describe it fully. Not a good
>> candidate for standardisation.
>
>Well, you threw away everything I wanted to standardize then tell me that it
>is a bad candidate for standardization.

Exactly.

>I even grant that the 50,
>33, and 66 values may not be good values to use in most cases.

Okay, so they need parameterising. You've just admitted that your
function isn't any use in most cases.

>I think that a
>standard function would result in the uniform operation of everyone's code.
>If the standard does not meet an individual need then don't use the standard
>function; write your own.

This is an area where it is really bad to have "uniform operation". The
problem of handling 2 digit dates is one that programmers have to
*think* about, not just pick a quick answer off the shelf. So they
should at the very least be thinking about the boundaries for switching,
not just saying "50, 33, and 66" for everything.

>It occurs to me that if you are entering a value in a calendar
>program then converting a 2 digit year to a 4 digit year using a +/- 50 year
>range centering on the current year makes sense.

I disagree. If I'm entering something into *my* calendar, I won't be
interested in dates before I was born. I probably won't be interested in
dates before last year.

And this is the whole point - *every* use of dates has to be thought
about, and there is no one right solution.

--
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 <37E004CE.CE5DCF91@ix.netcom.com>, Paul D. DeRocco
<pderocco@ix.netcom.com> writes
>> Yes. In a codeset using the shift-out and shift-in concept for switching
>> between character sets, there are two different codes (14 and 15 in
>> ASCII) with that meaning.
>>
>> On a BBC micro - an ASCII based system - there are six or seven codes
>> that have that meaning [*]. Curiously 27 isn't one of them.
>>
>> [*] Plus, in some screen modes, another 25 or so.
>
>Why are we making this so difficult? In ASCII there is an ESC character. In
>EBCDIC there is an ESC character. I don't believe there are any other
>execution character sets, for which anyone will actually write a C++
>compiler, that don't have an ESC character.

I've programmed in C for a BBC micro based system. It doesn't have an
ESC character.

> If I'm wrong about this, then
>I'd be surprised if this character set I'm as yet unaware of didn't also
>have analogous problems with other missing control characters that are
>already mentioned in the C++ standard.

It had alert, carriage return, newline, and backspace. Tabs - both
horizontal and vertical - were at every character position, but it
distinguished between space (overwrites) and tab (doesn't).

>I've got modules in production code that have literally hundreds of
>instances of \x1B in strings

What's wrong with:

    #define ESC "\x1B"

for ASCII, if that's what you're on ?

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

petebecker@acm.org (Pete Becker)  wrote on 16.09.99 in <37E0F7C9.9B295B80@acm.org>:

> Al Stevens wrote:
> >
> > Pete Becker wrote in message <37DE5025.A1D9E60E@acm.org>...
> > >Complete the following
> > >paragraph (paraphrased from the C standard):
> > >
> > >'\a' produces an audible or visible alert. '\b' moves the active
> > >position to the previous position on the current line. '\f' moves the
> > >active position to the initial position at the start of the next logical
> > >page. '\n' moves the active position to the initial position of the next
> > >line. '\r' moves the active position to the initial position of the
> > >current line. '\t' moves the active position to the next horizontal
> > >tabulation position on the current line. '\v' moves the active positon
> > >to the initial position of the next vertical tabulation position. '\e'
> > >.....
> >
> > ....introduces a sequence of characters to be interpreted (in any
> > herein-undefined manner) by the printer/plotter/display device or by the
> > protocol language that serves as a device-independent layer between the
> > program and the device.
>
> Suppose I'm implementing the standard library on a system whose display
> device is mapped to an 80x25 array of 16-bit storage cells that hold
> character codes and color codes. I know how to write the code that deals
> with \a, \t, \r, \v, etc. What code does this definition (or any other
> proposed definition) require me to write to handle \e?

You know that?

What do you do for \a?

What do you do for \t?

What do you do for \v?

How do you now these things?

And why don't you know what to do for \e the exact same way you know this
other stuff?

Kai
--
http://www.westfalen.de/private/khms/
"... by God I *KNOW* what this network is for, and you can't have it."
  - Russ Allbery (rra@stanford.edu)


[ 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@on-the-train.demon.co.uk (Clive D.W. Feather)  wrote on 15.09.99 in <QxBC0IHch533EwtJ@romana.davros.org>:

> In article <7Os69jVHw-B@khms.westfalen.de>, Kai Henningsen
> <kaih=7Os69jVHw-B@khms.westfalen.de> writes
> >IMHO, it would have been *far* saner to say "IF the execution character
> >set is (ASCII, ISO 646, something like that), THEN these escape sequences
> >map to the following control characters (NOT effects); for other character
> >sets, the meaning is implementation-defined".
>
> No it wouldn't. They weren't trying to write an ASCII-only Standard.

Nor would the result *be* an ASCII-only standard.


Kai
--
http://www.westfalen.de/private/khms/
"... by God I *KNOW* what this network is for, and you can't have it."
  - Russ Allbery (rra@stanford.edu)


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

petebecker@acm.org (Pete Becker)  wrote on 14.09.99 in <37DE5025.A1D9E60E@acm.org>:

> Kai Henningsen wrote:
> >
> > francis@robinton.demon.co.uk (Francis Glassborow)  wrote on 11.09.99 in
> > <egKSkRA3Dj23EwF$@robinton.demon.co.uk>:
> >
> > > BTW exactly what would be the definition of \e?  I know exactly what \a,
> > > \t etc. do (even though some systems may provide trivial meanings to
> > > some of them)
> >
> > Does that "etc." include \v? And can you explain to me what, exactly, \v
> > does in any kind of non-printer context?
> >
> > \e would be the codeset escape function. I certainly know what *that* is.
>
> Do you? Please explain what '\e' would do.

How many times do you want me to repeat that definition?

>Complete the following
> paragraph (paraphrased from the C standard):
>
> '\a' produces an audible or visible alert. '\b' moves the active
> position to the previous position on the current line. '\f' moves hte
> active position to the initial position at the start of the next logical
> page. '\n' moves the active position to the initial position of the next
> line. '\r' moves the active position to the initial position of the
> current line. '\t' moves the active position to the next horizontal
> tabulation position on the current line. '\v' moves the active positon
> to the initial position of the next vertical tabulation position. '\e'
> .....

ESC is used for code extension purposes. It causes the meanings of a
limited number of bit combinations following it in the data stream to be
changed.

(This is from ECMA-48, a.k.a. ISO/IEC 6429.)

Kai
--
http://www.westfalen.de/private/khms/
"... by God I *KNOW* what this network is for, and you can't have it."
  - Russ Allbery (rra@stanford.edu)


[ 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:
>
> I've programmed in C for a BBC micro based system. It doesn't have an
> ESC character.
>
> > If I'm wrong about this, then
> >I'd be surprised if this character set I'm as yet unaware of didn't also
> >have analogous problems with other missing control characters that are
> >already mentioned in the C++ standard.
>
> It had alert, carriage return, newline, and backspace. Tabs - both
> horizontal and vertical - were at every character position, but it
> distinguished between space (overwrites) and tab (doesn't).

Interesting. What is a BBC micro, and where can I get info on it? I'd like
to see what it's character set is.

> >I've got modules in production code that have literally hundreds of
> >instances of \x1B in strings
>
> What's wrong with:
>
>     #define ESC "\x1B"
>
> for ASCII, if that's what you're on ?

I might as well just type out \x1B, or for that matter \xC for form feed.
But this is harder to type and harder to read. And hex escapes are
error-prone because they may inadvertently be followed by hex digits. For
instance, PCL, HP's printer control language, uses esc 9 for margin release
and esc E for reset. If I type "\x1B9" or "\x1BE" I don't get what I
expect; I have to write "\x1B" "9" or "\x1B" "E". It would be easier and
more readable to type "\e9" or "\eE".

Another reason for preferring \e is that one might wish to port to an
EBCDIC machine a program that generates ASCII escape sequences. If I write
a program that generates text that is to be consumed by an ASCII machine,
and I compile and run it on an EBCDIC machine, I would expect to be able to
write the quoted string "Hi, mom!" in the code, and have some magic module,
either in the library or in the OS, translate the character codes from
EBCDIC to ASCII. This remains true even if there's a BEL, TAB, or CR in the
string--or an ESC. If I have to write \x1B in a program that will run on an
EBCDIC machine, then I'm obviously not using some separate EBCDIC to ASCII
translation module, and I therefore can't write "Hi, mom!" either.

One could wish, I suppose, for C escapes for all standard control
characters. However, I'm only suggesting \e for ESC because I think it's
the only one that doesn't already have a C escape, and that is commonly
used. I know I use it a lot. I don't have to port my stuff to EBCDIC, but
I'd still like the readability of \e.

--

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              ]

Paul Jarc wrote:
>
> Pete Becker <petebecker@acm.org> writes:
> > Al Stevens wrote:
> > > Could you point me to those places I overlooked where that behavior is
> > > specified?
> >
> > From the ANSI C standard, cl. 2.2.2:
> >
> >     \a (alert) Produces an audible or visible alert. The active position shall
> >           not be changed.
> >
> >     \b (backspace) Moves the active position to the previous position on the
> >           current line. If the active position is at the initial position of
> >           a line, the behavior is unspecified.
> >     ....
>
> But the beginning of that paragraph, which you have consistently
> ignored, says (in C9X 5.2.2p2):
>
> # Alphabetic escape sequences representing nongraphic characters in
> # the execution character set are intended to produce actions on
> # display devices as follows:
>
> What you quoted does *not* define how these escape sequences are
> handled.  It specifies intent only.
>

Sigh. Yes, that's what it says, and all the rest are mere words that any
implementor is free to ignore at their peril. The fact is that every
library implementor on every platform where these operations are
possible tries to implement what those words say.

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

Kai Henningsen wrote:
>
> petebecker@acm.org (Pete Becker)  wrote on 14.09.99 in <37DE5025.A1D9E60E@acm.org>:
>
> > Kai Henningsen wrote:
> > >
> > > francis@robinton.demon.co.uk (Francis Glassborow)  wrote on 11.09.99 in
> > > <egKSkRA3Dj23EwF$@robinton.demon.co.uk>:
> > >
> > > > BTW exactly what would be the definition of \e?  I know exactly what \a,
> > > > \t etc. do (even though some systems may provide trivial meanings to
> > > > some of them)
> > >
> > > Does that "etc." include \v? And can you explain to me what, exactly, \v
> > > does in any kind of non-printer context?
> > >
> > > \e would be the codeset escape function. I certainly know what *that* is.
> >
> > Do you? Please explain what '\e' would do.
>
> How many times do you want me to repeat that definition?

I don't want you to repeat it at all. I want you to tell me what \e
does, so that as a library implementor I can do a reasonable job of
writing code to implement it.

>
> >Complete the following
> > paragraph (paraphrased from the C standard):
> >
> > '\a' produces an audible or visible alert. '\b' moves the active
> > position to the previous position on the current line. '\f' moves hte
> > active position to the initial position at the start of the next logical
> > page. '\n' moves the active position to the initial position of the next
> > line. '\r' moves the active position to the initial position of the
> > current line. '\t' moves the active position to the next horizontal
> > tabulation position on the current line. '\v' moves the active positon
> > to the initial position of the next vertical tabulation position. '\e'
> > .....
>
> ESC is used for code extension purposes. It causes the meanings of a
> limited number of bit combinations following it in the data stream to be
> changed.
>
> (This is from ECMA-48, a.k.a. ISO/IEC 6429.)
>

There's a vast difference between the definitions from the C standard,
which tell you exactly what the expected behavior is, and this
description of ESC, which doesn't say anything about what should be done
when it is encountered.

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

Kai Henningsen wrote:
>
> petebecker@acm.org (Pete Becker)  wrote on 16.09.99 in <37E0F7C9.9B295B80@acm.org>:
>
> > Al Stevens wrote:
> > >
> > > Pete Becker wrote in message <37DE5025.A1D9E60E@acm.org>...
> > > >Complete the following
> > > >paragraph (paraphrased from the C standard):
> > > >
> > > >'\a' produces an audible or visible alert. '\b' moves the active
> > > >position to the previous position on the current line. '\f' moves the
> > > >active position to the initial position at the start of the next logical
> > > >page. '\n' moves the active position to the initial position of the next
> > > >line. '\r' moves the active position to the initial position of the
> > > >current line. '\t' moves the active position to the next horizontal
> > > >tabulation position on the current line. '\v' moves the active positon
> > > >to the initial position of the next vertical tabulation position. '\e'
> > > >.....
> > >
> > > ....introduces a sequence of characters to be interpreted (in any
> > > herein-undefined manner) by the printer/plotter/display device or by the
> > > protocol language that serves as a device-independent layer between the
> > > program and the device.
> >
> > Suppose I'm implementing the standard library on a system whose display
> > device is mapped to an 80x25 array of 16-bit storage cells that hold
> > character codes and color codes. I know how to write the code that deals
> > with \a, \t, \r, \v, etc. What code does this definition (or any other
> > proposed definition) require me to write to handle \e?
>
> You know that?
>
> What do you do for \a?
>
> What do you do for \t?
>
> What do you do for \v?
>
> How do you now these things?
>

Once again, condensed from the C standard:

    \a (alert) Produces an audible or visible alert.
    \b (backspace) Moves the actrive position to the previous position on
 the current line.
    \f (form feed) Moves the active position to the initial position at the start
 of the next logical page.
    \n (new line) Moves the active position to the initial position of the next line.
    \r (carriage return) Moves the active position to the initial position
of
 the current line.
    \t (horizontal tab) Moves the active position to the next horizontal tabulation
 position on the current line.
    \v (vertical tab) Moves the active position to the initial position of the next
 vertical tabulation position.

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

Al Stevens wrote:
>
> >> ....introduces a sequence of characters to be interpreted (in any
> >> herein-undefined manner) by the printer/plotter/display device or by the
> >> protocol language that serves as a device-independent layer between the
> >> program and the device.
> >
> >Suppose I'm implementing the standard library on a system whose display
> >device is mapped to an 80x25 array of 16-bit storage cells that hold
> >character codes and color codes. I know how to write the code that deals
> >with \a, \t, \r, \v, etc. What code does this definition (or any other
> >proposed definition) require me to write to handle \e?
>
> Anything or nothing. Same as for the others. You "know how to write the
> code" only because you know by convention and tradition what those
> characters mean, but not because the standard specifies their behavior when
> sent to a display device.
>
> For example, where does the standard require you to provide any specific
> behavior for /v other than to treat it as white space?

Christopher Eltschka wrote:
>
> John Hauser wrote:
> >
> > Paul Jarc:
> > > You tell me exactly what you mean by a vertical tab.
> >
> > It's like a horizontal tab (\t), only in the vertical direction.  It
> > introduces some implementation-defined amount of vertical whitespace
> > (possibly none).  The safest use would presumably always follow '\n',
> > as in "First line.\n\vSecond line.\n".
> >
> > Now you tell us exactly what you mean by an escape (\e).
>
> \e means that the implementation may interpret an implementation
> defined (not necessarily fixed) number of following characters
> in an implementation defined way on output.
> It makes sense to put restrictions on some of the standard
> streambufs (f.ex. that stringstreambuf may _not_ interpret
> them) and corresponding stdio functions (like sprintf).

This is a description, not a specification. That is, an implementation
that interpreted the first character following \e as a request to reboot
the system satisfies these requirements. I suspect that folks have
something a little narrower in mind.

>
> Usually the interpretation will be done by the external device
> (terminal/terminal emulator, printer),

But then the behavior depends on the particular device that the code is
talking to, which makes it impossible for the implementor to predict
what will happen. So the characters following \e cannot be interpreted
"in an implementation defined way," because the implementation cannot
define what the behavior is.

>but it may be done by
> the I/O library itself (f.ex., a C++ compiler could decide to
> emulate VT100 on non-VT100 devices).
>

Maybe. But ultimately it seems to me that this boils down to a request
that '\e' be shorthand for '033'. I don't see any reasonable way to give
it more content than that. That's only useful with the ASCII codeset,
and it provides very little benefit even then.

--
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:
> > Al Stevens wrote:
> > > [\e] introduces a sequence of characters to be interpreted (in any
> > > herein-undefined manner) by the printer/plotter/display device or by the
> > > protocol language that serves as a device-independent layer between the
> > > program and the device.
> >
> > I know how to write the code that deals with \a, \t, \r, \v,
> > etc. What code does this definition (or any other proposed
> > definition) require me to write to handle \e?
>
> You handle \e however you like, the same as for the others.  You
> aren't *required* to do anything in particular with the others, so why
> do you expect a requirement for \e?
>

If someone puts \t into a character string and my code clears the
screen, they're going to complain loudly and justifiably. First, because
it's not what most people expect \t to mean, and second, because the C
standard describes what this ought to do. I'm not convinced that there
is no requirement whatsoever here, but even if there isn't, hiding
behind legalisms is a good way to go bankrupt.

--
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:
> > So you'd find it acceptable for \e to be mapped, for example, to \a, and
> > produce an alert, and then to display the rest of the escape sequence as
> > ordinary characters?
>
> I would rather that \e was not equal to any other \c (single letter)
> value. I would definitely find it acceptable for the remainder of
> the characters to be displayed normally. Remember that in the vast
> majority of implementations (perhaps even all of them), the special
> characters are simply output through low level calls without any
> special handling whatsoever. Even in MS environments where \n turns
> into two characters on certain output streams, that translation is
> handled transparently by low level read and write calls which the
> C and C++ runtime uses.

Err, umm, well, the part that you snipped was when you said:

> At worst, the implementation would just assign \e to be
> some arbitrary control character, or a printing character outside of
> the usual 96.

I take it that this proposed definition is no longer proposed?

--
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:
> I've been reading the C standard. Too bad the C++ standard screwed it
> up. <g> So what do you take this to mean if the platform's character set
> does not define NL, HT, VT, etc.?

I don't take it to mean anything. Presumably the implementation on such
a platform would ascribe some meaning to them.

> Defined as what? That is, what should the implementation do if there is
> no character whose name is ESC?

The same thing it does when there is no character whose name is BEL :-)
Since the Standard didn't see fit to further specify the behavior, I
don't either. At worst, the implementation would just assign \e to be
some arbitrary control character, or a printing character outside of
the usual 96.


[ 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:
> > I've been reading the C standard. Too bad the C++ standard screwed it
> > up. <g> So what do you take this to mean if the platform's character set
> > does not define NL, HT, VT, etc.?
>
> I don't take it to mean anything. Presumably the implementation on such
> a platform would ascribe some meaning to them.

Well, you can't say both that it doesn't mean anything and that the
implementation is free to do whatever it wants. Either it's
implementation-specific or it isn't. Choose one. <g>

>
> > Defined as what? That is, what should the implementation do if there is
> > no character whose name is ESC?
>
> The same thing it does when there is no character whose name is BEL :-)

The C standard says: "\a (alert) Produces an audible or visual alert."

> Since the Standard didn't see fit to further specify the behavior, I
> don't either. At worst, the implementation would just assign \e to be
> some arbitrary control character, or a printing character outside of
> the usual 96.
>

So you'd find it acceptable for \e to be mapped, for example, to \a, and
produce an alert, and then to display the rest of the escape sequence as
ordinary characters?

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

>Under the C standard, the effect of writing '\e' in a character string
>is undefined. Under this definition it produces undefined results if
>it's sent to a display device. I don't think that's much of an
>improvement. In either case, if your vendor tells you what '\e' does on
>their system you can use it, and if they don't, you can't.


Pete, you're losing me here. Under the C and C++ standards the definitions
of *all* the \x characters produce undefined results if they are sent to a
display device. Nowhere (that I've found) does the standard say what effect
\v or any of the others has when sent to a display device. The standard kind
of says what effect they have when you code them in a string or character
literal but not completely because the standard cannot specify the value of
the resulting character without tying them to specific character sets. It
uses conventional names such as BEL, HT, and FF, but it assigns no values or
behavior to them other than to say "alert," "backspace," etc. Those are only
names; they do not specify behavior. The standard says things about how
std::endl inserts a newline into the stream, for example, but it says
nothing (that I have found) about what effect the newline has on the
display. I fail to see what there is about \e that would be any different.
Could you point me to those places I overlooked where that behavior is
specified?




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

Al Stevens wrote:
>
> >Under the C standard, the effect of writing '\e' in a character string
> >is undefined. Under this definition it produces undefined results if
> >it's sent to a display device. I don't think that's much of an
> >improvement. In either case, if your vendor tells you what '\e' does on
> >their system you can use it, and if they don't, you can't.
>
> Pete, you're losing me here. Under the C and C++ standards the definitions
> of *all* the \x characters produce undefined results if they are sent to a
> display device. Nowhere (that I've found) does the standard say what effect
> \v or any of the others has when sent to a display device. The standard kind
> of says what effect they have when you code them in a string or character
> literal but not completely because the standard cannot specify the value of
> the resulting character without tying them to specific character sets. It
> uses conventional names such as BEL, HT, and FF, but it assigns no values or
> behavior to them other than to say "alert," "backspace," etc. Those are only
> names; they do not specify behavior. The standard says things about how
> std::endl inserts a newline into the stream, for example, but it says
> nothing (that I have found) about what effect the newline has on the
> display. I fail to see what there is about \e that would be any different.
> Could you point me to those places I overlooked where that behavior is
> specified?

Pete Becker <petebecker@acm.org> writes:
> Al Stevens wrote:
> > [\e] introduces a sequence of characters to be interpreted (in any
> > herein-undefined manner) by the printer/plotter/display device or by the
> > protocol language that serves as a device-independent layer between the
> > program and the device.
>
> I know how to write the code that deals with \a, \t, \r, \v,
> etc. What code does this definition (or any other proposed
> definition) require me to write to handle \e?

You handle \e however you like, the same as for the others.  You
aren't *required* to do anything in particular with the others, so why
do you expect a requirement for \e?


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              ]

>> ....introduces a sequence of characters to be interpreted (in any
>> herein-undefined manner) by the printer/plotter/display device or by the
>> protocol language that serves as a device-independent layer between the
>> program and the device.
>
>Suppose I'm implementing the standard library on a system whose display
>device is mapped to an 80x25 array of 16-bit storage cells that hold
>character codes and color codes. I know how to write the code that deals
>with \a, \t, \r, \v, etc. What code does this definition (or any other
>proposed definition) require me to write to handle \e?

Anything or nothing. Same as for the others. You "know how to write the
code" only because you know by convention and tradition what those
characters mean, but not because the standard specifies their behavior when
sent to a display device.

For example, where does the standard require you to provide any specific
behavior for /v other than to treat it as white space? Interestingly,
2.13.2/3 says, "If the character following a backslash is not one of those
specified, the behavior is undefined," then it neglects to define the kind
of behavior we're discussing for the ones it specifies except to say that
they cause some undefined character value to occur in character and string
literals. At least that's what a search on \v and "vertical tab" reveals
except to include \v as one of the whitespace characters in preprocessor
directives. So \v behavior is defined when \v appears in source code but not
when sent to a display device.

Not that there's anything wrong with that, but it fails to make the case for
or against including \e as part of the formal language definition. Inclusion
of the others is the legacy of tradition. The omission of \e was a
deficiency in that tradition, IMHO, and occurred probably because whatever
terminal was on the PDP-11 (Decwriter?) at the time C was developed made no
use of the ESC character (he said, ducking).
---
[ 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 [quoting the C89 Rationale]:
>   The C89 Committee considered proposals to add the character
>   constant '\e' to represent the ASCII ESC ('\033') character. This
>   proposal was based upon the use of ESC as the initial character
>   of most control sequences in common terminal driving disciplines
>   such as ANSI X3.64. However, this usage has no obvious counterpart
>   in other popular character codes such as EBCDIC.
>
> Which is a lie - EBCDIC damn well does contain every single control
> character from ASCII, including ESC (0x27).  This comment also
> implies, incorrectly, that "other popular character sets" all contain
> a \v character.

I raised the same objection.  The response was that it didn't say that
the *character* has no obvious counterpart, but rather that the *usage*
doesn't.  That is, no one uses escape sequences in an EBCDIC
environment, they use channel control programs and other esoterica
instead.  While this still isn't strictly true, it comes much closer.
(I still don't think it's a particularly good reason for rejecting the
proposal, but the rules of the game are that the committee needs a good
reason for accepting something, not for rejecting it.)

-Larry Jones

When you're SERIOUS about having fun, it's not much fun at all! -- 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              ]

Pete Becker <petebecker@acm.org> writes:
> So you'd find it acceptable for \e to be mapped, for example, to \a, and
> produce an alert, and then to display the rest of the escape sequence as
> ordinary characters?

I would rather that \e was not equal to any other \c (single letter)
value. I would definitely find it acceptable for the remainder of
the characters to be displayed normally. Remember that in the vast
majority of implementations (perhaps even all of them), the special
characters are simply output through low level calls without any
special handling whatsoever. Even in MS environments where \n turns
into two characters on certain output streams, that translation is
handled transparently by low level read and write calls which the
C and C++ runtime uses.
---
[ 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              ]

>Al Stevens wrote:
>>  [erroneous drivel snipped ]

Please ignore my previous posts on this thread. I found what Pete was
referring to in the C standard, a document that I tend to neglect because it
is a paper copy that I can't search in lazy mode.
---
[ 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 <scjones@thor.sdrc.com> wrote in message
news:7rrdt2$9f5@nfs0.sdrc.com...
> David R Tribble (david@tribble.com) wrote [quoting the C89 Rationale]:
> doesn't.  That is, no one uses escape sequences in an EBCDIC
> environment, they use channel control programs and other esoterica
> instead.  While this still isn't strictly true, it comes much closer.

I did.  I used to have to send control sequences to laser printers hooked up
with a protocol converter.  The \e sequence would not have helped me though;
I was using REXX.

Greg Brewer
---
[ 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              ]

Greg Brewer wrote:

[...]

> Allowing parameters as you describe negates the whole purpose.  I do concede
> one point.  It occurs to me that if you are entering a value in a calendar
> program then converting a 2 digit year to a 4 digit year using a +/- 50 year
> range centering on the current year makes sense.  However if you a looking
> for historical data, then a 100 range ending with the current year makes
> more sense.  If its 2040 and you are looking for a piece of data from 68 you
> sure don't mean 2068!

Maybe the following interface would make sense:

enum date_range { past_date=-1, nearest_date, future_date };

int get_full_year(int year, date_range range = nearest_date);


[ 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:

> Why are we making this so difficult? In ASCII there is an ESC character. In
> EBCDIC there is an ESC character. I don't believe there are any other
> execution character sets, for which anyone will actually write a C++
> compiler, that don't have an ESC character. If I'm wrong about this, then
> I'd be surprised if this character set I'm as yet unaware of didn't also
> have analogous problems with other missing control characters that are
> already mentioned in the C++ standard.

So the simplest solution would be to define '\e' as the ESC character and
not worry about what its effect might be on any specific device; let the
device driver's designer worry about that.

For clarity, we could specify:

In ASCII, '\e' = '\x1B'
In EBCDIC, '\e' = '\x27'
... (mention any other cases here) ...
In other codesets the meaning of '\e' is implementation-dependent.

This should be simple enough for any compiler writer to implement and
would cause '\e' to have the effect that most people would expect.

--- Brian




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

John Hauser wrote:
>
> Paul Jarc:
> > You tell me exactly what you mean by a vertical tab.
>
> It's like a horizontal tab (\t), only in the vertical direction.  It
> introduces some implementation-defined amount of vertical whitespace
> (possibly none).  The safest use would presumably always follow '\n',
> as in "First line.\n\vSecond line.\n".
>
> Now you tell us exactly what you mean by an escape (\e).

\e means that the implementation may interpret an implementation
defined (not necessarily fixed) number of following characters
in an implementation defined way on output.
It makes sense to put restrictions on some of the standard
streambufs (f.ex. that stringstreambuf may _not_ interpret
them) and corresponding stdio functions (like sprintf).

Usually the interpretation will be done by the external device
(terminal/terminal emulator, printer), but it may be done by
the I/O library itself (f.ex., a C++ compiler could decide to
emulate VT100 on non-VT100 devices).


[ 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:
>
> David R Tribble wrote:
> >
> > I would wager that >50% of all C/C++ code is not intended to be
> > portable.
>
> And 99% of all C/C++ code is not intended to be portable to machines
> that don't speak ASCII.

What with IBM having embraced Unix for OS/390 (USS), this is slowly
becoming less true.  And then, of course, there's Unicode looming
on the horizon (which, it's true, is really just fat ASCII)...

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

"Douglas A. Gwyn" wrote:
>
> Max TenEyck Woodbury wrote:
> > At best you have argued here that \v and \a should be dropped from
> > the standard, not that \e should be added. The old values are kept
> > because
> > old programs use them and because \v is part of the input language.
>
> Indeed, I would probably support changes along those lines,
> even though some miniscule portion of existing source code
> might contain them.  In environments where they have a use,
> I would expect C implementations to continue to support them
> as an extension.  (This would be allowed if such a change to
> the spec were made properly.)

If nothing else, every C/C++/LEX/YACC lexical analyzer would have to
be rewritten if those characters were eliminated.

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

nospam.greg@brewer.net (Greg Brewer)  wrote on 13.09.99 in <7rj23q$24kd$1@news.hal-pc.org>:

> The reason I think that creating a standard function might be a good idea is
> that it would standardize the rotation rates.  Lets take 33 and 66.
>    if (given_year > 50 && current_year < 33) return last_century +
> given_year;
>    if (given_year < 50 && current_year > 66) return next_century +
> given_year;
>    return current_century + given_year;

The obvious solution is to take the closest version. I've implemented that
myself, and I believe I've seen it standardized somewhere.

That is, for a two-digit year of 17, when the current year is 1999, have a
look at 1817, 1917, and 2017. The absolute delta to our year is 182, 82,
and 18 years; so 2017 it is. (Of course, you can optimize this so you do
not actually need to determine a minimum of three differences.)

This fails for 49 (1949 is 50, 2049 is also 50). Just pick one is probably
good enough in most cases. (And if it isn't, you need extra information to
know what's better.)

Of course, just using 4 digit dates is always preferreble, but sometimes
you have to deal with data that just doesn't have those.

Oh, yes, another important point: if you're dealing with *old* data, then
obviously using the current year is the wrong thing to do :-)

Kai
--
http://www.westfalen.de/private/khms/
"... by God I *KNOW* what this network is for, and you can't have it."
  - Russ Allbery (rra@stanford.edu)
---
[ 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              ]

petebecker@acm.org (Pete Becker)  wrote on 14.09.99 in <37DE50EC.4EBB2E40@acm.org>:

> Kai Henningsen wrote:
> >
> > DAGwyn@null.net (Douglas A. Gwyn)  wrote on 11.09.99 in
> > <37D9B107.33E13CED@null.net>:
> >
> > > "Paul D. DeRocco" wrote:
> > > > The standard requires "alert" and "vertical tab", though. ... I was
> > > > merely using their common ASCII (and EBCDIC) abbreviations.
> > >
> > > Here is a challenge for you:  Write a functional specification for
> > > the character which would probably be mapped to ESC in an ASCII
> > > implementation, along the lines of the specifications for other
> > > device control functions.
> >
> > You mean using lots of concepts not defined in the standard?
> >
> > \e (escape) The codeset escape function. Invokes a different
> >    interpretation for one or more following characters.
> >
>
> So an implementation in which printf("\ea") displayed the letter a would
> not be conforming, because the letter a isn't a different interpretation
> of the character constant 'a'.

If by that you imply that an implementation where \v moved down to the
next line, but not to the initial position, would not be conforming?

Or one where \v did nothing at all?

Or one where \v displayed a "male symbol" ( circle with arrow)?

I've seen all of those. And I've never seen or heard anyone complain. (And
incidentally, it was never one of the things the C implementation would
have been expected to influence by anyone who wasn't a standards lawyer.)

IMHO, it would have been *far* saner to say "IF the execution character
set is (ASCII, ISO 646, something like that), THEN these escape sequences
map to the following control characters (NOT effects); for other character
sets, the meaning is implementation-defined".

Kai
--
http://www.westfalen.de/private/khms/
"... by God I *KNOW* what this network is for, and you can't have it."
  - Russ Allbery (rra@stanford.edu)
---
[ 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:
> You tell me exactly what you mean by a vertical tab.

It's like a horizontal tab (\t), only in the vertical direction.  It
introduces some implementation-defined amount of vertical whitespace
(possibly none).  The safest use would presumably always follow '\n',
as in "First line.\n\vSecond line.\n".

Now you tell us exactly what you mean by an escape (\e).

     - John Hauser
---
[ 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              ]

Kai Henningsen wrote:
>
> petebecker@acm.org (Pete Becker)  wrote on 14.09.99 in <37DE50EC.4EBB2E40@acm.org>:
>
> > Kai Henningsen wrote:
> > >
> > > \e (escape) The codeset escape function. Invokes a different
> > >    interpretation for one or more following characters.
> > >
> >
> > So an implementation in which printf("\ea") displayed the letter a would
> > not be conforming, because the letter a isn't a different interpretation
> > of the character constant 'a'.
>
> If by that you imply that an implementation where \v moved down to the
> next line, but not to the initial position, would not be conforming?
>

I said nothing about '\v'. I asked how you would apply your definition
of '\e' in a particular case. Since you decline to answer, I assume that
my interpretation is correct.

--
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 <7rj23q$24kd$1@news.hal-pc.org>, Greg Brewer
<nospam.greg@brewer.net> writes
>The reason I think that creating a standard function might be a good idea is
>that it would standardize the rotation rates.  Lets take 33 and 66.
>   if (given_year > 50 && current_year < 33) return last_century +
>given_year;
>   if (given_year < 50 && current_year > 66) return next_century +
>given_year;
>   return current_century + given_year;

Firstly, that might not be an ideal point to rotate. Secondly, it's not
always the current year that matters, but rather some reference year
based on the data. So both given_year and current_year, and for that
matter current_century, would have to be parameters of the function, and
the 50, 33, and 66 ought to be as well.

So we now have a function which can be written in portable code in about
10% of the space required to actually describe it fully. Not a good
candidate for standardisation.

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

John Hauser <jhauser@cs.berkeley.edu> writes:
> Paul Jarc:
> > You tell me exactly what you mean by a vertical tab.
>
> It's like a horizontal tab (\t), only in the vertical direction.  It
> introduces some implementation-defined amount of vertical whitespace
> (possibly none).  The safest use would presumably always follow '\n',
> as in "First line.\n\vSecond line.\n".

But all that is intent only.  AFAICT, the standard mandates nothing
with regard to what happens when \v is output.

> Now you tell us exactly what you mean by an escape (\e).

I didn't claim to have a meaning in mind for \e.  I'm just disputing
the claim that \v is better defined in the standard than \e could be,
or that \v belongs in the standard more than \e.


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:
> >
> > Kai Henningsen wrote:
> > >
> > > DAGwyn@null.net (Douglas A. Gwyn)  wrote
> > >
> > > > "Paul D. DeRocco" wrote:
> > > >
> > > > Here is a challenge for you:  Write a functional specification for
> > > > the character which would probably be mapped to ESC in an ASCII
> > > > implementation, along the lines of the specifications for other
> > > > device control functions.
> > >
> > > You mean using lots of concepts not defined in the standard?
> > >
> > > \e (escape) The codeset escape function. Invokes a different
> > >    interpretation for one or more following characters.
> > >
> >
> > So an implementation in which printf("\ea") displayed the letter a
> > would not be conforming, because the letter a isn't a different
> > interpretation of the character constant 'a'.
>
> We should choose words that make "\ea" implementation-defined, to
> wit:
>
>   \e (escape)
>      The codeset escape function. Produces an implementation-defined
>      interpretation for one or more following characters.
>
> Now "\ea" could very well result in "a".  As could "\e[Ha".
>

Well, the original question asked for just such a specification. Clearly
the one given is inadequate, and now we get a recipe for perhaps
producing one in the future. Not exactly a sound basis for a
discussion...

--
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 <7OmpF$WXw-B@khms.westfalen.de>, Kai Henningsen
<kaih=7OmpF$WXw-B@khms.westfalen.de> writes
>\e (escape) The codeset escape function. Invokes a different
>   interpretation for one or more following characters.
>
>There. That wasn't all that hard, now was it?

Yes. In a codeset using the shift-out and shift-in concept for switching
between character sets, there are two different codes (14 and 15 in
ASCII) with that meaning.

On a BBC micro - an ASCII based system - there are six or seven codes
that have that meaning [*]. Curiously 27 isn't one of them.

[*] Plus, in some screen modes, another 25 or so.

--
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 <7OmpFSQmw-B@khms.westfalen.de>, Kai Henningsen
<kaih=7OmpFSQmw-B@khms.westfalen.de> writes
>> BTW exactly what would be the definition of \e?  I know exactly what \a,
>> \t etc. do (even though some systems may provide trivial meanings to
>> some of them)
>
>Does that "etc." include \v? And can you explain to me what, exactly, \v
>does in any kind of non-printer context?

It moves the current position to the next vertical tabulation mark.
That's a concept exactly as well defined as \t is. For example, vertical
tabulation marks might be every 10 lines from the start of the output
*or* the latest form feed.

--
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 <7Os69jVHw-B@khms.westfalen.de>, Kai Henningsen
<kaih=7Os69jVHw-B@khms.westfalen.de> writes
>IMHO, it would have been *far* saner to say "IF the execution character
>set is (ASCII, ISO 646, something like that), THEN these escape sequences
>map to the following control characters (NOT effects); for other character
>sets, the meaning is implementation-defined".

No it wouldn't. They weren't trying to write an ASCII-only Standard.

--
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 wrote:
>
> John Hauser <jhauser@cs.berkeley.edu> writes:
> > Paul Jarc:
> > > You tell me exactly what you mean by a vertical tab.
> >
> > It's like a horizontal tab (\t), only in the vertical direction.  It
> > introduces some implementation-defined amount of vertical whitespace
> > (possibly none).  The safest use would presumably always follow
> > '\n', as in "First line.\n\vSecond line.\n".
>
> But all that is intent only.  AFAICT, the standard mandates nothing
> with regard to what happens when \v is output.

It's interesting to note what the C89/C90/C9X Rationale says about
\v:

  5.2.2  Character display semantics

  ...
  The vertical tab sequence ('\v') was added since many existing
  implementations support it, and since it is convenient to have a
  designation within the language for all the defined white space
  characters.

  ...
  To avoid the issue of whether an implementation conforms if it
  cannot properly effect vertical tabs (for instance), the Standard
  emphasizes that the semantics merely describe intent.

Which means that an implementation could very well simply ignore
'\v' characters, if it made sense to do so on that implementation.

> > Now you tell us exactly what you mean by an escape (\e).
>
> I didn't claim to have a meaning in mind for \e.  I'm just disputing
> the claim that \v is better defined in the standard than \e could be,
> or that \v belongs in the standard more than \e.

Yep.  Again, from the Rationale:

  5.2.2  Character display semantics

  ...
  Proposals to add '\e' for ASCII ESC ('\033') were not adopted
  because other popular character sets have no obvious equivalent
  (see    6.4.4.4).

  6.4.4.4  Character constants

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

Which is a lie - EBCDIC damn well does contain every single control
character from ASCII, including ESC (0x27).  This comment also
implies, incorrectly, that "other popular character sets" all contain
a \v 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              ]

Pete Becker <petebecker@acm.org> writes:
> I said nothing about '\v'. I asked how you would apply your definition
> of '\e' in a particular case. Since you decline to answer, I assume that
> my interpretation is correct.

Actually, no one seems to have been looking at the C++ Standard!
In 2.13.2      3 it says "Certain nongraphic characters ... can be
represented according to Table 5." Table 5 looks like this for
the special characters:

 new-line NL(LF) \n
 horizontal tab HT \t
 vertical tab VT \v
 backspace BS \b
 carriage return CR \r
 form feed FF \f
 alert  BEL \a

That's all that the Standard says about them. Therefore, the proper
definition of \e in the Standard would be to add this line to Table 5:

 escape  ESC \e

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.
---
[ 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:
>
> Yes. In a codeset using the shift-out and shift-in concept for switching
> between character sets, there are two different codes (14 and 15 in
> ASCII) with that meaning.
>
> On a BBC micro - an ASCII based system - there are six or seven codes
> that have that meaning [*]. Curiously 27 isn't one of them.
>
> [*] Plus, in some screen modes, another 25 or so.

Why are we making this so difficult? In ASCII there is an ESC character. In
EBCDIC there is an ESC character. I don't believe there are any other
execution character sets, for which anyone will actually write a C++
compiler, that don't have an ESC character. If I'm wrong about this, then
I'd be surprised if this character set I'm as yet unaware of didn't also
have analogous problems with other missing control characters that are
already mentioned in the C++ standard.

Refusing to include \e for ESC seems to me to sacrifice a simple
enhancement that would be useful to many programmers in the real
world--I've got modules in production code that have literally hundreds of
instances of \x1B in strings--in deference to some obscure theoretical
possibility that will never occur, and that even if it did, could be
handled with a simple error message.

One might call this "standards puritanism".

--

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              ]

Pete Becker wrote:
>
> Kai Henningsen wrote:
> >
> > \e (escape) The codeset escape function. Invokes a different
> >    interpretation for one or more following characters.
> >
>
> So an implementation in which printf("\ea") displayed the letter a would
> not be conforming, because the letter a isn't a different interpretation
> of the character constant 'a'.

No less conforming than an implementation in which printf("\a") fails to
make a sound. The standard says \a is an alert character, and merely
requires that the execution character set include some such character, even
if a particular environment doesn't do anything with it.

--

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 <clive@on-the-train.demon.co.uk> wrote in message
news:4$KoHGFxqn33EwoC@romana.davros.org...
> Firstly, that might not be an ideal point to rotate. Secondly, it's not
> always the current year that matters, but rather some reference year
> based on the data. So both given_year and current_year, and for that
> matter current_century, would have to be parameters of the function, and
> the 50, 33, and 66 ought to be as well.
>
> So we now have a function which can be written in portable code in about
> 10% of the space required to actually describe it fully. Not a good
> candidate for standardisation.

Well, you threw away everything I wanted to standardize then tell me that it
is a bad candidate for standardization.  I agree that in all situations, the
operational values I set forth are undesirable.  I even grant that the 50,
33, and 66 values may not be good values to use in most cases.  My point was
that there are values that should work in most values and I think it would
be good to have a standard function that returns a year.  I think that a
standard function would result in the uniform operation of everyone's code.
If the standard does not meet an individual need then don't use the standard
function; write your own.  Its similar to sorting, if qsort meets your
requirements, use it if not, well ...

Allowing parameters as you describe negates the whole purpose.  I do concede
one point.  It occurs to me that if you are entering a value in a calendar
program then converting a 2 digit year to a 4 digit year using a +/- 50 year
range centering on the current year makes sense.  However if you a looking
for historical data, then a 100 range ending with the current year makes
more sense.  If its 2040 and you are looking for a piece of data from 68 you
sure don't mean 2068!

Greg Brewer
---
[ 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 <37DFC7F4.6C52E838@tribble.com>,
David R Tribble  <david@tribble.com> wrote:
>
>Paul Jarc wrote:
>>
>> John Hauser <jhauser@cs.berkeley.edu> writes:
>> > Paul Jarc:
>> > > You tell me exactly what you mean by a vertical tab.
>> >
>> > It's like a horizontal tab (\t), only in the vertical direction.  It
>> > introduces some implementation-defined amount of vertical whitespace
>> > (possibly none).  The safest use would presumably always follow
>> > '\n', as in "First line.\n\vSecond line.\n".
>>
>> But all that is intent only.  AFAICT, the standard mandates nothing
>> with regard to what happens when \v is output.
>
>  To avoid the issue of whether an implementation conforms if it
>  cannot properly effect vertical tabs (for instance), the Standard
>  emphasizes that the semantics merely describe intent.
>
>Which means that an implementation could very well simply ignore
>'\v' characters, if it made sense to do so on that implementation.

Yes, and many do.  However, one point that is often missed is that
vertical tab and form feed are defined by ASCII to be analogues of
line feed - i.e. the line terminators are 'CR-LF', 'CR-VT' or 'CR-FF'.
It has a special kludge that says LF may be treated as NL (i.e. a
'CR-LF' composite character), but has no such kludge for the others.

This (and the abominable treatment of tab as a data character) makes
it very difficult to interpret the C standard in a strict ASCII
context.  Not that there are many left, of course.

>> > Now you tell us exactly what you mean by an escape (\e).
>>
>> I didn't claim to have a meaning in mind for \e.  I'm just disputing
>> the claim that \v is better defined in the standard than \e could be,
>> or that \v belongs in the standard more than \e.
>
>  The C89 Committee considered proposals to add the character
>  constant '\e' to represent the ASCII ESC ('\033') character. This
>  proposal was based upon the use of ESC as the initial character
>  of most control sequences in common terminal driving disciplines
>  such as ANSI X3.64. However, this usage has no obvious counterpart
>  in other popular character codes such as EBCDIC.
>
>Which is a lie - EBCDIC damn well does contain every single control
>character from ASCII, including ESC (0x27).  This comment also
>implies, incorrectly, that "other popular character sets" all contain
>a \v character.

That is correct.  I made that comment on C89, and again on C9X.  In
the latest draft, the C9X rationale has been fixed to remove the
reference to EBCDIC.

The obvious specification of '\e', which is PRECISELY what the ASCII
standard says, is that it has an implementation-defined effect.
I still can't see why people object to that so fiercely.


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              ]

Pete Becker wrote in message <37DE5025.A1D9E60E@acm.org>...
>Complete the following
>paragraph (paraphrased from the C standard):
>
>'\a' produces an audible or visible alert. '\b' moves the active
>position to the previous position on the current line. '\f' moves hte
>active position to the initial position at the start of the next logical
>page. '\n' moves the active position to the initial position of the next
>line. '\r' moves the active position to the initial position of the
>current line. '\t' moves the active position to the next horizontal
>tabulation position on the current line. '\v' moves the active positon
>to the initial position of the next vertical tabulation position. '\e'
>.....

....introduces a sequence of characters to be interpreted (in any
herein-undefined manner) by the printer/plotter/display device or by the
protocol language that serves as a device-independent layer between the
program and the device.
---
[ 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:
>=20
> Pete Becker <petebecker@acm.org> writes:
> > I said nothing about '\v'. I asked how you would apply your definitio=
n
> > of '\e' in a particular case. Since you decline to answer, I assume t=
hat
> > my interpretation is correct.
>=20
> Actually, no one seems to have been looking at the C++ Standard!
> In 2.13.2=81=B63 it says "Certain nongraphic characters ... can be
> represented according to Table 5." Table 5 looks like this for
> the special characters:
>=20
>         new-line        NL(LF)  \n
>         horizontal tab  HT      \t
>         vertical tab    VT      \v
>         backspace       BS      \b
>         carriage return CR      \r
>         form feed       FF      \f
>         alert           BEL     \a
>=20
> That's all that the Standard says about them. Therefore, the proper
> definition of \e in the Standard would be to add this line to Table 5:
>=20
>         escape          ESC     \e

I've been reading the C standard. Too bad the C++ standard screwed it
up. <g> So what do you take this to mean if the platform's character set
does not define NL, HT, VT, etc.?

>=20
> In addition, 2.2=81=B63 would need to have "escape" added to the list o=
f
> 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?

--=20
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:
>
> Kai Henningsen wrote:
> >
> > \e (escape) The codeset escape function. Invokes a different
> >    interpretation for one or more following characters.
> >
>
> So an implementation in which printf("\ea") displayed the letter a would
> not be conforming, because the letter a isn't a different interpretation
> of the character constant 'a'.

An interpretation is a mapping, not the result of the mapping on
a single character.

So if_"\ea" meant the same as "a" that could be because \e had
introduced an interpreation in which the sequence

    \e(Annie Haslem Is A Goddess)

was translated to a GIF of said singer (and no other sequences
had non-trivial translations.

[Hemihydrated seriousness. Just add alcohol.]

--
Chris "at the Royal Albert Hall" Dollin
---
[ 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              ]

Al Stevens wrote:
>
> Pete Becker wrote in message <37DE5025.A1D9E60E@acm.org>...
> >Complete the following
> >paragraph (paraphrased from the C standard):
> >
> >'\a' produces an audible or visible alert. '\b' moves the active
> >position to the previous position on the current line. '\f' moves the
> >active position to the initial position at the start of the next logical
> >page. '\n' moves the active position to the initial position of the next
> >line. '\r' moves the active position to the initial position of the
> >current line. '\t' moves the active position to the next horizontal
> >tabulation position on the current line. '\v' moves the active positon
> >to the initial position of the next vertical tabulation position. '\e'
> >.....
>
> ....introduces a sequence of characters to be interpreted (in any
> herein-undefined manner) by the printer/plotter/display device or by the
> protocol language that serves as a device-independent layer between the
> program and the device.

Suppose I'm implementing the standard library on a system whose display
device is mapped to an 80x25 array of 16-bit storage cells that hold
character codes and color codes. I know how to write the code that deals
with \a, \t, \r, \v, etc. What code does this definition (or any other
proposed definition) require me to write to handle \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              ]

Hyman Rosen wrote:
>
> Pete Becker <petebecker@acm.org> writes:
> > I said nothing about '\v'. I asked how you would apply your definition
> > of '\e' in a particular case. Since you decline to answer, I assume that
> > my interpretation is correct.
>
> Actually, no one seems to have been looking at the C++ Standard!
> In 2.13.2      3 it says "Certain nongraphic characters ... can be
> represented according to Table 5." Table 5 looks like this for
> the special characters:
>
>         new-line        NL(LF)  \n
>         horizontal tab  HT      \t
>         vertical tab    VT      \v
>         backspace       BS      \b
>         carriage return CR      \r
>         form feed       FF      \f
>         alert           BEL     \a
>
> That's all that the Standard says about them. Therefore, the proper
> definition of \e in the Standard would be to add this line to Table 5:
>
>         escape          ESC     \e
>
> 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.

One post I noticed mentioned a point as if in passing that I feel is
quite relevant - the '\e' escape character does nothing by itself. It's
purpose is to alter the meaning of at least one other character in the
output sequence. However, the number of characters it alters is totally
device-dependent, and escape-sequence dependent.

For any other 'special character' (I wanted to say escape sequence
there, but realised it could be confusing :), say '\t', If I code the
following :

printf("This is a\ttest");

Then I know that the characters "This is a" will be output, then a tab
character (whatever it does) and then 't', 'e', 's', 't'. This can be
said for any of the current special characters.

'\e' would be fundamentally different in this way, because :

printf("This is an \eescape sequence");

will output "This is an ", followed by the escape sequence, which does
nothing, followed by absolutely anything, which could change according
to the output device. Which C doesn't really have a concept of.

\ee on one device could be a control code that means 'print all the
follwing characters in upper case, giving me 'SCAPE SEQUENCE' on the end
of my output. The same program on the same computer sending output to a
different device could well interpret this as "'\ees' - equivalent to
form feed."

This sort of thing not only possibly changes the nature of all following
output, but alters how much you actually get as well.

It just doesn't really seem to fit in the 'C' language to me.

Adam

--
Why is it that the smaller and easier a bug is to fix, the less I want
to actually fix it?

----------------
The opinions expressed in this email are mine alone, and do not
neccesarily represent those of my employer, my parents, or the people
who wrote the email software I use.



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

Al Stevens wrote:
>
> Pete Becker wrote in message <37DE5025.A1D9E60E@acm.org>...
> >Complete the following
> >paragraph (paraphrased from the C standard):
> >
> >'\a' produces an audible or visible alert. '\b' moves the active
> >position to the previous position on the current line. '\f' moves hte
> >active position to the initial position at the start of the next logical
> >page. '\n' moves the active position to the initial position of the next
> >line. '\r' moves the active position to the initial position of the
> >current line. '\t' moves the active position to the next horizontal
> >tabulation position on the current line. '\v' moves the active positon
> >to the initial position of the next vertical tabulation position. '\e'
> >.....
>
> ....introduces a sequence of characters to be interpreted (in any
> herein-undefined manner) by the printer/plotter/display device or by the
> protocol language that serves as a device-independent layer between the
> program and the device.

Under the C standard, the effect of writing '\e' in a character string
is undefined. Under this definition it produces undefined results if
it's sent to a display device. I don't think that's much of an
improvement. In either case, if your vendor tells you what '\e' does on
their system you can use it, and if they don't, you can't.

--
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:
>
> Pete Becker wrote:
> >
> > Kai Henningsen wrote:
> > >
> > > \e (escape) The codeset escape function. Invokes a different
> > >    interpretation for one or more following characters.
> > >
> >
> > So an implementation in which printf("\ea") displayed the letter a would
> > not be conforming, because the letter a isn't a different interpretation
> > of the character constant 'a'.
>
> No less conforming than an implementation in which printf("\a") fails to
> make a sound. The standard says \a is an alert character, and merely
> requires that the execution character set include some such character, even
> if a particular environment doesn't do anything with it.

No, because the standard permits '\a' to do nothing when the display
device does not support it. There is no such permission in the proposed
"definition" of the effect of '\e': It says that the interpretation is
different. If you would like to propose different words, please do so.

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

Nick Maclaren wrote:
>
> In article <37DFC7F4.6C52E838@tribble.com>,
> David R Tribble  <david@tribble.com> wrote:
> >
> >Which is a lie - EBCDIC damn well does contain every single control
> >character from ASCII, including ESC (0x27).  This comment also
> >implies, incorrectly, that "other popular character sets" all contain
> >a \v character.
>
> That is correct.

Well, no. It's not a lie, it's a misstatement. A lie is a misstatement
that is made with the intention of deceiving someone.

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

Let me attempt to bring this back on topic.

While the Y2K problem may have its roots in old systems implemented when
data space was very expensive, I was fighting against implementations that
contained the Y2K bug throughout the 80's.  The problem was similar to a Y2K
bug that existed on my checks.  Until last year, the date portion of my
checks had "______________, 19__" on them and my deposit slips still do.
After this year, I expect my checks will start having "_______, 20__"
printed on them.

The problem is that when you enter 80 for the year, people automatically
assume 1980.  I expect this kind of coding will start creeping back into our
coding some time after 2020.  With that in mind, I'm wondering if C/C++
wouldn't benefit from a function that converts a 2 digit year to a 4 digit
year.  Mind you now, this is not well thought out and I thought others might
have ideas that enhance it.  Consider that at least for the first 20 years
or so, a value of 14 will probably be taken as 2014 and a value of 84 will
often mean 1984.  Around the middle of the century, 14 and 84 will both
refer to 20xx dates.  Toward the end of the 21st century, 84 will likely
mean 2084 and 14 will be 2114.  I take this from my current Y2K bug fixes
where I code a 2 digit years less than some value means 20yy and a 2 digit
year greater than 19yy while a 4 digit year is not changed.

The reason I think that creating a standard function might be a good idea is
that it would standardize the rotation rates.  Lets take 33 and 66.
   if (given_year > 50 && current_year < 33) return last_century +
given_year;
   if (given_year < 50 && current_year > 66) return next_century +
given_year;
   return current_century + given_year;

Again, this is not a well thought out idea; just something that has occurred
to me recently.
Greg Brewer

Paul D. Smith <pausmith@nortelnetworks.com> wrote in message
news:p5lnaet5e5.fsf@baynetworks.com...
>
> [ moderator's note: This discussion has gone completely outside the
>   charter for comp.std.c++, however fascinating the history of
>   application program development may be. Further discussion that
>   does not in some small way relate to standard C++ should not
>   include comp.std.c++ in the list of newsgroups. -sdc ]




[ 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@robinton.demon.co.uk (Francis Glassborow)  wrote on 11.09.99 in <egKSkRA3Dj23EwF$@robinton.demon.co.uk>:

> BTW exactly what would be the definition of \e?  I know exactly what \a,
> \t etc. do (even though some systems may provide trivial meanings to
> some of them)

Does that "etc." include \v? And can you explain to me what, exactly, \v
does in any kind of non-printer context?

\e would be the codeset escape function. I certainly know what *that* is.
And it's supported in *far* more situations than \v is.

Kai
--
http://www.westfalen.de/private/khms/
"... by God I *KNOW* what this network is for, and you can't have it."
  - Russ Allbery (rra@stanford.edu)
---
[ 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              ]

DAGwyn@null.net (Douglas A. Gwyn)  wrote on 11.09.99 in <37D9B107.33E13CED@null.net>:

> "Paul D. DeRocco" wrote:
> > The standard requires "alert" and "vertical tab", though. ... I was
> > merely using their common ASCII (and EBCDIC) abbreviations.
>
> Here is a challenge for you:  Write a functional specification for
> the character which would probably be mapped to ESC in an ASCII
> implementation, along the lines of the specifications for other
> device control functions.

You mean using lots of concepts not defined in the standard?

\e (escape) The codeset escape function. Invokes a different
   interpretation for one or more following characters.

There. That wasn't all that hard, now was it?

You could add a footnote listing some relevant standards that use it (for
example, ISO 2022).

>(If we *were* to add \e, we'd have to
> come up with such wording.)  Then maybe you'll see why this is
> not likely to be standardized *at this level*.

I don't think this argument works.

Kai
--
http://www.westfalen.de/private/khms/
"... by God I *KNOW* what this network is for, and you can't have it."
  - Russ Allbery (rra@stanford.edu)
---
[ 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              ]

Kai Henningsen wrote:
>
> DAGwyn@null.net (Douglas A. Gwyn)  wrote on 11.09.99 in <37D9B107.33E13CED@null.net>:
>
> > "Paul D. DeRocco" wrote:
> > > The standard requires "alert" and "vertical tab", though. ... I was
> > > merely using their common ASCII (and EBCDIC) abbreviations.
> >
> > Here is a challenge for you:  Write a functional specification for
> > the character which would probably be mapped to ESC in an ASCII
> > implementation, along the lines of the specifications for other
> > device control functions.
>
> You mean using lots of concepts not defined in the standard?
>
> \e (escape) The codeset escape function. Invokes a different
>    interpretation for one or more following characters.
>

So an implementation in which printf("\ea") displayed the letter a would
not be conforming, because the letter a isn't a different interpretation
of the character constant '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              ]

In article <7OmpFSQmw-B@khms.westfalen.de>, Kai Henningsen
<kaih=7OmpFSQmw-B@khms.westfalen.de> writes
>Does that "etc." include \v? And can you explain to me what, exactly, \v
>does in any kind of non-printer context?
>
>\e would be the codeset escape function. I certainly know what *that* is.
>And it's supported in *far* more situations than \v is.

\v is unambiguously 'vertical tab' whether that has or has not any
effect on the output is entirely dependent on hardware.  Now you tell me
exactly what you mean be a codeset escape function.  IMO not only is it
dependent on the codeset but how it is used and what its significance is
is also equally dependent.  IOWs \v has a single uniform meaning that
may be implemented differently on different equipment, but the meaning
of \ea could be entirely different for different codesets.


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ 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 <7rj23q$24kd$1@news.hal-pc.org>,
  "Greg Brewer" <nospam.greg@brewer.net> wrote:
>
> Let me attempt to bring this back on topic.

> While the Y2K problem may have its roots in old systems implemented
> when data space was very expensive, I was fighting against
> implementations that contained the Y2K bug throughout the 80's.  The
> problem was similar to a Y2K bug that existed on my checks.  Until
> last year, the date portion of my checks had "______________, 19__" on
> them and my deposit slips still do.  After this year, I expect my
> checks will start having "_______, 20__" printed on them.

> The problem is that when you enter 80 for the year, people
> automatically assume 1980.  I expect this kind of coding will start
> creeping back into our coding some time after 2020.  With that in
> mind, I'm wondering if C/C++ wouldn't benefit from a function that
> converts a 2 digit year to a 4 digit year.  Mind you now, this is not
> well thought out and I thought others might have ideas that enhance
> it.  Consider that at least for the first 20 years or so, a value of
> 14 will probably be taken as 2014 and a value of 84 will often mean
> 1984.  Around the middle of the century, 14 and 84 will both refer to
> 20xx dates.  Toward the end of the 21st century, 84 will likely mean
> 2084 and 14 will be 2114.  I take this from my current Y2K bug fixes
> where I code a 2 digit years less than some value means 20yy and a 2
> digit year greater than 19yy while a 4 digit year is not changed.

> The reason I think that creating a standard function might be a good
> idea is that it would standardize the rotation rates.  Lets take 33
> and 66.
>    if (given_year > 50 && current_year < 33) return last_century +
> given_year;
>    if (given_year < 50 && current_year > 66) return next_century +
> given_year;
>    return current_century + given_year;

> Again, this is not a well thought out idea; just something that has
> occurred to me recently.

This is sort of what the Java DateFormat class (which also parses)
does.  Two digit years are presumed to be in a 100 year interval
starting at a given date.  The default starting date is the current date
minus 80 years; this value can be set by the programmer, however.

--
James Kanze                   mailto: James.Kanze@dresdner-bank.com
Conseils en informatique orient   e objet/
                  Beratung in objekt orientierter Datenverarbeitung
Ziegelh   ttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627


Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don'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              ]

In article <7OmpF$WXw-B@khms.westfalen.de>, Kai Henningsen
<kaih=7OmpF$WXw-B@khms.westfalen.de> writes
>You mean using lots of concepts not defined in the standard?
>
>\e (escape) The codeset escape function. Invokes a different
>   interpretation for one or more following characters.

But I do not find that in any way portable and so has, from my
perspective, very little utility.


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


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

Kai Henningsen wrote:
>
> francis@robinton.demon.co.uk (Francis Glassborow)  wrote on 11.09.99 in <egKSkRA3Dj23EwF$@robinton.demon.co.uk>:
>
> > BTW exactly what would be the definition of \e?  I know exactly what \a,
> > \t etc. do (even though some systems may provide trivial meanings to
> > some of them)
>
> Does that "etc." include \v? And can you explain to me what, exactly, \v
> does in any kind of non-printer context?
>
> \e would be the codeset escape function. I certainly know what *that* is.

Do you? Please explain what '\e' would do. Complete the following
paragraph (paraphrased from the C standard):

'\a' produces an audible or visible alert. '\b' moves the active
position to the previous position on the current line. '\f' moves hte
active position to the initial position at the start of the next logical
page. '\n' moves the active position to the initial position of the next
line. '\r' moves the active position to the initial position of the
current line. '\t' moves the active position to the next horizontal
tabulation position on the current line. '\v' moves the active positon
to the initial position of the next vertical tabulation position. '\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              ]

Francis Glassborow <francis@robinton.demon.co.uk> writes:
> In article <7OmpFSQmw-B@khms.westfalen.de>, Kai Henningsen
> <kaih=7OmpFSQmw-B@khms.westfalen.de> writes
> >\e would be the codeset escape function. I certainly know what *that* is.
> >And it's supported in *far* more situations than \v is.
>
> \v is unambiguously 'vertical tab' whether that has or has not any
> effect on the output is entirely dependent on hardware.  Now you tell me
> exactly what you mean be a codeset escape function.

You tell me exactly what you mean by a vertical tab.  If an
implementation isn't required to do anything in particular with \v,
why should it be with \e?

> IOWs \v has a single uniform meaning that may be implemented
> differently on different equipment, but the meaning of \ea could be
> entirely different for different codesets.

The same is true of \v, since according to C9X 5.2.2p2 the
interpretations of these escape sequences are only intended, not
required.


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              ]

francis@robinton.demon.co.uk (Francis Glassborow)  wrote on 14.09.99 in <FWw0JXAYZl33EwsM@robinton.demon.co.uk>:

> In article <7OmpFSQmw-B@khms.westfalen.de>, Kai Henningsen
> <kaih=7OmpFSQmw-B@khms.westfalen.de> writes
> >Does that "etc." include \v? And can you explain to me what, exactly, \v
> >does in any kind of non-printer context?
> >
> >\e would be the codeset escape function. I certainly know what *that* is.
> >And it's supported in *far* more situations than \v is.
>
> \v is unambiguously 'vertical tab' whether that has or has not any
> effect on the output is entirely dependent on hardware.  Now you tell me
> exactly what you mean be a codeset escape function.

It changes the interpretation of one or more following characters.

>IMO not only is it
> dependent on the codeset but how it is used and what its significance is
> is also equally dependent.

Just like \v, then, except it's useful in more contexts. (Incidentally, if
\v and \a context validity isn't completely disjunct, then it's surely
close to - \v is practically only found on printers, and \a is practically
never found on printers.)

>IOWs \v has a single uniform meaning that
> may be implemented differently on different equipment, but the meaning
> of \ea could be entirely different for different codesets.

Actually, the meaning is just as uniform.

Kai
--
http://www.westfalen.de/private/khms/
"... by God I *KNOW* what this network is for, and you can't have it."
  - Russ Allbery (rra@stanford.edu)


[ 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:
>
> Kai Henningsen wrote:
> >
> > DAGwyn@null.net (Douglas A. Gwyn)  wrote
> >
> > > "Paul D. DeRocco" wrote:
> > >
> > > Here is a challenge for you:  Write a functional specification for
> > > the character which would probably be mapped to ESC in an ASCII
> > > implementation, along the lines of the specifications for other
> > > device control functions.
> >
> > You mean using lots of concepts not defined in the standard?
> >
> > \e (escape) The codeset escape function. Invokes a different
> >    interpretation for one or more following characters.
> >
>
> So an implementation in which printf("\ea") displayed the letter a
> would not be conforming, because the letter a isn't a different
> interpretation of the character constant 'a'.

We should choose words that make "\ea" implementation-defined, to
wit:

  \e (escape)
     The codeset escape function. Produces an implementation-defined
     interpretation for one or more following characters.

Now "\ea" could very well result in "a".  As could "\e[Ha".

-- 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 <37D97855.201BF2E0@ix.netcom.com>, Paul D. DeRocco
<pderocco@ix.netcom.com> writes
>I think the two questions are quite different. Adding \e to the legal list
>of C++ escapes could be cleanly diagnosed as an error should someone try to
>port a program containing it to a character set other than ASCII or EBCDIC
>that has no ESC character.

I think you misunderstand what the Standard would require.  There could
not be such an error because a compiler would be required to support \e
just as it is required to support \a etc.

BTW exactly what would be the definition of \e?  I know exactly what \a,
\t etc. do (even though some systems may provide trivial meanings to
some of them) Note that the external representation of these are not
required to be single characters.  E.g. \n maps to NL,CR on some
systems.  While \a often maps to BEL it could map to anything, though
sensibly that should cause some form of alert.  I think it would be
perfectly acceptable to arrange that \a flashed the screen (might be
quite useful for deaf users)


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


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

clamage@eng.sun.com (Steve Clamage)  wrote on 10.09.99 in <7rbbgb$sem$1@engnews1.eng.sun.com>:

> "Ken Hagan" <K.Hagan@thermoteknix.co.uk> writes:
>
> >Max TenEyck Woodbury wrote in message
> >>And 90%+ of all portability problems arise because a program that was
> >>never intended to be ported has to be ported. The whole Y2K mess has
> >>come up for similar reasons. This kind of thinking should NOT be
> >>encouraged!
>
> >I think the Y2K mess is a result of "not thinking", rather than "thinking
> >badly".
>
> You have to put yourself in the position of a programmer in
> the late 1960's. Mainframe computers had a few hundred Kbytes of
> memory. Minicomputers had maybe 64K of memory. Disk drives were
> physically large and expensive, used only for system programs,
> swap space, and spooling. (A 10Mb drive was considered big.)
> Computers used banks of tape drives for data.
>
> You are writing a program to handle millions of records of
> data, each containing several dates. If you can save 2 bytes
> per date, it can make the difference between acceptable and
> unacceptable overall performance.

On the other hamd, you *know* (or at least, you'd knew if you thought for
a minute) that this is bound to make (many) programs using this trick
simply wrong, without waiting for 2000-01-01.

You know, I remember hearing about grandmothers called in for baby
vaccination, because someone had a Y1900 problem. That cannot have been
later then, say, 1975; and there's no reason to believe 1960 was really
any different.

That is, the mistake is in assuming a program can get away with handling
only 100 years. Very often, that's just not true, even without looking at
archaeology.

> You're not stupid. You know that a 2-digit date interface will
> fail after 1999.

You are stupid, because you forget that it may well fail *tomorrow*. When
you have to deal with someone past their 100th birthday. Or when you have
to deal with a deed from 61 years ago. Or one that will run for 41 years.

It's really not true that century problems only happen when the calendar
reaches 2000-01-01. And it never *was* true in the first place.

> That isn't "not thinking" or "thinking badly". It's sound
> engineering.

It's crappy engineering. And I say that even though I've done nothing to
solve a similar problem in a project I once worked with.

Kai
--
http://www.westfalen.de/private/khms/
"... by God I *KNOW* what this network is for, and you can't have it."
  - Russ Allbery (rra@stanford.edu)


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

"Douglas A. Gwyn" wrote:
>
> Lack of \e as a standard escape doesn't prevent you from writing
> a non-portable equivalent.  I don't see how to make \e portable
> anyway, without restricting the run-time codeset choices more
> that we ever have before.

If the standard requires BEL (which is meaningless in printed output) or VT
(which I've never found support for in any printer I've used since the
70's), why can't it require ESC? The only codesets I'm aware of are ASCII
and EBCDIC. They both have codes for CR, LF, HT, VT, FF, BS and BEL. And
they both have codes for ESC (0x27 in EBCDIC).

Is it any more likely that some obscure codeset out there doesn't have an
ESC character, than that it doesn't have a BEL or VT character? Are there
any real-world codesets out that have CR, LF, HT, VT, FF, BS and BEL, but
don't have ESC? If there exists a codeset that doesn't have, say, BEL, and
the compiler deals with \a in some nonstandard manner (perhaps with an
error message), it could do the same for \e if it doesn't have ESC.

The objections to \e seem awfully farfetched, compared to its obvious
advantages in typability and readability.

--

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              ]

"Paul D. DeRocco" wrote:
>
> David R Tribble wrote:
> >
> > I would wager that >50% of all C/C++ code is not intended to be
> > portable.
>
> And 99% of all C/C++ code is not intended to be portable to machines that
> don't speak ASCII.

And 90%+ of all portability problems arise because a program that was
never intended to be ported has to be ported. The whole Y2K mess has
come up for similar reasons. This kind of thinking should NOT be
encouraged!

mtew@cds.duke.edu
---
[ 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:
>
> "Douglas A. Gwyn" wrote:
> >
> > Lack of \e as a standard escape doesn't prevent you from writing
> > a non-portable equivalent.  I don't see how to make \e portable
> > anyway, without restricting the run-time codeset choices more
> > that we ever have before.
>
> If the standard requires BEL (which is meaningless in printed output) or VT

The standard doesn't require BEL or VT. It requires '\a' and '\f' and
describes what effects they have.

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

Max TenEyck Woodbury wrote in message
>And 90%+ of all portability problems arise because a program that was
>never intended to be ported has to be ported. The whole Y2K mess has
>come up for similar reasons. This kind of thinking should NOT be
>encouraged!


I think the Y2K mess is a result of "not thinking", rather than "thinking
badly". C++ is not one of those fascist languages which teaches you
"good programming".

Constructs which produce unportable code are already quite common.
(reinterpret_cast?) "\e" is being advocated as a convenience for those
(many) people working on systems which have such a beast. I think I
could make a stronger case for \e than for \a.




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

"Ken Hagan" <K.Hagan@thermoteknix.co.uk> writes:

>Max TenEyck Woodbury wrote in message
>>And 90%+ of all portability problems arise because a program that was
>>never intended to be ported has to be ported. The whole Y2K mess has
>>come up for similar reasons. This kind of thinking should NOT be
>>encouraged!

>I think the Y2K mess is a result of "not thinking", rather than "thinking
>badly".

You have to put yourself in the position of a programmer in
the late 1960's. Mainframe computers had a few hundred Kbytes of
memory. Minicomputers had maybe 64K of memory. Disk drives were
physically large and expensive, used only for system programs,
swap space, and spooling. (A 10Mb drive was considered big.)
Computers used banks of tape drives for data.

You are writing a program to handle millions of records of
data, each containing several dates. If you can save 2 bytes
per date, it can make the difference between acceptable and
unacceptable overall performance.

You're not stupid. You know that a 2-digit date interface will
fail after 1999. But you know for sure that your program will
no longer be in use that far in the future. Why give up
performance to avoid a problem that will never happen?

That isn't "not thinking" or "thinking badly". It's sound
engineering.

Now put yourself in the position of a DP manager in the 1970's
or 1980's.  Assume you know about the 2-digit date problem.
You've got a set of programs that are reliable enough. Replacing
them would cost several large fortunes, and you don't have the
budget for it. Year 2000 is still a long way off, and the
cost in money, time, and possible lost reliability while a
new set of programs mature has no short-term or medium-term
payoff. You could never sell it to top management even if you
thought it was a good idea. Well, you'll be retired before
1999, and it will be somebody else's problem.

I think Max's evaluation is correct.

--
Steve Clamage, stephen.clamage@sun.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:
>
> If the standard requires BEL (which is meaningless in printed output) or VT
> (which I've never found support for in any printer I've used since the
> 70's), why can't it require ESC? The only codesets I'm aware of are ASCII
> and EBCDIC. They both have codes for CR, LF, HT, VT, FF, BS and BEL. And
> they both have codes for ESC (0x27 in EBCDIC).
>
> Is it any more likely that some obscure codeset out there doesn't have an
> ESC character, than that it doesn't have a BEL or VT character? Are there
> any real-world codesets out that have CR, LF, HT, VT, FF, BS and BEL, but
> don't have ESC? If there exists a codeset that doesn't have, say, BEL, and
> the compiler deals with \a in some nonstandard manner (perhaps with an
> error message), it could do the same for \e if it doesn't have ESC.
>
> The objections to \e seem awfully farfetched, compared to its obvious
> advantages in typability and readability.

At best you have argued here that \v and \a should be dropped from the
standard, not that \e should be added. The old values are kept because
old programs use them and because \v is part of the input language. A
compiler that refused to compile a program with an \a in it would not
be a conforming compiler. You will gain nothing with this line of argument.

If you want to make your case, you'll need to explain why \e has to be added,
not why other escaped characters are useless. The only positive argument I've
seen so far is that you would find it convenient and you don't want to use
existing portable methods. That's not enough to mandate such a change and
require all implementations to comply.

mtew@cds.duke.edu


[ 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 <7rbbgb$sem$1@engnews1.eng.sun.com>, Steve Clamage
<clamage@eng.sun.com> writes
>>I think the Y2K mess is a result of "not thinking", rather than "thinking
>>badly".

It's neither, as Steve partially explained:

>You have to put yourself in the position of a programmer in
>the late 1960's. Mainframe computers had a few hundred Kbytes of
>memory.
[...]
>You are writing a program to handle millions of records of
>data, each containing several dates. If you can save 2 bytes
>per date, it can make the difference between acceptable and
>unacceptable overall performance.

Furthermore, I seem to recall reading (in _The_Mythical_Man_Month,
perhaps) that mainframe memory was *rented* for sums of around $1000 per
kilobyte per month. Suppose your software handed 500 dates in memory at
a time (not unreasonable when merging data) and was responsible for 20%
of machine use (also not unreasonable for a major application). Then the
2 bytes for the century cost *two hundred dollars per month*. Prices
have gone up by at least a factor of 10 by then.

>You're not stupid. You know that a 2-digit date interface will
>fail after 1999. But you know for sure that your program will
>no longer be in use that far in the future.

Even if it is, you can afford to wait several years and let those $200
per month build up to pay the changeover cost in 1995.

>Now put yourself in the position of a DP manager in the 1970's
>or 1980's.  Assume you know about the 2-digit date problem.
>You've got a set of programs that are reliable enough. Replacing
>them would cost several large fortunes,
[...]

And it's not unlikely that you'll be moving to a new machine or even
architecture before then. So you can put the rewrite off until the
porting work happens. Again, sound business practice.

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

Pete Becker wrote:
>
> "Paul D. DeRocco" wrote:
> >
> > "Douglas A. Gwyn" wrote:
> > >
> > > Lack of \e as a standard escape doesn't prevent you from writing
> > > a non-portable equivalent.  I don't see how to make \e portable
> > > anyway, without restricting the run-time codeset choices more
> > > that we ever have before.
> >
> > If the standard requires BEL (which is meaningless in printed output)
> > or VT
>
> The standard doesn't require BEL or VT. It requires '\a' and '\f' and
> describes what effects they have.

The standard requires "alert" and "vertical tab", though. (2.2 paras 1 and
3) I was merely using their common ASCII (and EBCDIC) abbreviations. Who's
to say that a compiler writer is more likely to encounter some obscure
execution character set that has no "escape", than that has no "vertical
tab" or "alert"?

What's more, it's obvious what a compiler writer should do when presented
with an execution character set that doesn't contain "escape", or for that
matter "vertical tab" or "alert". If the program uses \e, or \v or \a,
issue an error message, because the attempt to use _any_ character not
actually in the execution character set is a logical error.

--

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              ]

Max TenEyck Woodbury wrote:
>
> "Paul D. DeRocco" wrote:
> >
> > And 99% of all C/C++ code is not intended to be portable to machines
> > that don't speak ASCII.
>
> And 90%+ of all portability problems arise because a program that was
> never intended to be ported has to be ported. The whole Y2K mess has
> come up for similar reasons. This kind of thinking should NOT be
> encouraged!

I think the two questions are quite different. Adding \e to the legal list
of C++ escapes could be cleanly diagnosed as an error should someone try to
port a program containing it to a character set other than ASCII or EBCDIC
that has no ESC character. And the compiler error message would correctly
reflect an underlying logical problem that would need to be fixed. Y2K bugs
don't have anything to do with porting; they cannot be caught by a
compiler, and wind up being bugs in the code, which is quite another thing.

--

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              ]

"Paul D. DeRocco" wrote:
> The standard requires "alert" and "vertical tab", though. ... I was
> merely using their common ASCII (and EBCDIC) abbreviations.

Here is a challenge for you:  Write a functional specification for
the character which would probably be mapped to ESC in an ASCII
implementation, along the lines of the specifications for other
device control functions.  (If we *were* to add \e, we'd have to
come up with such wording.)  Then maybe you'll see why this is
not likely to be standardized *at this level*.


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

Max TenEyck Woodbury wrote:
> At best you have argued here that \v and \a should be dropped from the
> standard, not that \e should be added. The old values are kept because
> old programs use them and because \v is part of the input language.

Indeed, I would probably support changes along those lines,
even though some miniscule portion of existing source code
might contain them.  In environments where they have a use,
I would expect C implementations to continue to support them
as an extension.  (This would be allowed if such a change to
the spec were made properly.)

However, since nobody seems to be beating down our door
complaining about these, common sense says that they should
be left alone.  There are more important things to worry about.


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

>You have to put yourself in the position of a programmer in
>the late 1960's.

That's what I was doing then. Started in the late 1950s actually.

>Disk drives were
>physically large and expensive, used only for system programs,
>swap space, and spooling.

That's not entirely true. We were using disk drives for random access file
applications starting as early as 1959. As I remember, the software
technology (hashing, indexed-sequential, etc.) for doing that was well
understood even then, so someone must have been doing it even before we did.
Many commercial applications used sequential master files and were indeed
stored on tape, although a typical system might load them to disk to process
them, but we had interactive database queries and updates against permanent
disk files in the late 1950s.

>You're not stupid. You know that a 2-digit date interface will
>fail after 1999. But you know for sure that your program will
>no longer be in use that far in the future.

I have specific memories of thinking exactly that at the time.

>That isn't "not thinking" or "thinking badly". It's sound
>engineering.

Thanks. I've been feeling guilty for the past couple of years.

>Well, you'll be retired before
>1999, and it will be somebody else's problem.

Well, I didn'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              ]

[ moderator's note: This discussion has gone completely outside the
  charter for comp.std.c++, however fascinating the history of
  application program development may be. Further discussion that
  does not in some small way relate to standard C++ should not
  include comp.std.c++ in the list of newsgroups. -sdc ]

%% "Clive D.W. Feather" <clive@on-the-train.demon.co.uk> writes:

  cdwf> In article <7rbbgb$sem$1@engnews1.eng.sun.com>, Steve Clamage
  cdwf> <clamage@eng.sun.com> writes

  >>> I think the Y2K mess is a result of "not thinking", rather than "thinking
  >>> badly".

  cdwf> It's neither, as Steve partially explained:

  >> You have to put yourself in the position of a programmer in
  >> the late 1960's. Mainframe computers had a few hundred Kbytes of
  >> memory.
  cdwf> [...]
  >> You are writing a program to handle millions of records of
  >> data, each containing several dates. If you can save 2 bytes
  >> per date, it can make the difference between acceptable and
  >> unacceptable overall performance.

  cdwf> Furthermore, I seem to recall reading (in
  cdwf> _The_Mythical_Man_Month, perhaps) that mainframe memory was
  cdwf> *rented* for sums of around $1000 per kilobyte per
  cdwf> month. Suppose your software handed 500 dates in memory at a
  cdwf> time (not unreasonable when merging data) and was responsible
  cdwf> for 20% of machine use (also not unreasonable for a major
  cdwf> application). Then the 2 bytes for the century cost *two hundred
  cdwf> dollars per month*. Prices have gone up by at least a factor of
  cdwf> 10 by then.

I can't believe this is the real reason.

If it really were a case of data storage constraints and money, why
weren't programmers using only _one_ byte, and storing a range of 255
years in it?  They'd have saved lots of money, and we'd be set until at
least 2155 (to pick a fairly reasonable epoch).  Even if you had only
6-bit bytes you could get a lot better than 20-odd years out of two
bytes.

--
-------------------------------------------------------------------------------
 Paul D. Smith <psmith@baynetworks.com>         Network Management Development
 "Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
   These are my opinions---Nortel Networks takes no responsibility for them.


[ 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:
>
> I would wager that >50% of all C/C++ code is not intended to be
> portable.

And 99% of all C/C++ code is not intended to be portable to machines that
don't speak ASCII.

--

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              ]

David R Tribble wrote:
> Max TenEyck Woodbury wrote:
> > In any case there is no NEED to add \e. Including it would
> > encourage writing non-portable code.
> So?  What if I need to?

Lack of \e as a standard escape doesn't prevent you from writing
a non-portable equivalent.  I don't see how to make \e portable
anyway, without restricting the run-time codeset choices more
that we ever have before.
---
[ 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 <37D3FC7D.AB74E01D@null.net>, Douglas A. Gwyn
<DAGwyn@null.net> writes
>> A bigger drawback is the constraint in 6.4.3 that "A universal
>> character name shall not specify a character whose short identifier
>> is less than 00A0...".

>If we meant to exclude *only* the C basic source
>characters then that's what we should have said.

We meant to exclude:
- the C basic source characters
- the C0 and C1 control spaces (0 to 31, 127 to 159).
The cited words are the minimum that achieve that goal.

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

Larry Jones wrote:
>
> Barry Margolin (barmar@bbnplanet.com) wrote:
>>
>> But what can you do *portably* with \e?  ESC is normally used as the first
>> character of an escape sequence, and the rest of the escape sequence is
>> very dependent on the codeset.  Since the rest of it will have to be
>> conditionalized (probably table driven, as in Unix termcap or terminfo), is
>> it really necessary to have the first character part of the standard?
>
> The rest of the escape sequence is very dependent on the codeset of the
> *device*, not the codeset of the *program*.  If I could write:
>
>         printf("\e[H\e[JHello, world!\n");
>
> I would be confident that running that program with the output directed
> to an ANSI terminal would clear the screen and write "Hello, world!" in
> the top left corner, reguardless of the native codeset of the processor
> running the program.  That is, the program could well be running on an
> EBCDIC system with the output directed to an ASCII device with some
> hardware and/or software handling the ASCII/EBCDIC translation.  As it
> is, I can't write such code since I have to use \033 in ASCII and \047
> in EBCDIC.
>
> -Larry Jones

The best way I have found to handle this kind of thing is to build
a header file with the appropriate character sequences defined as
macros. For example in ASCII.H define:

#define STR_NUL  "\000"
#define CHAR_NUL ('\000)
...
#define STR_BEL  "\007"
#define CHAR_BEL ('\007)
#define STR_BS   "\010"
#define CHAR_BS  ('\010)
#define STR_HT   "\011"
#define CHAR_HT  ('\011)
#define STR_LF   "\012"
#define CHAR_LF  ('\012)
#define STR_VT   "\013"
#define CHAR_VT  ('\013)
#define STR_FF   "\014"
#define CHAR_FF  ('\014)
#define STR_CR   "\015"
#define CHAR_CR  ('\015)
...
#define STR_ESC  "\033"
#define CHAR_ESC ('\033)
...
#define STR_H    "\110"
#define CHAR_H   ('\110)
...
#define STR_J    "\112"
#define CHAR_J   ('\112)
...
#define STR_OSB  "\134"
#define CHAR_OSB ('\134)

and in VT100.H define something like:

...
#if ('\n == CHAR_LF)
#define TERMCAP_NL        "\n"
#else
#define TERMCAP_NL        STR_CR STR_LF
#endif
...
#define TERMCAP_INTRO     STR_ESC STR_OSB
...
#define TERMCAP_HOME      TERMCAP_INTRO STR_H
...
#define TERMCAP_CLEAR_EOS TERMCAP_INTRO STR_J
...
#define TERMCAP_CLS       TERMCAP_HOME TERMCAP_CLEAR_EOS
...

then the code would look like:

#include "ASCII.H"
#include "VT100.H"

...

    printf( TERMCAP_CLS "Hello, world!" TERMCAP_NL);

Given this approach, it becomes clear that very few of the
output formatting characters belong in the 'C' standard. In
fact, only the escaped characters needed to define the input
language are really needed. \a and \b are included mainly
because a number of old programs use them.

Note that the contents of files like ASCII.H and VT100.H
are 'bindings' of other standards on 'C' and could be required
as part of those other standard, but do NOT belong in the 'C'
standard.

In any case there is no NEED to add \e. Including it would
encourage writing non-portable code.

mtew@cds.duke.edu
---
[ 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:
>
> I suppose I can live with having to type "...\u001B..." instead of
> "...\e...".  The only possible drawback I can see is that \u001B is
> specifically the ASCII/Unicode ESC character, which could
> concievably translate into a character that is not the appropriate
> "escape" character on some non-ASCII/Unicode systems (whatever that
> means).  QoI?

A bigger drawback is the constraint in 6.4.3 that "A universal character
name shall not specify a character whose short identifier is less than
00A0...".

-Larry Jones

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

Larry Jones wrote:
>         printf("\e[H\e[JHello, world!\n");

Since this code is already very device-dependent, what is the beef
about it being codeset dependent as well?  I.e. the termcap library
should already be responsible for mapping device properties to the
proper strings for output, and it is therefore a perfect place to
translate an abstract notions of "ESC character" to whatever code
is actually needed.

There are a *lot* of special characters, commonly supported in
popular codesets, that are not in the C basic character set and
that have no \-escape sequence defined for them in the C standard.
Some of them I find more useful than ESC, these days.  As of C9x,
there is even a standard way to denote them in source code (UCN
notation).  I don't think we need to add individual kludges when
there is a sufficient general mechanism.
---
[ 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:
> A bigger drawback is the constraint in 6.4.3 that "A universal
> character name shall not specify a character whose short identifier
> is less than 00A0...".

I had temporarily forgotten about that.
It makes sense to limit the range of short-identifiers that can be
used in identifiers, but remind me again why some punctuation,
space, and control characters can be expressed via UCN and others
cannot.  If we meant to exclude *only* the C basic source
characters then that's what we should have said.


[ 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:
>
> A bigger drawback is the constraint in 6.4.3 that "A universal character
> name shall not specify a character whose short identifier is less than
> 00A0...".

Huh? What's the rationale behind that one?

Adam

--
Why is it that the smaller and easier a bug is to fix, the less I want
to actually fix it?

----------------
The opinions expressed in this email are mine alone, and do not
neccesarily represent those of my employer, my parents, or the people
who wrote the email software I use.


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

Barry Margolin wrote:
>
> But what can you do *portably* with \e?  ESC is normally used as the first
> character of an escape sequence, and the rest of the escape sequence is
> very dependent on the codeset.  Since the rest of it will have to be
> conditionalized (probably table driven, as in Unix termcap or terminfo), is
> it really necessary to have the first character part of the standard?

It isn't necessary, but it is such a commonly used character that one gets
tired of typing \33 or \x1B. What's more, those numeric forms don't work in
strings if followed by valid digits, so you wind up having to break strings,
e.g., "\x1B" "A" instead of "\eA". Ugly and hard to read.

--

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              ]

Barry Margolin (barmar@bbnplanet.com) wrote:
>
> But what can you do *portably* with \e?  ESC is normally used as the first
> character of an escape sequence, and the rest of the escape sequence is
> very dependent on the codeset.  Since the rest of it will have to be
> conditionalized (probably table driven, as in Unix termcap or terminfo), is
> it really necessary to have the first character part of the standard?

The rest of the escape sequence is very dependent on the codeset of the
*device*, not the codeset of the *program*.  If I could write:

 printf("\e[H\e[JHello, world!\n");

I would be confident that running that program with the output directed
to an ANSI terminal would clear the screen and write "Hello, world!" in
the top left corner, reguardless of the native codeset of the processor
running the program.  That is, the program could well be running on an
EBCDIC system with the output directed to an ASCII device with some
hardware and/or software handling the ASCII/EBCDIC translation.  As it
is, I can't write such code since I have to use \033 in ASCII and \047
in EBCDIC.

-Larry Jones

He's just jealous because I accomplish so much more than he does. -- 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 <37CCE33D.811BA5FC@ix.netcom.com>,
Paul D. DeRocco <pderocco@ix.netcom.com> wrote:
>It isn't necessary, but it is such a commonly used character that one gets
>tired of typing \33 or \x1B. What's more, those numeric forms don't work in
>strings if followed by valid digits, so you wind up having to break strings,
>e.g., "\x1B" "A" instead of "\eA". Ugly and hard to read.

Why are you hard-coding escape sequences into C programs, rather than using
libraries like termcap?  Why should the C standard be extended to support
something that's only useful for bad programming style?  I realize that C
has a number of features that promote poor programming (e.g. gets()) but
these are legacies that we're stuck with for compatibility, not things that
have been added.

--
Barry Margolin, barmar@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.


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

Barry Margolin wrote:
>
> Why are you hard-coding escape sequences into C programs, rather than using
> libraries like termcap?  Why should the C standard be extended to support
> something that's only useful for bad programming style?  I realize that C
> has a number of features that promote poor programming (e.g. gets()) but
> these are legacies that we're stuck with for compatibility, not things that
> have been added.

Because I'm not writing for Unix, so I have no "termcap" anywhere in sight.
When I'm using escape sequences, I'm writing mostly MS-DOS command line
utilities.

Now that computers can generate music, and not merely "beep", it seems to me
that the alert character is no more peculiar than an escape. And I don't think
I've _ever_ used a piece of hardware that understood vertical tab.

--

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              ]

"Douglas A. Gwyn" wrote:
>
> Larry Jones wrote:
> >     printf("\e[H\e[JHello, world!\n");
>
> Since this code is already very device-dependent, what is the beef
> about it being codeset dependent as well?  I.e. the termcap library
> should already be responsible for mapping device properties to the
> proper strings for output, and it is therefore a perfect place to
> translate an abstract notions of "ESC character" to whatever code
> is actually needed.

Assuming you're even using the termcap library.

> There are a *lot* of special characters, commonly supported in
> popular codesets, that are not in the C basic character set and
> that have no \-escape sequence defined for them in the C standard.
> Some of them I find more useful than ESC, these days.  As of C9x,
> there is even a standard way to denote them in source code (UCN
> notation).  I don't think we need to add individual kludges when
> there is a sufficient general mechanism.

I suppose I can live with having to type "...\u001B..." instead of
"...\e...".  The only possible drawback I can see is that \u001B is
specifically the ASCII/Unicode ESC character, which could
concievably translate into a character that is not the appropriate
"escape" character on some non-ASCII/Unicode systems (whatever that
means).  QoI?

The standard, BTW, does not prohibit implementations from supporting
extensions such as "\E" or even "\ESC\DEL\NUL".  They're just not
portable.

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

Douglas A. Gwyn (DAGwyn@null.net) wrote:
>
> I don't know about the C++ group, but the main reason against \e
> standardization in C is that ESC is specific to certain codesets
> and need not have a representation in others.

Which, it has been pointed out, is a completely specious argument.  The
fact is that all popular, extant codesets have an ESC character, as do
most, if not all, of the unpopular ones.  It is at least as common as
BEL (\a), if not more so.

> Odds are that what
> you *really* want in all environments where you plan to use ESC
> sequences is the numeric value, e.g. #define ESC 27.  You can do
> that already in Standard C.

In some contexts that's true, but in at least as large a number of
contexts you want the ESC character in the native codeset, not the ASCII
ESC character reguardless of the native codeset.

> There are already standards (e.g. X.64) for the semantics of
> escape sequences.  Note that an actual VT100 has several weird
> quirks (in its microcode) that make it less than an ideal model.

In my experience, an actual VT100 has many fewer quirks than most of the
devices that purport to emulate it.  ;-)

-Larry Jones

The real fun of living wisely is that you get to be smug about it. -- Hobbes
---
[ 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 <7qeoku$jt4@nfs0.sdrc.com>,
Larry Jones <larry.jones@sdrc.com> wrote:
>Douglas A. Gwyn (DAGwyn@null.net) wrote:
>>
>> I don't know about the C++ group, but the main reason against \e
>> standardization in C is that ESC is specific to certain codesets
>> and need not have a representation in others.
>
>Which, it has been pointed out, is a completely specious argument.  The
>fact is that all popular, extant codesets have an ESC character, as do
>most, if not all, of the unpopular ones.  It is at least as common as
>BEL (\a), if not more so.

But what can you do *portably* with \e?  ESC is normally used as the first
character of an escape sequence, and the rest of the escape sequence is
very dependent on the codeset.  Since the rest of it will have to be
conditionalized (probably table driven, as in Unix termcap or terminfo), is
it really necessary to have the first character part of the standard?

--
Barry Margolin, barmar@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.


[ 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:
> Yeah, that was more or less the committee response when I suggested
> that we needed an '\e' character sequence years ago.  Apparently,
> no one has been clever enough ...

I don't know about the C++ group, but the main reason against \e
standardization in C is that ESC is specific to certain codesets
and need not have a representation in others.  Odds are that what
you *really* want in all environments where you plan to use ESC
sequences is the numeric value, e.g. #define ESC 27.  You can do
that already in Standard C.

There are already standards (e.g. X.64) for the semantics of
escape sequences.  Note that an actual VT100 has several weird
quirks (in its microcode) that make it less than an ideal model.
---
[ 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              ]

Ken Hagan wrote:

> In K&R's original compiler, this was almost certainly done by the
> lexer, which was almost certainly generated by lex. Consequently,
> they would have had no reason to add such a function to their library.

Certainly it was handled by the lexical analyzer, but the K&R
compiler predates YACC and YACC predates LEX.

-Ron
---
[ 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:
>
> Apparently,
> no one has been clever enough to come up with a written description
> of the semantics of the control character ESC, even though everyone
> damn well knows what it means.
> [...]
> VT-100 terminal protocol
> (which uses ESC extensively) is something of a de facto standard, so
> these could probably serve as a guiding example of how to define the
> semantics of ESC on paper.

For the record, the VT-100 use of ESC was based on official ANSI
standards, now known as ISO 2022 and ISO 6429.

     - John Hauser


[ 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:
> >
> > What are the observable consequences of escape?
>
> Yeah, that was more or less the committee response when I suggested
> that we needed an '\e' character sequence years ago.  Apparently,
> no one has been clever enough to come up with a written description
> of the semantics of the control character ESC, even though everyone
> damn well knows what it means.
>
> Some of the ISO multibyte character sets are defined in terms of
> "shift in" and "shift out" sequences, and VT-100 terminal protocol
> (which uses ESC extensively) is something of a de facto standard, so
> these could probably serve as a guiding example of how to define the
> semantics of ESC on paper.  It really isn't that mystical, is it?

I wonder if the VT-100 terminal protocol do use plain ESC.
My impression was that it does use CSI and other characters that
happen to be defined in the C1 set, thus need to use ESC as a
fall-back mechanism to cooperate with 7-bit medias (the C1 set
is normaly using '\200' to '\237', but can also be obtained by
ESC followed by '\000' to '\037').


Anyway, the real definition of ESC is in ISO 2022 a.k.a. ECMA-35
(available online at <URL:http://www.ecma.ch/stand/ECMA-035.HTM>),
and its main use is to switch character sets when using that standard.
If this is an observable consequence or not is outside my realm.


Antoine


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

Greg Brewer wrote in message <7p1u5o$ipi$1@news.hal-pc.org>...
>...that the string functions do not include a function to translate
>strings from their code representation (eg "abc\t\a\n") to their
> internal representation...

In K&R's original compiler, this was almost certainly done by the
lexer, which was almost certainly generated by lex. Consequently,
they would have had no reason to add such a function to their library.
---
[ 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              ]

| (Much as I hate EBCDIC, I am forced to admit that it did a slightly
| better job by providing an explicit "newline" (NL) character;
| C/C++ grabbed "linefeed" (LF) for this purpose, which is logically
| only half of the motion of a printer head.  Oh, well.)

Getting far away from C++, but ... C (and Unix) had a reasonable basis
in the existing standards for doing this.  ASCII(10) always had two
interpretations:  As LF (Linefeed) or as NL (New Line).  I'm pretty sure
the VT100 allowed you to determine how ASCII(10) would be treated when
received by the terminal; I think the setting was one of those defined
in the ANSI terminal standard, X.34 or something like that.

Why the ambiguity?  When ASCII was created, there were two kinds of
"printing" devices in the world:  Teletype-like things and line
printers.  For Teletype-like things - which included the early video
terminals, then widely describe as "glass TTY's" - LF made sense, was
easy to implement, and could even be useful.  Not only that, but it made
the mechanicals simpler if each character only did one thing:  LF moved
the platen, CR moved the print element back to the left edge.

For line printers, LF was often too expensive to implement - the line
buffering logic was very simple-minded, of necessity (discrete
transistors and such).  New Line meant dump the current buffer and start
filling a new one from the left hand edge.  Line printers didn't
implement BACKSPACE either, for the same reason.  (Line printers did
generally allow you to control the platen advance separately, so you
could over-print an entire line - software could do things like
underlining or fake bolding by overprinting appropriately in only some
positions - or double space, or skip to the top of a page.)  The whole
FORTRAN printing model - with the magic first position - was based on
line printers (and was always a pain to match to terminals).

ASCII tried to cater to both styles of devices with its double meaning
for ASCII(10).  In practice, dumb line printers vanished - but their
interpretation of ASCII(10), as chosen for Unix, lives on.

One of the oddities of the evolution of this business....

       -- Jerry


[ 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:
>
> Francis Glassborow wrote:
> >
> > In addition I think that the
> > escape character is a specific code in a particular character set.
> > OTOH \t, etc. refer to a representation of specific control
> > characters regardless as to the character set in use.
>
> Let me put that a bit more strongly. The effect of using \t, etc. is
> described in the language definition: \t produces a tab, \a produces
> some sort of alert, etc. That is, they have observable consequences,
> and those consequences are what the standard describes. What are the
> observable consequences of escape?

Yeah, that was more or less the committee response when I suggested
that we needed an '\e' character sequence years ago.  Apparently,
no one has been clever enough to come up with a written description
of the semantics of the control character ESC, even though everyone
damn well knows what it means.

Some of the ISO multibyte character sets are defined in terms of
"shift in" and "shift out" sequences, and VT-100 terminal protocol
(which uses ESC extensively) is something of a de facto standard, so
these could probably serve as a guiding example of how to define the
semantics of ESC on paper.  It really isn't that mystical, is it?

And don't get me started on "newline" versus "linefeed"...

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

Greg Brewer wrote:
>
> Francis Glassborow <francis@robinton.demon.co.uk> wrote
> > In article <7p1u5o$ipi$1@news.hal-pc.org>, Greg Brewer
> > What has any of this to do with C++?  In addition I think that the
> > escape character is a specific code in a particular character set.
> > OTOH \t, etc. refer to a representation of specific control
> > characters  regardless as to the character set in use.
>
> What does it have to do with C++?  Well, the programming language I
> was using was C++.
>
> I'm trying to remember my IBM days dealing with EBCDIC.  If I remember
> correctly, that character set has no tab, newline, carriage return,
> or alarm character.  I could easily be wrong, it has been almost 10
> years.

You're wrong.  Perhaps you're remembering that your 3270 terminal
didn't have keys for those characters, which is partially correct,
but EBCDIC does indeed have them.  EBCDIC has all of the control
characters that ASCII has, in fact (and about 30 more, to boot).

   Char  ASCII EBCDIC
    NUL   00    00
    BEL   07    2F
    BS    08    16
    HT    09    05
    LF    0A    25
    VT    0B    0B
    FF    0C    0C
    CR    0D    0D
    NL    -     15
    DEL   7F    07
    etc.

(Much as I hate EBCDIC, I am forced to admit that it did a slightly
better job by providing an explicit "newline" (NL) character;
C/C++ grabbed "linefeed" (LF) for this purpose, which is logically
only half of the motion of a printer head.  Oh, well.)

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

One of the things that impressed me most when I first started using C was
the power of the standard C library.  It occurred to me that a lot of these
functions were useful in writting the C compiler.  I found the idea of
writting a C compiler in C somewhat amusing.  Over the years, I have gotten
a lot of use out of functions suchs as stpcpy, strcspn, etc.

A few years ago, I had to modify a DOS application to allow the user to
enter a printer initialization/deinitialization string and save that as a
default.  I was surprised by two shortcomings: that the string functions
does not a function to translate strings from their code representation (eg
"abc\t\a\n") to their internal representation and that there is no line code
sequence for representing the escape character (ie '\e').  I know there is a
hex, octal, etc sequence for that represents escape; the same is true for
tab, bell, and the rest.

Once upon a time, escape was so common for controlling printers and remote
terminals that I don't understand why it is not included in the \ character
set.  Since the function for translating strings from their "visual" form is
necessary for the compiler to operate, why isn't the function in the
standard C library.

Are escape sequences so passe that this code is unnecessary?  Any comments?
---
[ 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 <7p1u5o$ipi$1@news.hal-pc.org>, Greg Brewer
<nospam.gregb@hal-pc.org> writes
>Once upon a time, escape was so common for controlling printers and remote
>terminals that I don't understand why it is not included in the \ character
>set.  Since the function for translating strings from their "visual" form is
>necessary for the compiler to operate, why isn't the function in the
>standard C library.
>
>Are escape sequences so passe that this code is unnecessary?  Any comments?

What has any of this to do with C++?  In addition I think that the
escape character is a specific code in a particular character set.  OTOH
\t, etc. refer to a representation of specific control characters
regardless as to the character set in use.


Francis Glassborow      Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ 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 <7p1u5o$ipi$1@news.hal-pc.org>,
Greg Brewer <nospam.gregb@hal-pc.org> wrote:
>Once upon a time, escape was so common for controlling printers and remote
>terminals that I don't understand why it is not included in the \ character
>set.  Since the function for translating strings from their "visual" form is
>necessary for the compiler to operate, why isn't the function in the
>standard C library.

These days such things are almost always done using libraries like curses,
so it's not necessary to hard-code escape sequences into applications.
Therefore, they don't generally need to mention the ESC character
explicitly.  Even the library doesn't usually need to refer to it, because
they're generally table-driven; the ESC character will only appear in the
terminal control database files (e.g. termcap or terminfo).

--
Barry Margolin, barmar@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
---
[ 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 <francis@robinton.demon.co.uk> wrote in message
news:KrOnmwAFfIu3Ew3O@robinton.demon.co.uk...
> In article <7p1u5o$ipi$1@news.hal-pc.org>, Greg Brewer
> What has any of this to do with C++?  In addition I think that the
> escape character is a specific code in a particular character set.  OTOH
> \t, etc. refer to a representation of specific control characters
> regardless as to the character set in use.

What does it have to do with C++?  Well, the programming language I was
using was C++.

I'm trying to remember my IBM days dealing with EBCDIC.  If I remember
correctly, that character set has no tab, newline, carriage return, or alarm
character.  I could easily be wrong, it has been almost 10 years.

Greg Brewer



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

Greg Brewer wrote:
>
> I'm trying to remember my IBM days dealing with EBCDIC.  If I remember
> correctly, that character set has no tab, newline, carriage return, or alarm
> character.  I could easily be wrong, it has been almost 10 years.
>

This is getting off subject...

EBCDIC has HT, LF, CR and BEL defined. I'm not absolutely positive but I
think FF was also defined. I'd have to dig out an old green card to get
you their values. It's in a box with a bunch of other stuff from the '60s
and '70s so it would be a real tough hunt...

mtew@cds.duke.edu


[ 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:
>
> In addition I think that the
> escape character is a specific code in a particular character set.  OTOH
> \t, etc. refer to a representation of specific control characters
> regardless as to the character set in use.
>

Let me put that a bit more strongly. The effect of using \t, etc. is
described in the language definition: \t produces a tab, \a produces
some sort of alert, etc. That is, they have observable consequences, and
those consequences are what the standard describes. What are the
observable consequences of escape?

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