Pete Becker <petebecker@acm.org> wrote

> "Paul D. DeRocco" wrote:
> >
> > And, ironically, you would probably never use the \e character anyway.
> > Since you have repeatedly indicated that you only care about writing
> > utterly portable code
>
> The discussion isn't about what sort of code I may or may not write, but
> about what the standard should require. Please don't confuse the issue
> with ad hominem arguments.

What I mean to say is that your posts make it seem that you think the
standard should only serve the needs of people writing utterly portable
code, and that those of us who do not envisage porting our software to every
obscure platform are engaged in some lesser activity that the standard
shouldn't concern itself with.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, 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:
> What a marvelous piece of indirection. A very narrow allowance of
> unspecified behavior (\b at the beginning of a line) turns into
> "opportunities for unspecified behavior," which then turns into a
> license for never having to say what a character sequence that includes
> \e does. There is a significant and important difference between
> "occasionally produces unspecified behavior" and "always produces
> unspecified behavior."

Could you please explain what that significant and important
difference is?  The goal is to get \e in the C standard, so that
people who want it can use it. Those people want it to represent their
local escape character, and to be written unchanged to the output
stream. Some people insist that if \e is to be added to the C
standard, it must be described in a way consistent with the other
alphabetic escape sequences. The unspecified/unspecified description I
came up with matches that style pretty well. It would even allow
implementations to incorporate ANSI.SYS-style handling, for example,
on embedded devices with memory-mapped displays.

I can not even do a single putchar('\t') without invoking potentially
unspecified behavior, so I don't see how the elaborate description in
the C standard helps me at all.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Pete Becker <petebecker@acm.org> writes:
> No, my position is that I want to see a description with the same degree
> of specificity as in the descriptions of the alphabetic escape sequences
> in the C standard. I happen to think that that cannot be done, and so
> far that has been corroborated by the various attempts at doing it.

\e (escape) This and an unspecified number of following characters
   produce an unspecified effect on the display, regardless of the
   other requirements of this section. The effect on the active
   position is unspecified.

This is in keeping with other paragraphs in this section, which also
give opportunities for unspecified behavior.

What we *want*, on ASCII and EBCDIC platforms, is for \e to represent
ESC in the local character set, and for it to be written unchanged to
the output stream. It is trivial to specify this in the C++ standard,
so it seems that the C standard's attempt to describe display semantics
is impeding the adoption of a useful feature. This is certainly an
example of the standard getting in the way of what people want to do.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, 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:37EFB535.AB352AF9@acm.org...
>
> What people want is to be able to write code for the environment that
> they are targeting, and the C and C++ standards try not to get in the
> way when compiler implementors do this. Restricting the allowable
> character set to ASCII or EBCDIC would be a major departure from this
> policy.

First, I don't see how you can reasonably call restricting the character set
to ASCII or EBCDIC a "major" anything, without pointing out another
real-world character set that this would exclude.

Second, I'm not suggesting restricting the character set to ASCII or EBCDIC;
I'm suggesting restricting it to character sets that have escape characters.
And since I've yet to hear of any other character sets period, I've
therefore yet to hear of any other character sets without escape characters.

Third, even if you could come up with some obscure character set, whose
control character encoding is fundamentally different from ASCII and EBCDIC,
and that has no escape character, to have a valid argument you'd have to
demonstrate 1) that that character set had all the other characters for
where there are backslash escapes (otherwise it could deal with \e in the
same manner as it dealt with the other missing control characters that have
backslash constructs in the standard), and 2) you'd have to show that the
system that used this character set wasn't some dinosaur 1950's mainframe,
some toy 1970's single-board computer, or some crappy 16-bit DSP, but was
actually a system for which someone in the future might attempt a
standard-conforming compiler for.

In other words, you have to dig really hard to prove that adding \e to the
standard would _actually_ ever cause anyone a problem. On the other hand, \e
has an obvious benefit to a significant number of people.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, 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:37F29861.317A8599@acm.org...

> No, my position is that I want to see a description with the same degree
> of specificity as in the descriptions of the alphabetic escape sequences
> in the C standard. I happen to think that that cannot be done, and so
> far that has been corroborated by the various attempts at doing it.

And, ironically, you would probably never use the \e character anyway. Since
you have repeatedly indicated that you only care about writing utterly
portable code, I doubt you ever actually write _any_ control characters
other than \n--or you're not really writing portable code.

