Pete Becker <petebecker@acm.org> writes:
> Hyman Rosen wrote:
> > Obviously the C++ standard writers saw the problem and chose to
> > address it properly.
> As one of the C++ standard writers, I can tell you that I do not recall
> any such decision. The words in the C++ standard appear in the ARM, with
> a note that says nothing about why they are different from what is in
> the C standard, but that does suggest a misunderstanding of the C
> standard.

Then perhaps B.S. saw the problem and chose to address it properly.

I looked in the ARM, and saw nothing that suggests a misunderstanding
of the C standard. The note after the escape table says that causing
'\c' to be undefined, where c is a character different from any of
those in the table, is different from Classic C and early C++, where
it would just have been interpreted as 'c'. Classic C is not Standard
C, if that's what you're getting at.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, 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 <t7wvt8qbod.fsf@calumny.jyacc.com>,
Hyman Rosen  <hymie@prolifics.com> wrote:
>Run this program, then use a system utility to examine the contents
>of the file named "joe". If the first three bytes (on an ASCII system)
>aren't 13, 9, and 8, that's one ex-compiler.

I used a compiler that did 10 for \r and 13 for \n by default, because it
was a Mac compiler, and on a Mac, \r is the default line-ending.  Rather,
it did this by default in text mode; if you had done "wb", you would have
gotten what you expect.

I originally thought it was wrong, but eventually concluded that it was
right, in so far as any compiler in such a stupidly wrong environment
can be "right".  ;)

-s
--
Copyright 1999, All rights reserved.  Peter Seebach / seebs@plethora.net
C/Unix wizard, Pro-commerce radical, Spam fighter.  Boycott Spamazon!
Will work for interesting hardware.  http://www.plethora.net/~seebs/
Visit my new ISP <URL:http://www.plethora.net/> --- More Net, Less Spam!
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Pete Becker <petebecker@acm.org> wrote in message
news:37F0041D.99100AB1@acm.org...
> about control characters. One caution: if you persist in hypertechnical
> parsings of words in messages, others will respond in kind, and the
> discussion will bog down. Which will, in turn, pretty much eliminate any
> chance of persuading anyone that anything ought to be changed.

Pete, have you been playing devil's advocate here?

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:m3d7v0eylf.fsf@multivac.student.cwru.edu...
> > No, nothing is broken.  Existing programs using \x7f use that value in a
> > native context; whatever that is.
>
> That native context could include writing to a printer.

Okay, if that native context is writing to a native printer then there is
still no problem because that printer would not be connected using the
converter.  If the printer is not a native printer and the system things it
is, you are not going to get good results whether a converter is attached
whether the converter is present or not.  Moreover, you are going to get the
same results whether or not a \e is in the standard as an escape 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              ]

Paul Jarc wrote:
>
> Pete Becker <petebecker@acm.org> writes:
> > Paul Jarc wrote:
> > > The only sensible interpretation of "are intended to" is that it
> > > does not impose a requirement.  Why do you interpret it
> > > differently?
> >
> > Because I know what "normative" means.
>
> But don't you also know what "intended" means?  And given the
> conflict, shouldn't the more specific one (i.e., the one with narrower
> scope, not narrower meaning) take precedence?
>

What conflict? "Normative" and "intended" are not mutually exclusive.

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

Ross Smith <ross.s@ihug.co.nz> writes:
> What's wrong with
>
>     #if 'A' == 65
>       #define ASCII
>       #define ESC "\033"
>     #else
>       #define EBCDIC
>       #define ESC "\047"
>     #endif

In practice, this will often work, but 'A' (and charcter constants in
general) need not have the same value during preprocessing as at
runtime.


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:
> Let us say that the computer in questions uses x7f for some purpose -- who
> cares what -- and the translators used to hook an ASCII printer decides to
> use x7f as the character to translate to ASCII ESC and so the compiler
> implementer maps \e to x7f.  So a program that worked before \e is
> implemented is recompiled and executed.  It will still execute exactly as
> before!

Not if it relies on \x7f to have its native meaning.

> I guess that does exactly match what you said since you stipulated that the
> program will break "if used with [my] translator and printer."  So lets say
> we have a system with programs.  We upgrade the compiler to that it is
> exactly as before except it now translates \e to some character code.  We
> then recompile everything on the system.  All programs should produce
> exactly the same binaries since none of the existing programs used the new
> \e coding.  Next, lets attach a translator and printer.  Again, no change
> since no program actually uses the new \e coding

No, this is where things break.  No existing programs have \e in their
source, but they may be using \x7f, by whatever representation in the
source, and they may rely on that character to perform the action it
does natively.  Your translator prevents them from behaving the way
they expect 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 Jarc wrote:
>
> Pete Becker <petebecker@acm.org> writes:
> > Paul Jarc wrote:
> > > The standard suggests behavior for control characters on display
> > > devices.
> >
> > No. The C standard talks about the behavior of alphabetic escape
> > sequences. An alphabetic escape sequence occurs in the source code. One
> > way of implementing that behavior is for the compiler to map each
> > alphabetic escape sequence into an appropriate control character for
> > output, but that technique is not required by the standard.
>
> (and in another message:)
>
> > iscntrl has nothing to do with the display semantics of alphabetic
> > escape sequences.
>
> iscntrl has *everything* to do with the display semantics of
> alphabetic escape sequences.  I'm beginning to think that you've never
> even looked at any part of the standard outside the description of \t
> that you keep quoting.  C9X 7.4.1.3p2:
> # The iscntrl function tests for any control character.
>
> And what is a control character?  7.4p3 says:
> # The term printing character refers to a member of a locale-specific
> # set of characters, each of which occupies one printing position on a
> # display device; the term control character refers to a member of a
> # locale-specific set of characters that are not printing characters.
>
> 5.2.1p3:
> # Both the basic source and basic execution character sets shall have
> # at least the following members: ... control characters representing
> # horizontal tab, vertical tab, and form feed....  In the execution
> # character set, there shall be control characters representing alert,
> # backspace, carriage return, and new line.
>
> The characters produced by alphabetic escape sequences do not "occupy
> one printing position on a display device", assuming they follow the
> intent of 5.2.2p2.  They are also explicitly listed as control
> characters here in 5.2.1.
>
> > The reason for specifying it that way is to avoid exactly what has
> > been happening throughout this thread: analyzing expected behavior
> > based on common perceptions of what various control characters are
> > supposed to do.
>
> You're right that people have been confused in this: they think that
> each control character in the C standard is perfectly bound to its
> conventional representation and interpretation.  But you have
> apparently also been confused: you seem to think that the term
> "control character", as used in the standard, is perfectly bound to
> the conventional usage.
>
> > \t occurs in the program's source code. It is not a control character.
> > It is an alphabetic escape sequence.
>
> Until translation phase 5.  At that point, it is mapped to the
> horizontal tab control character.  The behavior produced on a display
> device comes after translation phase 5, so it's not unreasonable to
> talk about the display effect of a control character.
>

And what does all that tell you about the display semantics of
alphabetic escape sequences that is not contained in the description of
their 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              ]

Paul Jarc <prj@po.cwru.edu> wrote in message
news:m3ogek6vtv.fsf@multivac.student.cwru.edu...
> "Greg Brewer" <nospam.greg@brewer.net> writes:
> > Let us say that the computer in questions uses x7f for some purpose -- who
> > cares what -- and the translators used to hook an ASCII printer decides to
> > use x7f as the character to translate to ASCII ESC and so the compiler
> > implementer maps \e to x7f.  So a program that worked before \e is
> > implemented is recompiled and executed.  It will still execute exactly as
> > before!
> Not if it relies on \x7f to have its native meaning.

Devices relaying on \x7f to have its native meaning will only see \x7f in
its native context.

> > I guess that does exactly match what you said since you stipulated that the
> > program will break "if used with [my] translator and printer."  So lets say
> > we have a system with programs.  We upgrade the compiler to that it is
> > exactly as before except it now translates \e to some character code.  We
> > then recompile everything on the system.  All programs should produce
> > exactly the same binaries since none of the existing programs used the new
> > \e coding.  Next, lets attach a translator and printer.  Again, no change
> > since no program actually uses the new \e coding
> No, this is where things break.  No existing programs have \e in their
> source, but they may be using \x7f, by whatever representation in the
> source, and they may rely on that character to perform the action it
> does natively.  Your translator prevents them from behaving the way
> they expect to.

No, nothing is broken.  Existing programs using \x7f use that value in a
native context; whatever that is.  The translator is never involved in
native transactions.  It never sees any of the characters used by the
program unless those characters are sent to the printer port that it is
attached to.  I have seen programs that read data from files.  Each line or
record is divided in fields.  Some programs use commas to divide fields,
some programs use tabs to divide fields, and some programs use something
else to divide fields.  If one program that reads records with fields where
numbers contain embeded commas and fields are separated by tabs then the
fact that a comma means something different to this program has not effect
whatsoever on a program where comma separates the fields.  It is no
different in this case.

Escape only has meaning when given in context.  When directed at a display,
I don't know what it will do unless I am given the context.  In other words,
if it is a DOS machine I need to know if ANSI.SYS is loaded and what
characters follow it.  Without a context, it has about as much meaning as a
comma 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              ]