As I've stated elsewhere, the problem isn't that it's not possible to
specify the meaning of \e as well as the other control characters. The
problem is that other control characters (besides \n) are overspecified
anyway, in the C standard. All that people really expect the language to
guarantee about writing other control characters is that they be delivered
verbatim to whatever is being written to. It should be up to that something
else to guarantee the interpretation, not the language standard, and
therefore it should be up to the programmer to know what that something else
guarantees.




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, 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:
> > No, my position is that I want to see a description with the same degree
> > of specificity as in the descriptions of the alphabetic escape sequences
> > in the C standard. I happen to think that that cannot be done, and so
> > far that has been corroborated by the various attempts at doing it.
>
> \e (escape) This and an unspecified number of following characters
>    produce an unspecified effect on the display, regardless of the
>    other requirements of this section. The effect on the active
>    position is unspecified.
>
> This is in keeping with other paragraphs in this section, which also
> give opportunities for unspecified behavior.

What a marvelous piece of indirection. A very narrow allowance of
unspecified behavior (\b at the beginning of a line) turns into
"opportunities for unspecified behavior," which then turns into a
license for never having to say what a character sequence that includes
\e does. There is a significant and important difference between
"occasionally produces unspecified behavior" and "always produces
unspecified 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 D. DeRocco" wrote:
>
> Pete Becker <petebecker@acm.org> wrote in message
> news:37F29861.317A8599@acm.org...
>
> > No, my position is that I want to see a description with the same degree
> > of specificity as in the descriptions of the alphabetic escape sequences
> > in the C standard. I happen to think that that cannot be done, and so
> > far that has been corroborated by the various attempts at doing it.
>
> And, ironically, you would probably never use the \e character anyway. Since
> you have repeatedly indicated that you only care about writing utterly
> portable code

The discussion isn't about what sort of code I may or may not write, but
about what the standard should require. Please don't confuse the issue
with ad hominem arguments.

--
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:
> > What people want is to be able to write code for the environment that
> > they are targeting, and the C and C++ standards try not to get in the
> > way when compiler implementors do this.
>
> Exactly. That's what the whole \e debate is about. Your position is
> that people who want \e should be denied its benefit because it's
> difficult to write an explanation for it to your satisfaction, in
> the style of the C standard.

No, my position is that I want to see a description with the same degree
of specificity as in the descriptions of the alphabetic escape sequences
in the C standard. I happen to think that that cannot be done, and so
far that has been corroborated by the various attempts at doing it.

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

"Paul D. DeRocco" <pderocco@ix.netcom.com> writes:
> Paul Jarc wrote:
> > That's not a definition unless you also have a reference to another
> > document describing what those control characters do.
>
> Oh, I don't know. The C and C++ standards don't reference any English
> language dictionaries, even though they are written in English. No
> definitional document is closed; they all presume some agreement on the
> meanings of things outside themselves.

Yes, but currently, the standard doesn't presume agreement for what
TAB, etc., mean.  Instead, it specifies what \t, etc., ought to mean.
If the intended meaning is the same, why not make it explicit?  It has
the advantage of not being complicated by any lack of agreement that
might arise regarding TAB, etc.

> > filters need some logical division of lines/records/whatever, but
> > they usually don't need to know how that delimiter is displayed.
> > All they need is a convention for how to delimit lines, and that
> > is already established.
>
> Whatever. We agree, though, that \n, unlike the remaining control
> characters, has a logical meaning that is necessary in text files.

More or less.  Filters need *some* way to represent that logical
meaning.  \n is not strictly necessary.  Its meaning could be encoded
in graphic characters (just as it is in character/string literals);
it's just a matter of convenience.

> > Requiring a character with a particular name is ineffectual,
> > unless you specify the character set, which is too restrictive.
>
> Why? As long as you're only requiring characters that are known to be in
> all relevant character sets, that's all you need to do.

Yes, but which character sets are relevant?  I can't say, because I
don't know all the different kinds of systems C has been implemented
on.  Those implementations are important to their users, even if you
don't know about them.


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:
> What people want is to be able to write code for the environment that
> they are targeting, and the C and C++ standards try not to get in the
> way when compiler implementors do this.

Exactly. That's what the whole \e debate is about. Your position is
that people who want \e should be denied its benefit because it's
difficult to write an explanation for it to your satisfaction, in
the style of the C standard.

> Restricting the allowable
> character set to ASCII or EBCDIC would be a major departure from this
> policy.

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

"Paul D. DeRocco" wrote:
>
> I don't think anyone
> minds the fact that C and C++ compilers always seem to target well-known
> execution character sets like ASCII (and derivatives) and EBCDIC.