Pete Becker <petebecker@acm.org> writes:
> And what does all that tell you about the display semantics of
> alphabetic escape sequences that is not contained in the description of
> their behavior?

Nothing.  Why would you think I was trying to say otherwise?  You
seemed quite unaware of how "control character", as the standard uses
it, is related to "alphabetic escape sequence".  So I explained the
relationship for you.


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:
> > An implementation that didn't assign
> > the usual values to these alphabetic escape sequences would find itself
> > shown to the exit pretty quickly.
>
> Huh? How would anybody notice? If they do what they're supposed to do,
> you never see them.

#include <stdio.h>
int main() { return fputs("\r\t\b\n", fopen("joe", "w")); }

Run this program, then use a system utility to examine the contents
of the file named "joe". If the first three bytes (on an ASCII system)
aren't 13, 9, and 8, that's one ex-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 <petebecker@acm.org> writes:
> That and long searches of manuals will get you to something that
> actually does something useful. Until you have to move it to a different
> platform, and then you have to search the manuals for that platform to
> figure out whether the escape sequences that you wrote will do the same
> thing. Or, as we used to say back when coffee was cheaper, "that and 50
> cents will get you a cup of coffee."

You also have no assurance from the C standard that \t will be
written as 9, but try to find an ASCII implementation where that
is not the case. Think of what users of such a compiler would say
if they wrote what they thought were TABs into files and then
found that the files were incompatible with other system utilities.

This is so weird. The C standard chose to use language that makes
it stupidly difficult to describe a completely simple effect. You
seem to insist that this is a good thing and must be perpetuated.
Obviously the C++ standard writers saw the problem and chose to
address it properly.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, 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 <37F29CC3.9D4EB103@acm.org>...
>> Having it in the standard means that implementations will be required
>> to accept \e within string and character literals, and translate it to
>> a single control character. If it is not in the standard, no such
>> behavior can be assumed. I suspect most current implementations either
>> refuse to compile such literals, or turn '\e' into 'e'. Almost everyone
>> knows that once it is in the standard, it will become the ASCII ESC on
>> ASCII implementations, and will be written unchanged to the output.
>
>That and long searches of manuals will get you to something that
>actually does something useful. Until you have to move it to a different
>platform, and then you have to search the manuals for that platform to
>figure out whether the escape sequences that you wrote will do the same
>thing. Or, as we used to say back when coffee was cheaper, "that and 50
>cents will get you a cup of coffee."

You've got that backwards: anyone who knows that they need ESC in their data
knows to whom they will be sending it and what it does when it gets there.
Their long and fruitless search is in the C manual for a character that is
widely used and ought to be supported.

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" <nospam.greg@brewer.net> writes:
> Paul Jarc <prj@po.cwru.edu> wrote in message
> news:m3ogek6vtv.fsf@multivac.student.cwru.edu...
> > No existing programs have \e in their source, but they may be
> > using \x7f, by whatever representation in the source, and they may
> > rely on that character to perform the action it does natively.
> > Your translator prevents them from behaving the way they expect
> > to.
>
> No, nothing is broken.  Existing programs using \x7f use that value in a
> native context; whatever that is.

That native context could include writing to a printer.


paul


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

Hyman Rosen wrote:
>
> Pete Becker <petebecker@acm.org> writes:
> > That and long searches of manuals will get you to something that
> > actually does something useful. Until you have to move it to a different
> > platform, and then you have to search the manuals for that platform to
> > figure out whether the escape sequences that you wrote will do the same
> > thing. Or, as we used to say back when coffee was cheaper, "that and 50
> > cents will get you a cup of coffee."
>
> You also have no assurance from the C standard that \t will be
> written as 9, but try to find an ASCII implementation where that
> is not the case. Think of what users of such a compiler would say
> if they wrote what they thought were TABs into files and then
> found that the files were incompatible with other system utilities.

They would probably be quite upset. But that has nothing to do with
understanding what the C standard requires.

>
> This is so weird. The C standard chose to use language that makes
> it stupidly difficult to describe a completely simple effect. You
> seem to insist that this is a good thing and must be perpetuated.
> Obviously the C++ standard writers saw the problem and chose to
> address it properly.
>

As one of the C++ standard writers, I can tell you that I do not recall
any such decision. The words in the C++ standard appear in the ARM, with
a note that says nothing about why they are different from what is in
the C standard, but that does suggest a misunderstanding of 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:
>
> Pete Becker <petebecker@acm.org> wrote in message
> news:37F0041D.99100AB1@acm.org...
> > about control characters. One caution: if you persist in hypertechnical
> > parsings of words in messages, others will respond in kind, and the
> > discussion will bog down. Which will, in turn, pretty much eliminate any
> > chance of persuading anyone that anything ought to be changed.
>
> Pete, have you been playing devil's advocate here?
>

This thread has degenerated into quotes out of context, ad hominem
arguments, and personal innuendo. I will not take any further part in
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:
> Paul Jarc wrote:
> > The standard suggests behavior for control characters on display
> > devices.
>
> No. The C standard talks about the behavior of alphabetic escape
> sequences. An alphabetic escape sequence occurs in the source code. One
> way of implementing that behavior is for the compiler to map each
> alphabetic escape sequence into an appropriate control character for
> output, but that technique is not required by the standard.

(and in another message:)

> iscntrl has nothing to do with the display semantics of alphabetic
> escape sequences.

iscntrl has *everything* to do with the display semantics of
alphabetic escape sequences.  I'm beginning to think that you've never
even looked at any part of the standard outside the description of \t
that you keep quoting.  C9X 7.4.1.3p2:
# The iscntrl function tests for any control character.

And what is a control character?  7.4p3 says:
# The term printing character refers to a member of a locale-specific
# set of characters, each of which occupies one printing position on a
# display device; the term control character refers to a member of a
# locale-specific set of characters that are not printing characters.

5.2.1p3:
# Both the basic source and basic execution character sets shall have
# at least the following members: ... control characters representing
# horizontal tab, vertical tab, and form feed....  In the execution
# character set, there shall be control characters representing alert,
# backspace, carriage return, and new line.

The characters produced by alphabetic escape sequences do not "occupy
one printing position on a display device", assuming they follow the
intent of 5.2.2p2.  They are also explicitly listed as control
characters here in 5.2.1.

> The reason for specifying it that way is to avoid exactly what has
> been happening throughout this thread: analyzing expected behavior
> based on common perceptions of what various control characters are
> supposed to do.

You're right that people have been confused in this: they think that
each control character in the C standard is perfectly bound to its
conventional representation and interpretation.  But you have
apparently also been confused: you seem to think that the term
"control character", as used in the standard, is perfectly bound to
the conventional usage.

> \t occurs in the program's source code. It is not a control character.
> It is an alphabetic escape sequence.

Until translation phase 5.  At that point, it is mapped to the
horizontal tab control character.  The behavior produced on a display
device comes after translation phase 5, so it's not unreasonable to
talk about the display effect of a control character.


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:
> Paul Jarc wrote:
> > The only sensible interpretation of "are intended to" is that it
> > does not impose a requirement.  Why do you interpret it
> > differently?
>
> Because I know what "normative" means.

But don't you also know what "intended" means?  And given the
conflict, shouldn't the more specific one (i.e., the one with narrower
scope, not narrower meaning) take precedence?


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:
> Fergus Henderson wrote:
> > It is perfectly valid, useful, and practical to include in the standard
> > normative statements which do not form part of the requirements for
> > conformance.
>
> If that were true there would be no need for special markers such as
> "note", "example", etc. to indicate text that is non-normative.

Perhaps no need, but certainly not no use.  Standard authors have
enough to deal with in getting the normative wording to say what they
want it to say.  Marking certain passages as explicitly non-normative
lets them worry less about the implications of that text and about
possible conflicts with normative text.


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 in message
news:m3wvtcs0oe.fsf_-_@multivac.student.cwru.edu...
> "Greg Brewer" <nospam.greg@brewer.net> writes:
> > 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.
>
> But *your* supposedly "portable" program, which uses \e, won't do
> anything like what it does on your system.  How portable is that?

Yes it will.  If I am sending an escape sequence through a port of any of
the systems mentioned and the printer is an HP printer and \e has been set
to the correct character for the journey then the HP will print as I expect
it.  So if the converter that connects the HP printer to the Psion 3a
converts x7f to x1b and \e causes x7f to be placed in the character string
at that location, the program I wrote will compile and execute as I expect
on either DOS or Psion 3a.  Now, if the manufacturer of the Psion 3a doesn't
want you connecting ascii printers to the system they may provide no
converter and  no standards for the conversion and 3rd parties who decide to
manufacture converters for the Psion 3a my decide on different binary values
for the conversion to x1b.  In this case, there would be a problem for the C
implementor.  Personally, I don't see this happening.

> > 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.
>
> That would be problematic.  It would require a translation from the
> native character set to the character set that the printer
> understands.  Programs might actually use every character in the
> native set (collectively; no one program need do so individually), and
> expect each to have its native behavior.  Then any character in the
> native set that you commandeer for translation to ESC will break some
> program, if used with your translator and printer.

How?  Let us say that the computer in questions uses x7f for some purpose --
who cares what -- and the translators used to hook an ASCII printer decides
to use x7f as the character to translate to ASCII ESC and so the compiler
implementer maps \e to x7f.  So a program that worked before \e is
implemented is recompiled and executed.  It will still execute exactly as
before!  Whatever method was used to place the x7f value into a string is
still valid so those strings will still look exactly the same.

I guess that does exactly match what you said since you stipulated that the
program will break "if used with [my] translator and printer."  So lets say
we have a system with programs.  We upgrade the compiler to that it is
exactly as before except it now translates \e to some character code.  We
then recompile everything on the system.  All programs should produce
exactly the same binaries since none of the existing programs used the new
\e coding.  Next, lets attach a translator and printer.  Again, no change
since no program actually uses the new \e coding and unless some plug and
play implementation detected the attachment, the system doesn't even know
the new hardware is present.

Next, we do what ever is necessary to make the new printer known to the
system.  I would expect that we would have to define it as a generic impact
printer.  Again no difference since the new \e isn't used by anything.  Now,
we are getting down to the nitty gritty.  This system is treating the new
high-end, fancy dancy printer as a really dump printer.  Output doesn't look
right because the application that is sending the output to it is trying to
underline text by sending a two lines of text to the same line, the first
one only contains the underline characters in the correct relative position
for the character that is supposed to be underlined.  Trouble is that
printers default font is proportional and the characters don't line up
properly.   So, after going through the printer manual, you discover an
escape sequence that will set the printer so that your output will lineup
properly.  You also know how to hook a program into your application so that
it will call a program with the name of the destination before sending the
print stream.  So all you need to do is write a program, configure the
application to run it before printer and you are home free.

So you write the program.  It tests to see if the output is the new printer.
If it is then you output a string with the escape sequence to it.  Now what
character do you send to the printer so that it gets the escape character.
You don't know but you don't need to; you just code in \e.

Now, how does sending \e down the pipeline to the printer break any other
program.  If \e was not available, you would have had to find out what
character to code for the escape character anyway.  The fact that the same
binary code is used to mean something else in all other parts of the code in
no way impacts that code or this code.  It just works!

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:
>
> Pete Becker <petebecker@acm.org> writes:
> > If it's in the standard as simply a name for a particular character it's
> > not undefined. It's merely useless. Under those circumstances you cannot
> > write code that uses \e without knowing what your particular
> > implementation will do with it. From a practical perspective that's no
> > better than having undefined behavior.
>
> Having it in the standard means that implementations will be required
> to accept \e within string and character literals, and translate it to
> a single control character. If it is not in the standard, no such
> behavior can be assumed. I suspect most current implementations either
> refuse to compile such literals, or turn '\e' into 'e'. Almost everyone
> knows that once it is in the standard, it will become the ASCII ESC on
> ASCII implementations, and will be written unchanged to the output.

That and long searches of manuals will get you to something that
actually does something useful. Until you have to move it to a different
platform, and then you have to search the manuals for that platform to
figure out whether the escape sequences that you wrote will do the same
thing. Or, as we used to say back when coffee was cheaper, "that and 50
cents will get you a cup of coffee."

--
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 reason
> > for specifying it that way is to avoid exactly what has been happening
> > throughout this thread: analyzing expected behavior based on common
> > perceptions of what various control characters are supposed to do.
>
> Of course, this ignores the historical fact that the alphabetic escape
> sequences pre-date the C standard, and were in fact representations of
> some useful control characters.

Be leary of analogies, regardless of how close a historical parallel you
think there is. The standard defines what the alphabetic escape
sequences do.

> An implementation that didn't assign
> the usual values to these alphabetic escape sequences would find itself
> shown to the exit pretty quickly.
>

Huh? How would anybody notice? If they do what they're supposed to do,
you never see 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              ]

Greg Brewer wrote:
>
> Paul Jarc <prj@po.cwru.edu> wrote in message
> news:m33dw0thn9.fsf_-_@multivac.student.cwru.edu...
> > "Greg Brewer" <nospam.greg@brewer.net> writes:
> > > I know of no implementations of that define ASCII.
> >
> > Try reading what I wrote.  I said *you* #define ASCII on your ASCII
> > systems, *you* #define EBCDIC on your EBCDIC systems, etc.  No one is
> > claiming that they are defined for you.
>
> I have no way of detecting the character set so how am I supposed to know
> which one to define?

What's wrong with

    #if 'A' == 65
      #define ASCII
      #define ESC "\033"
    #else
      #define EBCDIC
      #define ESC "\047"
    #endif

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

"Greg Brewer" <nospam.greg@brewer.net> writes:
> Paul Jarc <prj@po.cwru.edu> wrote in message
> news:m33dw0thn9.fsf_-_@multivac.student.cwru.edu...
> > Try reading what I wrote.  I said *you* #define ASCII on your ASCII
> > systems, *you* #define EBCDIC on your EBCDIC systems, etc.  No one is
> > claiming that they are defined for you.
>
> I have no way of detecting the character set so how am I supposed to know
> which one to define?

I'll spell it out.

/* charset.h, on an ASCII system.  You provide this. */
#define ASCII 1

/* charset.h, on an EBCDIC system.  You provide this. */
#define EBCDIC 1

/* esc.h, portable to any system that has charset.h */
#include "charset.h"
#if defined(ASCII)
#define ESC "\033"
#elif defined(EBCDIC)
#defined ESC "\047" /* IIRC */
/* ... */
#endif
/* perhaps provide other charset-related macros as well... */

charset.h is not portable.  It's not meant to be.  It's meant to do
the nonportable work that esc.h needs.  charset.h is like an
implementor's choice of value for \e - it can't be done without
knowledge of the particular system.  There's nothing wrong with this.
No one expects any particular value for \e to work on all systems, nor
should anyone expect any particular implementation of charset.h to
work on all systems.

> > > \e would be a lot easier and portable to boot.
> >
> > It's no more portable.  You can provide a value for ESC just as easily
> > as an implementor can for \e.  The only difference is whether it's
> > done by you, or by implementors.
>
> Yes it is more portable.  The implementor knows what character set is in
> use; I do not!

Yes, you do - on any particular system, you know the character set in
use.  So you provide a (nonportable) charset.h specific to that
system.  esc.h is then portable to that system.  Having \e in the
language wouldn't be any more portable, because someone still has to
determine the value it should have on any particular system before it
can be used on that system.


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              ]

Ross Smith wrote:
...
> What's wrong with
>
>     #if 'A' == 65
>       #define ASCII
>       #define ESC "\033"
>     #else

This should also contain an 'if', based upon the EBCDIC value.

>       #define EBCDIC
>       #define ESC "\047"

      #else
        #error character set unrecognised.

>     #endif

This is safer, but will still produce incorrect results for any
character set that happens to use the same value for 'A' as one of those
two character sets, but uses a different value for the escape. However,
I suppose that the kind of programmer who is willing to assume that
ASCII and EBCDIC are the only two possibilities, won't care about 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              ]

Pete Becker <petebecker@acm.org> writes:
> Paul Jarc wrote:
> > "Greg Brewer" <nospam.greg@brewer.net> writes:
> > > 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);
> > > }
> >
> > There's no `stdprn' in standard C, to say nothing of this use of \e.
>
> This was an example of the proposed use of \e, so of course it uses \e.
> And even though there's no stdprn, it's clear what the example means.

Yes, but Greg posted this in response to your request for a
nontrivial, portable use of \e, IIRC.  stdprn and this use of \e
aren't portable; that's all I meant to say.


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:
> Paul Jarc wrote:
> > The standard suggests behavior for control characters on display
> > devices.
> No. The C standard talks about the behavior of alphabetic escape
> sequences. An alphabetic escape sequence occurs in the source code. One
> way of implementing that behavior is for the compiler to map each
> alphabetic escape sequence into an appropriate control character for
> output, but that technique is not required by the standard.

The standard requires that each alphabetic escape sequence be
represented as a single char object. The standard describes the
intended behavior when an alphabetic escape sequence is sent to a
display. When a character is sent to the runtime for printing, the
runtime has no information as to whether this character originated as
an alphabetic escape sequence. So if the runtime is to implement the
standarad-mandated display behavior, it can only do so by acting
specially for certain character values. We usually refer to characters
that cause such special behavior as control characters. Therefore, you
should have started your answer with "Yes".

> The reason
> for specifying it that way is to avoid exactly what has been happening
> throughout this thread: analyzing expected behavior based on common
> perceptions of what various control characters are supposed to do.

Of course, this ignores the historical fact that the alphabetic escape
sequences pre-date the C standard, and were in fact representations of
some useful control characters. An implementation that didn't assign
the usual values to these alphabetic escape sequences would find itself
shown to the exit pretty quickly.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, 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:
> > The words you quoted tell you that when the phrases "shall" and "shall
> > not" mean. They do not tell you what any other phrase means.
>
> Nor do any words in the standard tell you that anything other than
> "shall" means "this is a requirement".  The only sensible
> interpretation of "are intended to" is that it does not impose a
> requirement.  Why do you interpret it differently?
>