C and C++ compilers target the character system used on their target
platform, whether that character set is ASCII, EBCDIC, JIS, or anything
else.

> That's
> what people actually want, and that's all the standard needs to be able to
> handle.

What people want is to be able to write code for the environment that
they are targeting, and the C and C++ standards try not to get in the
way when compiler implementors do this. Restricting the allowable
character set to ASCII or EBCDIC would be a major departure from this
policy.

--
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:
>
> That's not a definition unless you also have a reference to another
> document describing what those control characters do.

Oh, I don't know. The C and C++ standards don't reference any English
language dictionaries, even though they are written in English. No
definitional document is closed; they all presume some agreement on the
meanings of things outside themselves.

> (Also, someone said that EBCDIC does have a newline character, but C
> implementations often use LF even on EBCDIC.  I myself don't know.)

Yes, EBCDIC does have a newline character. I don't know what current
practice is, but the standard should reflect current practice, as long as
it is consistent.

> Otherwise, it's just providing synonyms for these entities, without
> saying what they can actually be used for.

See my first point, above.

> The only difference between this and the current situation is that
> display action produced by the newline character would be required
> rather than intended.  This is unnecessary for text filters; filters
> need some logical division of lines/records/whatever, but they usually
> don't need to know how that delimiter is displayed.  All they need is
> a convention for how to delimit lines, and that is already
> established.

Whatever. We agree, though, that \n, unlike the remaining control
characters, has a logical meaning that is necessary in text files.

> Implementations are free to choose their character set, so they can
> say "character N is my line feed character", regardless of what the
> convention is in the host environment.  Requiring a character with a
> particular name is ineffectual, unless you specify the character set,
> which is too restrictive.

Why? As long as you're only requiring characters that are known to be in
all relevant character sets, that's all you need to do.

It's pointless to try to invent a standard, or even a small portion of a
standard, that achieves Platonic perfection, in that it can be
implementable on any conceivable abstract machine. C and C++ are already
limited, say, to binary machines, and nobody minds. I don't think anyone
minds the fact that C and C++ compilers always seem to target well-known
execution character sets like ASCII (and derivatives) and EBCDIC. That's
what people actually want, and that's all the standard needs to be able to
handle.

--

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

In article <37EF0559.5F8994B6@ix.netcom.com>,
Paul D. DeRocco <pderocco@ix.netcom.com> wrote:
>Paul Jarc wrote:
>
>> (Also, someone said that EBCDIC does have a newline character, but C
>> implementations often use LF even on EBCDIC.  I myself don't know.)
>
>Yes, EBCDIC does have a newline character. I don't know what current
>practice is, but the standard should reflect current practice, as long as
>it is consistent.

It is a long time since I evaluated the relevant compilers, but some
used X'15' (NL) and some X'25' (LF).


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


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

"Paul D. DeRocco" <pderocco@ix.netcom.com> writes:
> The C++ Standard no longer says very much, since the association
> with particular ASCII character symbols was removed between CD2 and
> the actual standard.

The actual C++ Standard, in 2.13.2/3, Table 5, says

 new-line (NL)LF \n
 horizontal tab HT \t
 vertical tab VT \v
 backspace BS \b
 carriage return CR \r
 form feed FF \f
 alert  BEL \a

and should say

 escape  ESC \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              ]

"Paul D. DeRocco" wrote:
> ... There is no "newline" character in either ASCII or EBCDIC.

(1) Newline is not necessarily mapped onto a character (LF or CR),
nor even a particular set of characters (CR,LF).  It is interpreted
as required by the run-time support library (on which stdio is based).

(2) "Newline" is too a character in some ASCII environments;
code 10 (decimal) was allowed to be interpreted either as LF or
as NL.  Around the time of the Teletype model 37, I recall some
terminals could interpret ASCII code 10 either way, depending on
how they were set up, and others would interpret code 13 as either
CR or NL, although I don't think that was allowed by the ASCII spec.
(I have the spec in my archives, but it would take too long to find
it.)


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

"Paul D. DeRocco" <pderocco@ix.netcom.com> writes:
> The C and C++ standards _should_ (in my view) do three things. First, they
> should define all the various backslashed characters according to the names
> customarily given to their equivalent control characters, i.e., alert for
> \a, backspace for \b, form feed for \f, line feed for \n, carriage return
> for \r, horizontal tab for \t, and vertical tab for \v. Note that I wrote
> "line feed" and not "newline". There is no "newline" character in either
> ASCII or EBCDIC.

That's not a definition unless you also have a reference to another
document describing what those control characters do.  (Also, someone
said that EBCDIC does have a newline character, but C implementations
often use LF even on EBCDIC.  I myself don't know.)  Otherwise, it's
just providing synonyms for these entities, without saying what they
can actually be used for.

> Second, because basic communication among text-based programs, such as Unix
> text-mode filters, _requires_ exactly one control function, the ability to
> move to the start of a new line, the standards _should_ define the
> "newline" function, and specify that it be represented by the line feed
> character. It should further explain that if there is a discrepancy between
> this logical meaning and the physical meaning of line feed in the
> surrounding environment, the library must hide this difference.

The only difference between this and the current situation is that
display action produced by the newline character would be required
rather than intended.  This is unnecessary for text filters; filters
need some logical division of lines/records/whatever, but they usually
don't need to know how that delimiter is displayed.  All they need is
a convention for how to delimit lines, and that is already
established.

> The standards, then, would be most useful, and best adhere to common
> practice, if they did the above two things,

(You said three things before, but I only counted two.  No one
inspects the Spanish Exposition, eh? :) )

> defining the backslash characters in terms of the names control
> characters found in existing character sets, and defining the
> meaning of the newline function and it representation by the line
> feed character.

Implementations are free to choose their character set, so they can
say "character N is my line feed character", regardless of what the
convention is in the host environment.  Requiring a character with a
particular name is ineffectual, unless you specify the character set,
which is too restrictive.


paul


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

Pete Becker wrote:
>
> Where in the standard does it say that \n is a special case?

Nowhere. _I_ said it's a special case, and then explained why it is.

You've made a lot of hay about what the C standard says. (The C++ Standard
no longer says very much, since the association with particular ASCII
character symbols was removed between CD2 and the actual standard.) But
we're talking here about changing the standards, so its current wording is
only important to the extent that we shouldn't make changes that break
existing code. I would like to suggest that the C standard (which others
have quoted--I don't have a copy) says more than it needs to, and in fact
says more than can possibly be enforced, since there's no guarantee that
the device to which control characters are sent will be able to respond to
them in the manner described. But there is a solution.

The C and C++ standards _should_ (in my view) do three things. First, they
should define all the various backslashed characters according to the names
customarily given to their equivalent control characters, i.e., alert for
\a, backspace for \b, form feed for \f, line feed for \n, carriage return
for \r, horizontal tab for \t, and vertical tab for \v. Note that I wrote
"line feed" and not "newline". There is no "newline" character in either
ASCII or EBCDIC.

Second, because basic communication among text-based programs, such as Unix
text-mode filters, _requires_ exactly one control function, the ability to
move to the start of a new line, the standards _should_ define the
"newline" function, and specify that it be represented by the line feed
character. It should further explain that if there is a discrepancy between
this logical meaning and the physical meaning of line feed in the
surrounding environment, the library must hide this difference.

Since no other control functions are _required_ for basic text-mode
communication (since text files are customarily viewed as two-dimensional
arrangements of characters), the logical meanings of the other characters
should be left unspecified by the standard, and the runtime library should
not do any translation on any of them (although the OS or a device driver
certainly may).

This distinction between newline and the other control functions is
essential. Newline is a logical meaning, and we need some sort of single
character to represent it, and for historical reasons that character
happens to be line feed. This was a good choice, because the common
physical meaning of line feed, moving to the next line without moving to
column one, isn't particularly useful anyway. The remaining control
characters have less well-defined logical meanings (e.g., tabs require the
specification of tab stops), and are generally used for physical control of
specific devices. They are not required for basic text-mode communication.
Therefore, they are fundamentally different from the newline function.

The standards, then, would be most useful, and best adhere to common
practice, if they did the above two things, defining the backslash
characters in terms of the names control characters found in existing
character sets, and defining the meaning of the newline function and it
representation by the line feed character.

The only possible exception to this might be form feed. It could be argued
that it would be useful to have a logical "newpage" function, to give text
files a third dimension. In this case, the "newpage" function would be
represented by the form feed character, and the standard could require
that, like newline, it should imply a move to column one. But this is mere
musing; current practice treats basic text files as two-dimensional, not
three-dimensional.

If this all makes sense, then it is perfectly reasonable to add the
"escape" character to the set of physical control characters that should
have special portable representations in C or C++. Like all the other
control characters except line feed, it would be defined merely by its
commonly understood name, which has a well-known meaning in the context of
the popular character sets, and not by its logical meaning.

--

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


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