Because I know 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              ]

Paul Jarc wrote:
>
> Pete Becker <petebecker@acm.org> writes:
> > Fergus Henderson wrote:
> > > I believe ISO has a meta-standard about the language used in standards,
> > > which I think states that all requirements for conformance should be stated
> > > using ``shall''.  Unfortunately I can't give a more precise reference.
> >
> > Yes, but that's a rule of writing style, not a rule of interpretation.
>
> Are you saying that we should deliberately ignore the meaning intended
> by the standard's authors?

On the contrary: I think we must give great weight to the intent of the
standard's authors, particularly when they did not use any of the
allowable mechanisms to make their statements about the effects of the
alphabetic escape sequences non-normative.

>That negates the idea of communication.
> If the standard's authors followed ISO's rule in writing the standard,
> then we should follow it in interpreting the standard.

Good advice on how to write clearly is not necessarily good advice on
how to read well.

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

Fergus Henderson wrote:
>
> It is perfectly valid, useful, and practical to include in the standard
> normative statements which do not form part of the requirements for
> conformance.

If that were true there would be no need for special markers such as
"note", "example", etc. to indicate text that is non-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              ]

Paul Jarc <prj@po.cwru.edu> wrote in message
news:m33dw0thn9.fsf_-_@multivac.student.cwru.edu...
> "Greg Brewer" <nospam.greg@brewer.net> writes:
> > I know of no implementations of that define ASCII.
>
> Try reading what I wrote.  I said *you* #define ASCII on your ASCII
> systems, *you* #define EBCDIC on your EBCDIC systems, etc.  No one is
> claiming that they are defined for you.

I have no way of detecting the character set so how am I supposed to know
which one to define?

> > > 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.
>
> Are you going to make me repeat every detail in every post?  The
> `/* or whatever */' comment should have made it obvious that ESC would
> get the proper value for each particular character set:
#define ASCII
>     #if defined(ASCII)
>     #define ESC "\033"
>     #elif defined(EBCDIC)
>     #defined ESC "\047" /* IIRC */
>     /* ... */
>     #endif
>
> The difference between my definition and the previous one was that
> mine was a string constant, not a character constant.  You should be
> able to figure out that I didn't mean for useful features of the
> previous suggestion to be abandoned, just for mine to be added.

Okay, I added one line since you now define that I must define ASCII.  It is
still wrong when compiled on an EBCDIC system.

> > \e would be a lot easier and portable to boot.
>
> It's no more portable.  You can provide a value for ESC just as easily
> as an implementor can for \e.  The only difference is whether it's
> done by you, or by implementors.

Yes it is more portable.  The implementor knows what character set is in
use; I do not!

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:
> The \ escape sequences all produce unique values, but that's still not
> likely to be a problem.  The problem is that some people are
> advocating that the standard require "ESC" - not "the escape
> character".  This requires that the character set must have a character
> named ESC, and doesn't require that character to be an escape
> character.

The C++ standard lists the alphabetic escape sequences in a table,
giving each one a name and a mnemonic, like so:

 horizontal tab HT \t
 backspace BS \b

Therefore, in C++, we would add this to the table:

 escape  ESC \e

In C, we would add something like "the effect of printing \e followed
by an unspecified number of characters is unspecified, regardless of
the other requirements of this section".

Both standards would add an escape character to the list of control
characters in the execution character set.

We're all agreeing to boycott any vendor who doesn't pick ASCII ESC
as the character vale of \e on ASCII implementations, or who doesn't
just copy it to the output stream. We'll send the surplus copies over
to Pete's house :-)


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, 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 in order to use \e meaningfully you must know details about the
> hardware and OS that the application is running on.

By an extraordinary coincidence, those are the people who want to use \e!


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, 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:

>Fergus Henderson wrote:
>>
>> Pete Becker <petebecker@acm.org> writes:
>>
>> >If it's in the standard as simply a name for a particular character it's
>> >not undefined. It's merely useless. Under those circumstances you cannot
>> >write code that uses \e without knowing what your particular
>> >implementation will do with it. From a practical perspective that's no
>> >better than having undefined behavior.
>>
>> I disagree.  Having \e in the standard would give you a stick with which
>> to beat uncooperative vendors.  Undefined behaviour, on the other hand,
>> (as is the current status quo) gives the vendor a stick with which to
>> beat the hapless programmer that should try to make use of such a construct.
>
>It's a rather short stick if it all it says is that it's
>implementation-defined.

That's OK: most vendors are actually pretty cooperative,
so a short stick would be sufficient.

So long as the standard makes it clear that "\e" is intended to be an
"escape" character (whatever that is), I'm sure implementations would
do something useful, even if the standard gives no clue as to what
an "escape" character is supposed to do.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, 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:
> Fergus Henderson wrote:
> > I believe ISO has a meta-standard about the language used in standards,
> > which I think states that all requirements for conformance should be stated
> > using ``shall''.  Unfortunately I can't give a more precise reference.
>
> Yes, but that's a rule of writing style, not a rule of interpretation.

Are you saying that we should deliberately ignore the meaning intended
by the standard's authors?  That negates the idea of communication.
If the standard's authors followed ISO's rule in writing the standard,
then we should follow it in interpreting the standard.  An exception
could be made if the standard explicitly said that it uses other
language to impose requirements, but there is no such statement.


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:
> Paul Jarc wrote:
> > Pete Becker <petebecker@acm.org> writes:
> > > 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.
> >
> > 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.

A program can't necessarily open a binary stream in such a way that it
knows it's writing to a display device, but it can happen without the
program's knowledge.  (I.e., the program knows that it has a binary
output stream, but it doesn't know that it's connected to a display
device.  In fact, the program can't know that it isn't connected to
one.)  The implementation is encouraged to perform display actions on
display devices, regardless of whether the program knows what it's
writing to, and regardless of the mode of the stream.


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

You know that stdio typically doesn't treat control characters
specially, and so you conclude that the implementation doesn't do
anything with them.  You're wrong.  "The implementation" includes more
than you think it does: it includes (or can, at least) whatever it is
that *does* handle control characters.

If that handling is not already being done, then how is an implementor
supposed to know what to do with them, if the standard does not
describe the behavior?  Relying on `common knowledge' is not
desirable.

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

Try reading what I wrote.  I said *you* #define ASCII on your ASCII
systems, *you* #define EBCDIC on your EBCDIC systems, etc.  No one is
claiming that they are defined for you.

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

Are you going to make me repeat every detail in every post?  The
`/* or whatever */' comment should have made it obvious that ESC would
get the proper value for each particular character set:
    #if defined(ASCII)
    #define ESC "\033"
    #elif defined(EBCDIC)
    #defined ESC "\047" /* IIRC */
    /* ... */
    #endif

The difference between my definition and the previous one was that
mine was a string constant, not a character constant.  You should be
able to figure out that I didn't mean for useful features of the
previous suggestion to be abandoned, just for mine to be added.

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

It's no more portable.  You can provide a value for ESC just as easily
as an implementor can for \e.  The only difference is whether it's
done by you, or by implementors.


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 wrote:
>
> "Greg Brewer" <nospam.greg@brewer.net> writes:
> > 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);
> > }
>
> There's no `stdprn' in standard C, to say nothing of this use of \e.

This was an example of the proposed use of \e, so of course it uses \e.
And even though there's no stdprn, it's clear what the example 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              ]

"Clive D.W. Feather" <clive@on-the-train.demon.co.uk> writes:
> It suddenly strikes me that the ASCII code "DLE" (16) probably has as
> good, if not better, claim to be "escape" than "ESC" (27). Certainly it
> matches every description I've seen posted so far.
>
> Can the pro-\e people explain why not ?

Because the devices which people using \e want to address use ASCII ESC
as the escape sequence lead-in character. The goal is to provide a useful,
not a useless, feature.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, 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:
> Here's the definition of "normative" from the Merriam-Webster Collegiate
> Dictionary:
>
> 1: of, relating to, or determining norms or standards <~ tests> 2:
> conforming to or based on norms <~ behavior> <~ judgments> 3:
> prescribing norms <~ rules of ethics> <~ grammar>
>
> Since ISO allows text in the standard to be non-normative under certain
> circumstances, it is clear that "normative" in ISO's usage does not
> simply refer to all of the text in a standard, so the first two parts of
> definition 1 (of, relating to) do not apply.. All the rest of the
> definitions involove imposing requirements.

So now all you need to do is discover which of those definitions the
standard means by "normative", and show that the standard *never*
deviates from using the word in exactly that way.


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

David R Tribble <david@tribble.com> writes:
> Paul Jarc wrote:
> > "David J. Littleboy" <davidjl@gol.com> writes:
> >> Paul Jarc wrote in message ...
> >> > To justify adding escapes for characters that aren't meant for
> >> > sending to display devices, you'd have to either show that the
> >> > control characters are widely used across multiple character sets,
> >>
> >> ESC, SI, and SO appear in ASCII, EBCDIC, and Unicode. Done.
> >>
> >> > or say what behavior these characters (are intended to) cause for
> >> > other kinds of output streams.
> >>
> >> The behavior of these codes are well-defined in various contexts
> >> (ISO-2022, various hardware devices), so that's done as well.
> >
> > There are other character sets that have C implementations, though.
> > By requiring an ESC in the execution character set, you'd make those
> > implementations nonconforming (and more importantly, eliminate the
> > possibility of having a conforming C implementation for such a
> > character set).  Standards aren't typically in the habit of forsaking
> > some platforms for a little convenience on others.
>
> The ISO C and C++ standards only require 99 distinct source and
> control character codes, but they also require 'char' to be at least
> 8 bits wide.  So it's hard for me to imagine an implementation that
> doesn't have room for a \e character (even if it duplicates an
> existing character code, provided it's not one of the standard 99
> codes).

The \ escape sequences all produce unique values, but that's still not
likely to be a problem.  The problem is that some people are
advocating that the standard require "ESC" - not "the escape
character".  This requires that the character set must have a character
named ESC, and doesn't require that character to be an escape
character.


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:
> 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);
> }

There's no `stdprn' in standard C, to say nothing of this use of \e.

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

That's a tab character on *input*.  The standard talks about tab
characters on *output*, and only to display devices.  A GUI probably
isn't a display device in the sense intended by the standard anyway.


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:
> The words you quoted tell you that when the phrases "shall" and "shall
> not" mean. They do not tell you what any other phrase means.

Nor do any words in the standard tell you that anything other than
"shall" means "this is a requirement".  The only sensible
interpretation of "are intended to" is that it does not impose a
requirement.  Why do you interpret it differently?


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

But *your* supposedly "portable" program, which uses \e, won't do
anything like what it does on your system.  How portable is that?

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

That would be problematic.  It would require a translation from the
native character set to the character set that the printer
understands.  Programs might actually use every character in the
native set (collectively; no one program need do so individually), and
expect each to have its native behavior.  Then any character in the
native set that you commandeer for translation to ESC will break some
program, if used with your translator and printer.


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 wrote:
>
> The standard suggests behavior for control characters on display
> devices.

No. The C standard talks about the behavior of alphabetic escape
sequences. An alphabetic escape sequence occurs in the source code. One
way of implementing that behavior is for the compiler to map each
alphabetic escape sequence into an appropriate control character for
output, but that technique is not required by the standard. The reason
for specifying it that way is to avoid exactly what has been happening
throughout this thread: analyzing expected behavior based on common
perceptions of what various control characters are supposed to do.
That's why I keep reciting:

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

\t occurs in the program's source code. It is not a control character.
It is an alphabetic escape sequence. Its effect is intended to be
exactly what the standard describes. No more, no less. It has no
inherent connection with the ASCII TAB character, except that their
definitions are similar enough that it is often convenient to implement
\t by sending ASCII TAB to the 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 Jarc wrote:
>
> Pete Becker <petebecker@acm.org> writes:
>
> > The fact is that ANSI says that text in examples and footnotes
> > is not normative, and that everything else is.
>
> So now all you need to do is show that all normative text necessarily
> imposes requirements.
>

Here's the definition of "normative" from the Merriam-Webster Collegiate
Dictionary:

1: of, relating to, or determining norms or standards <~ tests> 2:
conforming to or based on norms <~ behavior> <~ judgments> 3:
prescribing norms <~ rules of ethics> <~ grammar>

Since ISO allows text in the standard to be non-normative under certain
circumstances, it is clear that "normative" in ISO's usage does not
simply refer to all of the text in a standard, so the first two parts of
definition 1 (of, relating to) do not apply.. All the rest of the
definitions involove imposing requirements.

--
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:
> >
> > If it's in the standard as simply a name for a particular character it's
> > not undefined. It's merely useless. Under those circumstances you cannot
> > write code that uses \e without knowing what your particular
> > implementation will do with it. From a practical perspective that's no
> > better than having undefined behavior.
>
> You mean as useless as creating the file "foo", since there's
> no guarantee by the standard that there's really a file "foo"
> generated on disk? (The implementation could simply associate
> some program memory area with the name "foo" and do all
> operations there, which effectively causes the "file" to
> be private to the program and to disappear when the program does).

Interesting hypothesis, but I don't see where the standard permits this.

--
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:
>
> "David J. Littleboy" <davidjl@gol.com> writes:
>> Paul Jarc wrote in message ...
>> > To justify adding escapes for characters that aren't meant for
>> > sending to display devices, you'd have to either show that the
>> > control characters are widely used across multiple character sets,
>>
>> ESC, SI, and SO appear in ASCII, EBCDIC, and Unicode. Done.
>>
>> > or say what behavior these characters (are intended to) cause for
>> > other kinds of output streams.
>>
>> The behavior of these codes are well-defined in various contexts
>> (ISO-2022, various hardware devices), so that's done as well.
>
> There are other character sets that have C implementations, though.
> By requiring an ESC in the execution character set, you'd make those
> implementations nonconforming (and more importantly, eliminate the
> possibility of having a conforming C implementation for such a
> character set).  Standards aren't typically in the habit of forsaking
> some platforms for a little convenience on others.

The ISO C and C++ standards only require 99 distinct source and
control character codes, but they also require 'char' to be at least
8 bits wide.  So it's hard for me to imagine an implementation that
doesn't have room for a \e character (even if it duplicates an
existing character code, provided it's not one of the standard 99
codes).

-- 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:
> If it's in the standard as simply a name for a particular character it's
> not undefined. It's merely useless. Under those circumstances you cannot
> write code that uses \e without knowing what your particular
> implementation will do with it. From a practical perspective that's no
> better than having undefined behavior.

Having it in the standard means that implementations will be required
to accept \e within string and character literals, and translate it to
a single control character. If it is not in the standard, no such
behavior can be assumed. I suspect most current implementations either
refuse to compile such literals, or turn '\e' into 'e'. Almost everyone
knows that once it is in the standard, it will become the ASCII ESC on
ASCII implementations, and will be written unchanged to the output.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, 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:
>> > Paul Jarc wrote:
>> > > 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.
>>
>> Yes; I was sloppy.  I meant: how do you maintain that that text
>> imposes requirements?
>
>Because that's what a standard does -- its normative text gives the
>meaning of the constructs in a  valid program.

Yes, but constructs can have a meaning without that being a strict
requirement that is needed for conformance.  ISO standards are allowed
to use "should" as well as "shall".  Some standards, such as the Ada
standard, make this extremely clear, with separate "Implementation
Advice" sections.  Others, such as the C standard, mix requirements and
intent without such clear distinctions, to the point where many
involved in the standards process seem to be unaware of the possibility
of including normative text that is not a strict requirement for
conformance in a standard.

It is perfectly valid, useful, and practical to include in the standard
normative statements which do not form part of the requirements for
conformance.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, 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:
> > The C standard says nothing about "control characters," but it does
> > define the effect of writing a \n to a display device.
>
> $ egrep 'control +character' n2794.txt | wc -l
>       7

In the context of writing alphabetic escape sequences to display
devices, which is what we were discussing, the standard says nothing
about control characters. One caution: if you persist in hypertechnical
parsings of words in messages, others will respond in kind, and the
discussion will bog down. Which will, in turn, pretty much eliminate any
chance of persuading anyone that anything ought to be changed.

--
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:
>
> Paul Jarc 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.
> >
> > $ egrep 'control +character' n2794.txt | wc -l
> >       7
>
> Which brings up a related issue: iscntrl('\t') is not defined anywhere
> (for '\t' and any other "control character" escape sequence).

Seems to me that this is an unrelated issue. <g> iscntrl has nothing to
do with the display semantics of alphabetic escape sequences.

--
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" <nospam.greg@brewer.net> writes:
> 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.

That handling is for "external representation of text files".  This is
a separate issue from display actions.  The transformation applied to
\n is done so that the display action won't require additional
handling, but that's just for convenience.

You still missing the point, though: *something* handles control
characters (even if it doesn't do quite all of the handling itself).
That something handles control characters approximately as described
by the standard, and it also handles the escape character.  Its
treatment of the escape character is what should be described.

The something that handles control characters is not something that
you are accustomed to thinking of as part of your C implementation,
but it is indeed part of the implementation (or can be, at least).

For all the other control characters, it's clear that the standard is
not describing something that passes them to the next level.  Why do
otherwise for \e?

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

"Device defined" is not a term used in the standard.  It could be
used, but you'd have to come up with a definition for it, which seems
like an awful lot of work for such a minor feature.

Also, note that "implementation-defined" just means that the
implementation documents how the feature works; the implementation may
say "\e is handled however the receiving device interprets it".

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

But you are, in fact, relying on at least a suggestion of what \e
would do.  If the standard said nothing but "\e exists", then all that
would come close to making \e portable would be market forces.  Market
forces are effective, but normative wording is preferable, at least
for some of us.


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 <37F01ABA.894840E3@acm.org>, Pete Becker <petebecker@acm.org>
writes
>> I disagree.  Having \e in the standard would give you a stick with which
>> to beat uncooperative vendors.

>It's a rather short stick if it all it says is that it's
>implementation-defined. It's even shorter, because no compiler vendor
>will specify in detail what effect \e has

It suddenly strikes me that the ASCII code "DLE" (16) probably has as
good, if not better, claim to be "escape" than "ESC" (27). Certainly it
matches every description I've seen posted so far.

Can the pro-\e people explain why not ?

--
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:
> Paul Jarc <prj@po.cwru.edu> wrote in message
> news:m3g1049cky.fsf_-_@multivac.student.cwru.edu...
> > Modern compilers for DOS/Windows will (I expect) still perform the
> > translation on output, and perhaps perform it only if needed on
> > input.
>
> The point was that you would not be able to tell from observation that the
> output was done in binary mode on recent versions of the OS and you could
> tell on earlier versions.

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.


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 wrote:
>
> Pete Becker <petebecker@acm.org> writes:
> > 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.
>
> 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.

--
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:
> > Pete Becker <petebecker@acm.org> writes:
> > > Sure: it's required unless it can't be done reasonably.
> >
> > Absolutely nowhere does the standard make requirements of that nature.
> > All requirements are absolute, ignoring the hosted/freestanding issue.
> > A requirement with a condition like yours is no requirement at all; an
> > implementor can say "that's not feasible here" for any such
> > requirement.  Conformance is discrete.  Feasibility is fuzzy.
> > Conformance can't depend on feasibility.
> >
>
> And where did you get this definition of conformance?

>From clause 4, where it talks about what signifies a requirement.
Note that there is no mention of feasibility.  Where did you get your
definition, which requires the implementor to evaluate the feasibility
of implementing a language feature?

I agree that in practice, it can be hard to tell whether an
implementation is conforming, and it may require some judgment calls.
But this is not desirable, and the standard certainly doesn't
explicitly require judgment calls.


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:
> The C standard says nothing about "control characters," but it does
> define the effect of writing a \n to a display device.

$ egrep 'control +character' n2794.txt | wc -l
      7


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:
> Nick Maclaren <nmm1@cus.cam.ac.uk> wrote in message
> news:7sfnkn$ccs$1@pegasus.csx.cam.ac.uk...
> > 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.

freopen(), with a NULL filename, can be used for that purpose (at
least in C9X).

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

1. There are no "stric[t]ly conforming implementations".  There are
   only conforming and nonconforming.  "Strictly conforming" applies
   to programs.  ("Conforming" also applies to programs.)
2. Strictly conforming programs can *not* use functions not provided
   by the standard.  Using them does indeed make the program 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.

There's no standard way to duplicate stdout or stderr, or to open
/dev/tty (or whatever).


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

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.

> Pete Becker <petebecker@acm.org> wrote in message
> news:37EC3125.EA4EBBAA@acm.org...
> > #if ASCII
> > #define ESC '\033'
> > #elif EBCDIC
> > #define ESC 'whatever'
> > #else
> > ....
> > #endif
>
> 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.

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.

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

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;

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


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:
> Paul Jarc wrote in message ...
> >> ESC is well-defined (but with different values) in all the major
> >> execution character sets, and thus a prime candidate for providing as
> >> a language feature.
> >
> >True, AFAIK.  \e is on (nearly) the same footing as \n et al.
>
> Whew. Someone agrees with me on something at least.

Except that now I noticed Clive has given a couple of character sets
that have no escape character.  (Presumably, they have conforming C
implementations, or this wouldn't be too relevant.)  So I retract my
claim, or I amend "nearly" to be something a little less near.

> >The only purpose for having \ sequences for them is so the programmer
> >has a way to get the required or intended behavior.
>
> I really dislike talking about "required or intended behavior". Why? Because
> behavior occurs when a particular character code is interpreted by a
> particular recipient. There are lots of recipients: modems, printers, glass
> TTY's, buffers that are being displayed by a word processor as proprietary
> commands, buffers that are being displayed by a word processor as JIS,
> buffers that are being displayed by a word processor as Shift JIS.

The standard suggests behavior for control characters on display
devices.  For other recipients of control characters, you want some
particular behavior to be produced.  So you need *something* to tell
you what behavior a particular control character is required or
intended to produce on a particular device.  Given that the C standard
doesn't bind itself to any particular character set, you need that
description in the C standard itself.

> What I'd like from my language is a way of portably and reliably expressing
> the codes I need to appear in my data.

If you need particular byte values in your code, then you can do that
already with hex or octal character constants.  If you need an
arbitrary value that will produce a particular behavior on a
particular device, then you need the language standard to tell you
what control characters are available, and what behavior they are
required or intended to produce on particular devices.

> >  To justify adding
> >escapes for characters that aren't meant for sending to display
> >devices, you'd have to either show that the control characters are
> >widely used across multiple character sets,
>
> ESC, SI, and SO appear in ASCII, EBCDIC, and Unicode. Done.
>
> > or say what behavior these
> >characters (are intended to) cause for other kinds of output streams.
>
> The behavior of these codes are well-defined in various contexts (ISO-2022,
> various hardware devices), so that's done as well.

There are other character sets that have C implementations, though.
By requiring an ESC in the execution character set, you'd make those
implementations nonconforming (and more importantly, eliminate the
possibility of having a conforming C implementation for such a
character set).  Standards aren't typically in the habit of forsaking
some platforms for a little convenience on others.


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 in message
news:m3u2ohjvrn.fsf_-_@multivac.student.cwru.edu...
>
> "Greg Brewer" <nospam.greg@brewer.net> writes:
> > 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.
>
> That's your own personal motivation.  Of course, others have other
> reasons for wanting \e.

Hince the words "short answer".  However, I think you are right since I
failed to note the word "only" in the original question.  Mea culpa as they
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              ]

Pete Becker wrote:
>
> Paul Jarc wrote:
> >
> > Pete Becker <petebecker@acm.org> writes:
> > > Christopher Eltschka wrote:
> > > > // 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?
> >
> > Nothing in Christopher's post suggested ASCII, and he stated that the
> > behavior would not be undefined.  The behavior for \033 is undefined.
> > There's your difference.  (I'll leave it to Christopher to defend the
> > claim that \e would not give undefined behavior.)
> >
>
> If it's in the standard as simply a name for a particular character it's
> not undefined. It's merely useless. Under those circumstances you cannot
> write code that uses \e without knowing what your particular
> implementation will do with it. From a practical perspective that's no
> better than having undefined behavior.

You mean as useless as creating the file "foo", since there's
no guarantee by the standard that there's really a file "foo"
generated on disk? (The implementation could simply associate
some program memory area with the name "foo" and do all
operations there, which effectively causes the "file" to
be private to the program and to disappear when the program does).

I guess there are lots of programs which assume creating
the file "foo" does leave something on their disk which
is named "foo" and still exists after the program ended.

The situation is actually worse: The implementation could
AFAIK just indicate failure on any attempt to do I/O, and
still be conforming. Does that make all I/O functionality
useless?
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, 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:
> > > > 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?
> > >
> > > Clause 4, paragraph 1:
> > > # In this International Standard, ``shall'' is to be interpreted as a
> > > # requirement on an implementation or on a program; conversely,
> > > # ``shall not'' is to be interpreted as a prohibition.
> > >
> > > Nothing else imposes a requirement,
> >
> > I don't see that in the above quotation.
>
> The standard explicity says right there what makes a requirement.  It
> doesn't say that anything else imposes a requirement.  Why do you
> think that some requirements are made explicit, while others are left
> for you to figure out?  Why do you believe that the behavior for
> control characters is required, when there's no "shall", and it's
> explicitly expressed as only intent?
>

The words you quoted tell you that when the phrases "shall" and "shall
not" mean. They do not tell you what any other phrase 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              ]

Paul Jarc wrote:
>
> Pete Becker <petebecker@acm.org> writes:
> > Paul Jarc wrote:
> > > Pete Becker <petebecker@acm.org> writes:
> > > > Sure: it's required unless it can't be done reasonably.
> > >
> > > Absolutely nowhere does the standard make requirements of that nature.
> > > All requirements are absolute, ignoring the hosted/freestanding issue.
> > > A requirement with a condition like yours is no requirement at all; an
> > > implementor can say "that's not feasible here" for any such
> > > requirement.  Conformance is discrete.  Feasibility is fuzzy.
> > > Conformance can't depend on feasibility.
> > >
> >
> > And where did you get this definition of conformance?
>
> >From clause 4, where it talks about what signifies a requirement.
> Note that there is no mention of feasibility.  Where did you get your
> definition, which requires the implementor to evaluate the feasibility
> of implementing a language feature?

It's the most reasonable interpretation I can think of for the words in
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              ]

Christopher Eltschka <celtschk@physik.tu-muenchen.de> writes:
> You mean as useless as creating the file "foo", since there's
> no guarantee by the standard that there's really a file "foo"
> generated on disk? (The implementation could simply associate
> some program memory area with the name "foo" and do all
> operations there, which effectively causes the "file" to
> be private to the program and to disappear when the program does).

The storage medium is unimportant, but C9X 7.19.3p5 says:
# The file may be subsequently reopened, by the same or another
# program execution, and its contents reclaimed or modified (if it can
# be repositioned at its start).


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 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.
>
> $ egrep 'control +character' n2794.txt | wc -l
>       7

Which brings up a related issue: iscntrl('\t') is not defined anywhere
(for '\t' and any other "control character" escape sequence).

Hence Unix can define isprint('\t') != 0, and Microsoft can define
isprint('\t') == 0, and both can be considered conforming.
In other words, "control character" is not defined in terms of
"iscntrl()", and visa versa.

See <http://www.flash.net/~dtribble/text/c9xc006.txt>.

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

>If it's in the standard as simply a name for a particular character it's
>not undefined. It's merely useless. Under those circumstances you cannot
>write code that uses \e without knowing what your particular
>implementation will do with it. From a practical perspective that's no
>better than having undefined behavior.

I disagree.  Having \e in the standard would give you a stick with which
to beat uncooperative vendors.  Undefined behaviour, on the other hand,
(as is the current status quo) gives the vendor a stick with which to
beat the hapless programmer that should try to make use of such a construct.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, 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:
>> > 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?
>>
>> Clause 4, paragraph 1:
>> # In this International Standard, ``shall'' is to be interpreted as a
>> # requirement on an implementation or on a program; conversely,
>> # ``shall not'' is to be interpreted as a prohibition.
>>
>> Nothing else imposes a requirement,
>
>I don't see that in the above quotation.

I believe ISO has a meta-standard about the language used in standards,
which I think states that all requirements for conformance should be stated
using ``shall''.  Unfortunately I can't give a more precise reference.

But in any case, if something is specifically stated to be "intent",
then it is not a requirement.  That much follows from the ordinary
meanings of "intent" and "requirement" in this context.

--
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3        |     -- the last words of T. S. Garp.


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

Fergus Henderson wrote:
>
> Pete Becker <petebecker@acm.org> writes:
>
> >Paul Jarc wrote:
> >>
> >> Pete Becker <petebecker@acm.org> writes:
> >> > 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?
> >>
> >> Clause 4, paragraph 1:
> >> # In this International Standard, ``shall'' is to be interpreted as a
> >> # requirement on an implementation or on a program; conversely,
> >> # ``shall not'' is to be interpreted as a prohibition.
> >>
> >> Nothing else imposes a requirement,
> >
> >I don't see that in the above quotation.
>
> I believe ISO has a meta-standard about the language used in standards,
> which I think states that all requirements for conformance should be stated
> using ``shall''.  Unfortunately I can't give a more precise reference.

Yes, but that's a rule of writing style, not a rule of interpretation.

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

Fergus Henderson wrote:
>
> Pete Becker <petebecker@acm.org> writes:
>
> >If it's in the standard as simply a name for a particular character it's
> >not undefined. It's merely useless. Under those circumstances you cannot
> >write code that uses \e without knowing what your particular
> >implementation will do with it. From a practical perspective that's no
> >better than having undefined behavior.
>
> I disagree.  Having \e in the standard would give you a stick with which
> to beat uncooperative vendors.  Undefined behaviour, on the other hand,
> (as is the current status quo) gives the vendor a stick with which to
> beat the hapless programmer that should try to make use of such a construct.
>

It's a rather short stick if it all it says is that it's
implementation-defined. It's even shorter, because no compiler vendor
will specify in detail what effect \e has -- it depends on what device
drivers you have loaded and what device you send it to, both of which
are beyond the control of the vendor. So in order to use \e meaningfully
you must know details about the hardware and OS that the application is
running on.

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

scjones@thor.sdrc.com (Larry Jones) writes:
> 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.

Hm.  All right, then - I don't know it's done in the source.  This
doesn't strike me as a particularly good idea, though - my approach
would be to put raw escape sequences in the database, so that the code
doesn't need to know how to do any translation.  Does knowledge of the
terminal type ever fail to imply knowledge of the character set?


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:
> In any event, when you start reasoning about such subtle
> implications of words you're usually in trouble.

And when you just accept a simplistic interpretation without
considering such subtle implications you're in more trouble.

> The fact is that ANSI says that text in examples and footnotes
> is not normative, and that everything else is.

So now all you need to do is show that all normative text necessarily
imposes requirements.

> So the problem is not figuring out how to ignore those words, but
> how to give them meaning in the context of the rest of the standard.

I'm not trying to figure out how to ignore those words; I know exactly
how to ignore them, and I know why I'm allowed to do it.


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:
> Paul Jarc wrote:
> > Pete Becker <petebecker@acm.org> writes:
> > > 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?
> >
> > Clause 4, paragraph 1:
> > # In this International Standard, ``shall'' is to be interpreted as a
> > # requirement on an implementation or on a program; conversely,
> > # ``shall not'' is to be interpreted as a prohibition.
> >
> > Nothing else imposes a requirement,
>
> I don't see that in the above quotation.

The standard explicity says right there what makes a requirement.  It
doesn't say that anything else imposes a requirement.  Why do you
think that some requirements are made explicit, while others are left
for you to figure out?  Why do you believe that the behavior for
control characters is required, when there's no "shall", and it's
explicitly expressed as only intent?


paul


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

"Greg Brewer" <nospam.greg@brewer.net> writes:
> 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.

That's your own personal motivation.  Of course, others have other
reasons for wanting \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              ]

Pete Becker <petebecker@acm.org> writes:
> Sure: it's required unless it can't be done reasonably.

Absolutely nowhere does the standard make requirements of that nature.
All requirements are absolute, ignoring the hosted/freestanding issue.
A requirement with a condition like yours is no requirement at all; an
implementor can say "that's not feasible here" for any such
requirement.  Conformance is discrete.  Feasibility is fuzzy.
Conformance can't depend on feasibility.


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 wrote:
>
> Pete Becker <petebecker@acm.org> writes:
> > Paul Jarc wrote:
> > > 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.
>
> Yes; I was sloppy.  I meant: how do you maintain that that text
> imposes requirements?
>

Because that's what a standard does -- its normative text gives the
meaning of the constructs in a  valid program. At a more practical
level, if writing a string that contains \n doesn't move the output
position to the beginning of the next line, the vendor better have a
good explanation for why it's unreasonable to implement for that
particular platform.

--
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:
> > (You can't legally send the contents of a binary stream to the
> > screen).
>
> You can't know that the contents of a binary stream *aren't* directed
> at a display device.  And nothing in the standard restricts you to
> using text streams with display devices.
>

Of course you can. Not in portable C, but that's why it goes into the
library, where the non-portabilities are taken care of. The function
that does this is usually named 'isatty'.

--
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:m3g1049cky.fsf_-_@multivac.student.cwru.edu...
> Modern
> compilers for DOS/Windows will (I expect) still perform the
> translation on output, and perhaps perform it only if needed on input.

The point was that you would not be able to tell from observation that the
output was done in binary mode on recent versions of the OS and you could
tell on earlier versions.

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:
> Paul Jarc <prj@po.cwru.edu> wrote in message
> news:m34sglqrcb.fsf@multivac.student.cwru.edu...
> > 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.

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.


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:
> Christopher Eltschka wrote:
> > // 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?

Nothing in Christopher's post suggested ASCII, and he stated that the
behavior would not be undefined.  The behavior for \033 is undefined.
There's your difference.  (I'll leave it to Christopher to defend the
claim that \e would not give undefined behavior.)


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

Hyman Rosen wrote:
> And they would be just as unhappy if \b was written as \x33[D, ...

Yes, because ESC [ D doesn't mean "backspace" on every device to
which the output might be sent, just those supporting some variant
of X3.64.  However, BS means backspace practically everywhere,
because the ASCII standard (and compatible extensions) has been
adopted nearly everywhere, even on X3.64 devices.  Whether or not
ASCII BS is correctly implemented on some device is a separate
issue from whether or not everyone would agree about its intended
approximate 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              ]

"Greg Brewer" <nospam.greg@brewer.net> writes:
> Paul Jarc <prj@po.cwru.edu> wrote in message
> news:m3n1ueiwdn.fsf@multivac.student.cwru.edu...
> > 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.

(Text printed to standard output goes directly to standard output.
Whether it gets rerouted on its way to a display device is another
matter.)

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

Then, in the second case, foo's runtime library isn't responsible for
producing the display effects, and if more isn't a C program, it isn't
either, since it's outside the scope of the standard.


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

Clause 4, paragraph 1:
# In this International Standard, ``shall'' is to be interpreted as a
# requirement on an implementation or on a program; conversely,
# ``shall not'' is to be interpreted as a prohibition.

Nothing else imposes a requirement, and there is no "shall" in the
text we're discussing.


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 wrote:
>
> Pete Becker <petebecker@acm.org> writes:
> > Paul Jarc wrote:
> > > Yes, they know how to say it - and they did.  4p2:
> > > # Undefined behavior is otherwise indicated in this International
> > > # Standard by the words ``undefined behavior'' or by the omission of
> > > # any explicit definition of behavior.
> > >
> > > There's no binding definition of behavior for the \ characters, hence
> > > it's undefined.
> >
> > No, the standard says "explicit definition of behavior", not "binding
> > definition," so even at the level of labels your analysis doesn't apply.
>
> Consider "binding definition" (as I used it) to be a synonym for
> "definition".  I say that the behavior of the \ control characters is
> not given by a definition at all, because it is not a requirement.
> (No "shall"==no requirement.)  How can it be a definition, if it
> imposes no requirements, and hence is compatible with absolutely any
> interpretation?
>

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

Sure looks like an explicit definition of behavior to me. The fact that
it's qualified doesn't change that. In any event, when you start
reasoning about such subtle implications of words you're usually in
trouble. The fact is that ANSI says that text in examples and footnotes
is not normative, and that everything else is. So the problem is not
figuring out how to ignore those words, but how to give them meaning in
the context of the rest 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              ]

Pete Becker <petebecker@acm.org> writes:
> 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.

The standard doesn't make any distinction between text and binary mode
streams with regard to display devices.  (I agree that binary mode
doesn't have to deal with display actions, but only because all
display actions are specified only as intent.)


paul


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

Paul Jarc wrote:
>
> Pete Becker <petebecker@acm.org> writes:
> > Sure: it's required unless it can't be done reasonably.
>
> Absolutely nowhere does the standard make requirements of that nature.
> All requirements are absolute, ignoring the hosted/freestanding issue.
> A requirement with a condition like yours is no requirement at all; an
> implementor can say "that's not feasible here" for any such
> requirement.  Conformance is discrete.  Feasibility is fuzzy.
> Conformance can't depend on feasibility.
>

And where did you get this definition of conformance? The issue is how
to give meaning to the words in a document. Documents are written by
humans, and are sometimes less than perfect. If the meaning is less than
clear it is necessary to infer meanings in reasonable ways. A standards
document is not a computer program. You cannot insist on complete
determinism from a document. It usually cannot be done.

--
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:
> > > 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?
>
> Clause 4, paragraph 1:
> # In this International Standard, ``shall'' is to be interpreted as a
> # requirement on an implementation or on a program; conversely,
> # ``shall not'' is to be interpreted as a prohibition.
>
> Nothing else imposes a requirement,

I don't see that in the above quotation.

--
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:
> > Christopher Eltschka wrote:
> > > // 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?
>
> Nothing in Christopher's post suggested ASCII, and he stated that the
> behavior would not be undefined.  The behavior for \033 is undefined.
> There's your difference.  (I'll leave it to Christopher to defend the
> claim that \e would not give undefined behavior.)
>

If it's in the standard as simply a name for a particular character it's
not undefined. It's merely useless. Under those circumstances you cannot
write code that uses \e without knowing what your particular
implementation will do with it. From a practical perspective that's no
better than having undefined 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              ]

Paul Jarc wrote in message ...
>
>Talking about "the run-time behavior of \a" is convenient shorthand.
>There may have been some confusion about compile-time vs. run-time,
>but I don't think this is the cause.

The standard itself says: "Alphabetic escape sequences representing
nongraphic characters in the execution character set are intended to produce
actions on display devices as follows:"

To paraphrase: "Alphabetic escape sequences are intended to produce actions
on display devices." That sounds like it's taking about run-time behavior...

>> ESC is well-defined (but with different values) in all the major
>> execution character sets, and thus a prime candidate for providing as
>> a language feature.
>
>True, AFAIK.  \e is on (nearly) the same footing as \n et al.

Whew. Someone agrees with me on something at least.

>The only purpose for having \ sequences for them is so the programmer
>has a way to get the required or intended behavior.

I really dislike talking about "required or intended behavior". Why? Because
behavior occurs when a particular character code is interpreted by a
particular recipient. There are lots of recipients: modems, printers, glass
TTY's, buffers that are being displayed by a word processor as proprietary
commands, buffers that are being displayed by a word processor as JIS,
buffers that are being displayed by a word processor as Shift JIS. printf()
and friends are just one of many.

What I'd like from my language is a way of portably and reliably expressing
the codes I need to appear in my data. If the runtime would like to be
helpful, that's nice too. But the requirements on that subset of the runtime
library that handles printing do not belong in the definition of the syntax
for character and string literals.

>  To justify adding
>escapes for characters that aren't meant for sending to display
>devices, you'd have to either show that the control characters are
>widely used across multiple character sets,

ESC, SI, and SO appear in ASCII, EBCDIC, and Unicode. Done.

> or say what behavior these
>characters (are intended to) cause for other kinds of output streams.

The behavior of these codes are well-defined in various contexts (ISO-2022,
various hardware devices), so that's done 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              ]

Paul Jarc wrote:
>
> Yes, they know how to say it - and they did.  4p2:
> # Undefined behavior is otherwise indicated in this International
> # Standard by the words ``undefined behavior'' or by the omission of
> # any explicit definition of behavior.
>
> There's no binding definition of behavior for the \ characters, hence
> it's undefined.
>

No, the standard says "explicit definition of behavior", not "binding
definition," so even at the level of labels your analysis doesn't apply.

--
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" <nospam.greg@brewer.net> writes:
> 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.

But *something* (sometimes stdio, often not) is encouraged to display
the \ characters in a particular way.  That something can be
considered part of the "implementation", which is what the standard
talks about, even though it may come from a different vendor than your
compiler and linker.  The buck stops somewhere, and that point is what
this discussion is about.

Pete's problem with your suggestion is that you haven't suggested any
(required or intended) behavior for \e at all, on a display device or
otherwise.  At best, you've deferred to some other standard, which is
sometimes done, but should be avoided when possible.

Saying "\x1B for ASCII, \x27 for EBCDIC, etc." doesn't cut it: the
standard doesn't define anything else in this manner, AFAIK, and I
don't think it should.  "The execution character set's escape
character, if there is one, or a unique control character otherwise,
causing (unspecified|implementation-defined) behavior when written to
a display device" is better, but still isn't enough for Pete.  You'll
have to do better if you care about winning him over.


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:
> Paul Jarc wrote:
> > Yes, they know how to say it - and they did.  4p2:
> > # Undefined behavior is otherwise indicated in this International
> > # Standard by the words ``undefined behavior'' or by the omission of
> > # any explicit definition of behavior.
> >
> > There's no binding definition of behavior for the \ characters, hence
> > it's undefined.
>
> No, the standard says "explicit definition of behavior", not "binding
> definition," so even at the level of labels your analysis doesn't apply.

Consider "binding definition" (as I used it) to be a synonym for
"definition".  I say that the behavior of the \ control characters is
not given by a definition at all, because it is not a requirement.
(No "shall"==no requirement.)  How can it be a definition, if it
imposes no requirements, and hence is compatible with absolutely any
interpretation?


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

Both methods are viable.  For DOS/Windows, the translation is
typically done for all text files (external representation is allowed
to be different), and happens to be the translation that produces the
desired effect on console.  For Unices, it's done by the terminal
driver, which knows that it is on a (not necessarily physical) display
device.

> One complicating factor in this is a change in Win/Dos.  Recent versions no
> longer require the translation.

Newer Microsoft programs (WordPad, etc.)  will recognize a lone \n as
a line ending in text files, yes.  That's somewhat unrelated to
whether the translation happens on output in *your* programs.  Modern
compilers for DOS/Windows will (I expect) still perform the
translation on output, and perhaps perform it only if needed on input.


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

Talking about "the run-time behavior of \a" is convenient shorthand.
There may have been some confusion about compile-time vs. run-time,
but I don't think this is the cause.

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

No, more *could* be said, but that would place additional limits on
what kind of systems C could be implemented on.  As it happens,
though, even less is said (or rather, required).

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

True, AFAIK.  \e is on (nearly) the same footing as \n et al.

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

The only purpose for having \ sequences for them is so the programmer
has a way to get the required or intended behavior.  To justify adding
escapes for characters that aren't meant for sending to display
devices, you'd have to either show that the control characters are
widely used across multiple character sets, or say what behavior these
characters (are intended to) cause for other kinds of output streams.


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              ]

comeau@panix.com (Greg Comeau) writes:
> In article <t7d7v9369d.fsf@calumny.jyacc.com> Hyman Rosen <hymie@prolifics.com> writes:
> >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."

That doesn't conflict with Hyman's statement.

> It's not talking about 10 here, but of all the escape sequences.

Actually, it's talking about all 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.
>
> All of this is for files in text mode.

No, the section about the effects of \ characters on display devices
makes no mention of text vs. binary mode, so it applies to both.


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:
> (You can't legally send the contents of a binary stream to the
> screen).

You can't know that the contents of a binary stream *aren't* directed
at a display device.  And nothing in the standard restricts you to
using text streams with display devices.


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:
> Nick Maclaren wrote:
> > 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.

Yes, but it does not follow that these words impose requirements.

> If they meant them merely as advice they would have put them in the
> rationale, or perhaps in a footnote or a comment.

Oh?  Have you asked the standard writers?  If not, how do you know
this?  It is the way most informative text is included, but that
doesn't imply that all other text imposes requirements.

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

Yes, they know how to say it - and they did.  4p2:
# Undefined behavior is otherwise indicated in this International
# Standard by the words ``undefined behavior'' or by the omission of
# any explicit definition of behavior.

There's no binding definition of behavior for the \ characters, hence
it's undefined.


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:
> Paul Jarc wrote:
> > 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.

Yes; I was sloppy.  I meant: how do you maintain that that text
imposes requirements?


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              ]