Why's of C++ -- Part 3 (string discussion)
Greg Brewer
the power of the standard C library. It occurred to me that a lot of these
functions were useful in writting the C compiler. I found the idea of
writting a C compiler in C somewhat amusing. Over the years, I have gotten
a lot of use out of functions suchs as stpcpy, strcspn, etc.
A few years ago, I had to modify a DOS application to allow the user to
enter a printer initialization/deinitialization string and save that as a
default. I was surprised by two shortcomings: that the string functions
does not a function to translate strings from their code representation (eg
"abc\t\a\n") to their internal representation and that there is no line code
sequence for representing the escape character (ie '\e'). I know there is a
hex, octal, etc sequence for that represents escape; the same is true for
tab, bell, and the rest.
Once upon a time, escape was so common for controlling printers and remote
terminals that I don't understand why it is not included in the \ character
set. Since the function for translating strings from their "visual" form is
necessary for the compiler to operate, why isn't the function in the
standard C library.
Are escape sequences so passe that this code is unnecessary? Any comments?
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html ]
Francis Glassborow
<nospam...@hal-pc.org> writes
>Once upon a time, escape was so common for controlling printers and remote
>terminals that I don't understand why it is not included in the \ character
>set. Since the function for translating strings from their "visual" form is
>necessary for the compiler to operate, why isn't the function in the
>standard C library.
>
>Are escape sequences so passe that this code is unnecessary? Any comments?
What has any of this to do with C++? In addition I think that the
escape character is a specific code in a particular character set. OTOH
\t, etc. refer to a representation of specific control characters
regardless as to the character set in use.
Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
Barry Margolin
Greg Brewer <nospam...@hal-pc.org> wrote:
>Once upon a time, escape was so common for controlling printers and remote
>terminals that I don't understand why it is not included in the \ character
>set. Since the function for translating strings from their "visual" form is
>necessary for the compiler to operate, why isn't the function in the
>standard C library.
These days such things are almost always done using libraries like curses,
so it's not necessary to hard-code escape sequences into applications.
Therefore, they don't generally need to mention the ESC character
explicitly. Even the library doesn't usually need to refer to it, because
they're generally table-driven; the ESC character will only appear in the
terminal control database files (e.g. termcap or terminfo).
--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Greg Brewer
Francis Glassborow <fra...@robinton.demon.co.uk> wrote in message
news:KrOnmwAF...@robinton.demon.co.uk...
> In article <7p1u5o$ipi$1...@news.hal-pc.org>, Greg Brewer
> What has any of this to do with C++? In addition I think that the
> escape character is a specific code in a particular character set. OTOH
> \t, etc. refer to a representation of specific control characters
> regardless as to the character set in use.
What does it have to do with C++? Well, the programming language I was
using was C++.
I'm trying to remember my IBM days dealing with EBCDIC. If I remember
correctly, that character set has no tab, newline, carriage return, or alarm
character. I could easily be wrong, it has been almost 10 years.
Greg Brewer
Max TenEyck Woodbury
Greg Brewer wrote:
>
> I'm trying to remember my IBM days dealing with EBCDIC. If I remember
> correctly, that character set has no tab, newline, carriage return, or alarm
> character. I could easily be wrong, it has been almost 10 years.
>
This is getting off subject...
EBCDIC has HT, LF, CR and BEL defined. I'm not absolutely positive but I
think FF was also defined. I'd have to dig out an old green card to get
you their values. It's in a box with a bunch of other stuff from the '60s
and '70s so it would be a real tough hunt...
Pete Becker
>
> In addition I think that the
> escape character is a specific code in a particular character set. OTOH
> \t, etc. refer to a representation of specific control characters
> regardless as to the character set in use.
>
Let me put that a bit more strongly. The effect of using \t, etc. is
described in the language definition: \t produces a tab, \a produces
some sort of alert, etc. That is, they have observable consequences, and
those consequences are what the standard describes. What are the
observable consequences of escape?
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
---
David R Tribble
>
> Francis Glassborow wrote:
> >
> > In addition I think that the
> > escape character is a specific code in a particular character set.
> > OTOH \t, etc. refer to a representation of specific control
> > characters regardless as to the character set in use.
>
> Let me put that a bit more strongly. The effect of using \t, etc. is
> described in the language definition: \t produces a tab, \a produces
> some sort of alert, etc. That is, they have observable consequences,
> and those consequences are what the standard describes. What are the
> observable consequences of escape?
Yeah, that was more or less the committee response when I suggested
that we needed an '\e' character sequence years ago. Apparently,
no one has been clever enough to come up with a written description
of the semantics of the control character ESC, even though everyone
damn well knows what it means.
Some of the ISO multibyte character sets are defined in terms of
"shift in" and "shift out" sequences, and VT-100 terminal protocol
(which uses ESC extensively) is something of a de facto standard, so
these could probably serve as a guiding example of how to define the
semantics of ESC on paper. It really isn't that mystical, is it?
And don't get me started on "newline" versus "linefeed"...
-- David R. Tribble, da...@tribble.com --
David R Tribble
>
> Francis Glassborow <fra...@robinton.demon.co.uk> wrote> > What has any of this to do with C++? In addition I think that the
> > escape character is a specific code in a particular character set.
> > OTOH \t, etc. refer to a representation of specific control
> > characters regardless as to the character set in use.
>
> was using was C++.
>
> correctly, that character set has no tab, newline, carriage return,
> or alarm character. I could easily be wrong, it has been almost 10
> years.
You're wrong. Perhaps you're remembering that your 3270 terminal
didn't have keys for those characters, which is partially correct,
but EBCDIC does indeed have them. EBCDIC has all of the control
characters that ASCII has, in fact (and about 30 more, to boot).
Char ASCII EBCDIC
NUL 00 00
BEL 07 2F
BS 08 16
HT 09 05
LF 0A 25
VT 0B 0B
FF 0C 0C
CR 0D 0D
NL - 15
DEL 7F 07
etc.
(Much as I hate EBCDIC, I am forced to admit that it did a slightly
better job by providing an explicit "newline" (NL) character;
C/C++ grabbed "linefeed" (LF) for this purpose, which is logically
only half of the motion of a printer head. Oh, well.)
John Hauser
David R Tribble wrote:
>
> Apparently,
> no one has been clever enough to come up with a written description
> of the semantics of the control character ESC, even though everyone
> damn well knows what it means.
> [...]
> VT-100 terminal protocol
> (which uses ESC extensively) is something of a de facto standard, so
> these could probably serve as a guiding example of how to define the
> semantics of ESC on paper.
For the record, the VT-100 use of ESC was based on official ANSI
standards, now known as ISO 2022 and ISO 6429.
- John Hauser
Antoine Leca
David R Tribble wrote:
>
> Pete Becker wrote:
> >
> > What are the observable consequences of escape?
>
> Yeah, that was more or less the committee response when I suggested
> no one has been clever enough to come up with a written description
> of the semantics of the control character ESC, even though everyone
> damn well knows what it means.
>
> (which uses ESC extensively) is something of a de facto standard, so
> these could probably serve as a guiding example of how to define the
I wonder if the VT-100 terminal protocol do use plain ESC.
My impression was that it does use CSI and other characters that
happen to be defined in the C1 set, thus need to use ESC as a
fall-back mechanism to cooperate with 7-bit medias (the C1 set
is normaly using '\200' to '\237', but can also be obtained by
ESC followed by '\000' to '\037').
Anyway, the real definition of ESC is in ISO 2022 a.k.a. ECMA-35
(available online at <URL:http://www.ecma.ch/stand/ECMA-035.HTM>),
and its main use is to switch character sets when using that standard.
If this is an observable consequence or not is outside my realm.
Antoine
Ken Hagan
>...that the string functions do not include a function to translate
>strings from their code representation (eg "abc\t\a\n") to their
In K&R's original compiler, this was almost certainly done by the
lexer, which was almost certainly generated by lex. Consequently,
they would have had no reason to add such a function to their library.
---
Jerry Leichter
| (Much as I hate EBCDIC, I am forced to admit that it did a slightly
| better job by providing an explicit "newline" (NL) character;
| C/C++ grabbed "linefeed" (LF) for this purpose, which is logically
| only half of the motion of a printer head. Oh, well.)
Getting far away from C++, but ... C (and Unix) had a reasonable basis
in the existing standards for doing this. ASCII(10) always had two
interpretations: As LF (Linefeed) or as NL (New Line). I'm pretty sure
the VT100 allowed you to determine how ASCII(10) would be treated when
received by the terminal; I think the setting was one of those defined
in the ANSI terminal standard, X.34 or something like that.
Why the ambiguity? When ASCII was created, there were two kinds of
"printing" devices in the world: Teletype-like things and line
printers. For Teletype-like things - which included the early video
terminals, then widely describe as "glass TTY's" - LF made sense, was
easy to implement, and could even be useful. Not only that, but it made
the mechanicals simpler if each character only did one thing: LF moved
the platen, CR moved the print element back to the left edge.
For line printers, LF was often too expensive to implement - the line
buffering logic was very simple-minded, of necessity (discrete
transistors and such). New Line meant dump the current buffer and start
filling a new one from the left hand edge. Line printers didn't
implement BACKSPACE either, for the same reason. (Line printers did
generally allow you to control the platen advance separately, so you
could over-print an entire line - software could do things like
underlining or fake bolding by overprinting appropriately in only some
positions - or double space, or skip to the top of a page.) The whole
FORTRAN printing model - with the magic first position - was based on
line printers (and was always a pain to match to terminals).
ASCII tried to cater to both styles of devices with its double meaning
for ASCII(10). In practice, dumb line printers vanished - but their
interpretation of ASCII(10), as chosen for Unix, lives on.
One of the oddities of the evolution of this business....
-- Jerry
Ron Natalie
> In K&R's original compiler, this was almost certainly done by the
> lexer, which was almost certainly generated by lex. Consequently,
> they would have had no reason to add such a function to their library.
Certainly it was handled by the lexical analyzer, but the K&R
compiler predates YACC and YACC predates LEX.
-Ron
---
Douglas A. Gwyn
> Yeah, that was more or less the committee response when I suggested
> that we needed an '\e' character sequence years ago. Apparently,
I don't know about the C++ group, but the main reason against \e
standardization in C is that ESC is specific to certain codesets
and need not have a representation in others. Odds are that what
you *really* want in all environments where you plan to use ESC
sequences is the numeric value, e.g. #define ESC 27. You can do
that already in Standard C.
There are already standards (e.g. X.64) for the semantics of
escape sequences. Note that an actual VT100 has several weird
quirks (in its microcode) that make it less than an ideal model.
Larry Jones
>
> I don't know about the C++ group, but the main reason against \e
> standardization in C is that ESC is specific to certain codesets
> and need not have a representation in others.
Which, it has been pointed out, is a completely specious argument. The
fact is that all popular, extant codesets have an ESC character, as do
most, if not all, of the unpopular ones. It is at least as common as
BEL (\a), if not more so.
> Odds are that what
> you *really* want in all environments where you plan to use ESC
> sequences is the numeric value, e.g. #define ESC 27. You can do
> that already in Standard C.
In some contexts that's true, but in at least as large a number of
contexts you want the ESC character in the native codeset, not the ASCII
ESC character reguardless of the native codeset.
> There are already standards (e.g. X.64) for the semantics of
> escape sequences. Note that an actual VT100 has several weird
> quirks (in its microcode) that make it less than an ideal model.
In my experience, an actual VT100 has many fewer quirks than most of the
devices that purport to emulate it. ;-)
-Larry Jones
The real fun of living wisely is that you get to be smug about it. -- Hobbes
Barry Margolin
In article <7qeoku$j...@nfs0.sdrc.com>,
Larry Jones <larry...@sdrc.com> wrote:
>Douglas A. Gwyn (DAG...@null.net) wrote:
>>
>> I don't know about the C++ group, but the main reason against \e
>> standardization in C is that ESC is specific to certain codesets
>> and need not have a representation in others.
>
>Which, it has been pointed out, is a completely specious argument. The
>fact is that all popular, extant codesets have an ESC character, as do
>most, if not all, of the unpopular ones. It is at least as common as
>BEL (\a), if not more so.
But what can you do *portably* with \e? ESC is normally used as the first
character of an escape sequence, and the rest of the escape sequence is
very dependent on the codeset. Since the rest of it will have to be
conditionalized (probably table driven, as in Unix termcap or terminfo), is
it really necessary to have the first character part of the standard?
--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Paul D. DeRocco
>
> But what can you do *portably* with \e? ESC is normally used as the first
> character of an escape sequence, and the rest of the escape sequence is
> very dependent on the codeset. Since the rest of it will have to be
> conditionalized (probably table driven, as in Unix termcap or terminfo), is
> it really necessary to have the first character part of the standard?
It isn't necessary, but it is such a commonly used character that one gets
tired of typing \33 or \x1B. What's more, those numeric forms don't work in
strings if followed by valid digits, so you wind up having to break strings,
e.g., "\x1B" "A" instead of "\eA". Ugly and hard to read.
--
Ciao, Paul D. DeRocco
Paul mailto:pder...@ix.netcom.com
---
Larry Jones
>
> But what can you do *portably* with \e? ESC is normally used as the first
> character of an escape sequence, and the rest of the escape sequence is
> very dependent on the codeset. Since the rest of it will have to be
> conditionalized (probably table driven, as in Unix termcap or terminfo), is
> it really necessary to have the first character part of the standard?
The rest of the escape sequence is very dependent on the codeset of the
*device*, not the codeset of the *program*. If I could write:
printf("\e[H\e[JHello, world!\n");
I would be confident that running that program with the output directed
to an ANSI terminal would clear the screen and write "Hello, world!" in
the top left corner, reguardless of the native codeset of the processor
running the program. That is, the program could well be running on an
EBCDIC system with the output directed to an ASCII device with some
hardware and/or software handling the ASCII/EBCDIC translation. As it
is, I can't write such code since I have to use \033 in ASCII and \047
in EBCDIC.
-Larry Jones
He's just jealous because I accomplish so much more than he does. -- Calvin
Barry Margolin
In article <37CCE33D...@ix.netcom.com>,
Paul D. DeRocco <pder...@ix.netcom.com> wrote:
>It isn't necessary, but it is such a commonly used character that one gets
>tired of typing \33 or \x1B. What's more, those numeric forms don't work in
>strings if followed by valid digits, so you wind up having to break strings,
>e.g., "\x1B" "A" instead of "\eA". Ugly and hard to read.
Why are you hard-coding escape sequences into C programs, rather than using
libraries like termcap? Why should the C standard be extended to support
something that's only useful for bad programming style? I realize that C
has a number of features that promote poor programming (e.g. gets()) but
these are legacies that we're stuck with for compatibility, not things that
have been added.
--
Barry Margolin, bar...@bbnplanet.com
GTE Internetworking, Powered by BBN, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
Douglas A. Gwyn
> printf("\e[H\e[JHello, world!\n");
Since this code is already very device-dependent, what is the beef
about it being codeset dependent as well? I.e. the termcap library
should already be responsible for mapping device properties to the
proper strings for output, and it is therefore a perfect place to
translate an abstract notions of "ESC character" to whatever code
is actually needed.
There are a *lot* of special characters, commonly supported in
popular codesets, that are not in the C basic character set and
that have no \-escape sequence defined for them in the C standard.
Some of them I find more useful than ESC, these days. As of C9x,
there is even a standard way to denote them in source code (UCN
notation). I don't think we need to add individual kludges when
there is a sufficient general mechanism.
---
Paul D. DeRocco
Barry Margolin wrote:
>
> Why are you hard-coding escape sequences into C programs, rather than using
> libraries like termcap? Why should the C standard be extended to support
> something that's only useful for bad programming style? I realize that C
> has a number of features that promote poor programming (e.g. gets()) but
> these are legacies that we're stuck with for compatibility, not things that
> have been added.
Because I'm not writing for Unix, so I have no "termcap" anywhere in sight.
When I'm using escape sequences, I'm writing mostly MS-DOS command line
utilities.
Now that computers can generate music, and not merely "beep", it seems to me
that the alert character is no more peculiar than an escape. And I don't think
I've _ever_ used a piece of hardware that understood vertical tab.
--
Ciao, Paul D. DeRocco
Paul mailto:pder...@ix.netcom.com
David R Tribble
"Douglas A. Gwyn" wrote:
>
> Larry Jones wrote:
> > printf("\e[H\e[JHello, world!\n");
>
> Since this code is already very device-dependent, what is the beef
> about it being codeset dependent as well? I.e. the termcap library
> should already be responsible for mapping device properties to the
> proper strings for output, and it is therefore a perfect place to
> translate an abstract notions of "ESC character" to whatever code
> is actually needed.
Assuming you're even using the termcap library.
> There are a *lot* of special characters, commonly supported in
> popular codesets, that are not in the C basic character set and
> that have no \-escape sequence defined for them in the C standard.
> Some of them I find more useful than ESC, these days. As of C9x,
> there is even a standard way to denote them in source code (UCN
> notation). I don't think we need to add individual kludges when
> there is a sufficient general mechanism.
I suppose I can live with having to type "...\u001B..." instead of
"...\e...". The only possible drawback I can see is that \u001B is
specifically the ASCII/Unicode ESC character, which could
concievably translate into a character that is not the appropriate
"escape" character on some non-ASCII/Unicode systems (whatever that
means). QoI?
The standard, BTW, does not prohibit implementations from supporting
extensions such as "\E" or even "\ESC\DEL\NUL". They're just not
portable.
-- David R. Tribble, da...@tribble.com --
Larry Jones
>
> I suppose I can live with having to type "...\u001B..." instead of
> "...\e...". The only possible drawback I can see is that \u001B is
> specifically the ASCII/Unicode ESC character, which could
> concievably translate into a character that is not the appropriate
> "escape" character on some non-ASCII/Unicode systems (whatever that
> means). QoI?
A bigger drawback is the constraint in 6.4.3 that "A universal character
name shall not specify a character whose short identifier is less than
00A0...".
-Larry Jones
Hmph. -- Calvin
---
Douglas A. Gwyn
Larry Jones wrote:
> A bigger drawback is the constraint in 6.4.3 that "A universal
> character name shall not specify a character whose short identifier
> is less than 00A0...".
I had temporarily forgotten about that.
It makes sense to limit the range of short-identifiers that can be
used in identifiers, but remind me again why some punctuation,
space, and control characters can be expressed via UCN and others
cannot. If we meant to exclude *only* the C basic source
characters then that's what we should have said.
Adam Spragg
Larry Jones wrote:
>
> A bigger drawback is the constraint in 6.4.3 that "A universal character
> name shall not specify a character whose short identifier is less than
> 00A0...".
Huh? What's the rationale behind that one?
Adam
--
Why is it that the smaller and easier a bug is to fix, the less I want
to actually fix it?
----------------
The opinions expressed in this email are mine alone, and do not
neccesarily represent those of my employer, my parents, or the people
who wrote the email software I use.
Clive D.W. Feather
In article <37D3FC7D...@null.net>, Douglas A. Gwyn
<DAG...@null.net> writes
>> A bigger drawback is the constraint in 6.4.3 that "A universal
>> character name shall not specify a character whose short identifier
>> is less than 00A0...".
>If we meant to exclude *only* the C basic source
>characters then that's what we should have said.
We meant to exclude:
- the C basic source characters
- the C0 and C1 control spaces (0 to 31, 127 to 159).
The cited words are the minimum that achieve that goal.
--
Clive D.W. Feather | Internet Expert | Work: <cl...@demon.net>
Tel: +44 20 8371 1138 | Demon Internet Ltd. | Home: <cl...@davros.org>
Fax: +44 20 8371 1037 | | Web: <http://www.davros.org>
Written on my laptop; please observe the Reply-To address
Max TenEyck Woodbury
>
> Barry Margolin (bar...@bbnplanet.com) wrote:
>>
>> But what can you do *portably* with \e? ESC is normally used as the first
>> character of an escape sequence, and the rest of the escape sequence is
>> very dependent on the codeset. Since the rest of it will have to be
>> conditionalized (probably table driven, as in Unix termcap or terminfo), is
>> it really necessary to have the first character part of the standard?
>
> The rest of the escape sequence is very dependent on the codeset of the
> *device*, not the codeset of the *program*. If I could write:
>
>
> to an ANSI terminal would clear the screen and write "Hello, world!" in
> the top left corner, reguardless of the native codeset of the processor
> running the program. That is, the program could well be running on an
> EBCDIC system with the output directed to an ASCII device with some
> hardware and/or software handling the ASCII/EBCDIC translation. As it
> is, I can't write such code since I have to use \033 in ASCII and \047
> in EBCDIC.
>
> -Larry Jones
The best way I have found to handle this kind of thing is to build
a header file with the appropriate character sequences defined as
macros. For example in ASCII.H define:
#define STR_NUL "\000"
#define CHAR_NUL ('\000)
...
#define STR_BEL "\007"
#define CHAR_BEL ('\007)
#define STR_BS "\010"
#define CHAR_BS ('\010)
#define STR_HT "\011"
#define CHAR_HT ('\011)
#define STR_LF "\012"
#define CHAR_LF ('\012)
#define STR_VT "\013"
#define CHAR_VT ('\013)
#define STR_FF "\014"
#define CHAR_FF ('\014)
#define STR_CR "\015"
#define CHAR_CR ('\015)
...
#define STR_ESC "\033"
#define CHAR_ESC ('\033)
...
#define STR_H "\110"
#define CHAR_H ('\110)
...
#define STR_J "\112"
#define CHAR_J ('\112)
...
#define STR_OSB "\134"
#define CHAR_OSB ('\134)
and in VT100.H define something like:
...
#if ('\n == CHAR_LF)
#define TERMCAP_NL "\n"
#else
#define TERMCAP_NL STR_CR STR_LF
#endif
...
#define TERMCAP_INTRO STR_ESC STR_OSB
...
#define TERMCAP_HOME TERMCAP_INTRO STR_H
...
#define TERMCAP_CLEAR_EOS TERMCAP_INTRO STR_J
...
#define TERMCAP_CLS TERMCAP_HOME TERMCAP_CLEAR_EOS
...
then the code would look like:
#include "ASCII.H"
#include "VT100.H"
...
printf( TERMCAP_CLS "Hello, world!" TERMCAP_NL);
Given this approach, it becomes clear that very few of the
output formatting characters belong in the 'C' standard. In
fact, only the escaped characters needed to define the input
language are really needed. \a and \b are included mainly
because a number of old programs use them.
Note that the contents of files like ASCII.H and VT100.H
are 'bindings' of other standards on 'C' and could be required
as part of those other standard, but do NOT belong in the 'C'
standard.
In any case there is no NEED to add \e. Including it would
encourage writing non-portable code.
John Hauser
Larry Jones:
> A bigger drawback is the constraint in 6.4.3 that "A universal
> character name shall not specify a character whose short identifier
> is less than 00A0...".
Douglas Gwyn:
> If we meant to exclude *only* the C basic source
> characters then that's what we should have said.
Clive Feather:
> We meant to exclude:
> - the C basic source characters
> - the C0 and C1 control spaces (0 to 31, 127 to 159).
> The cited words are the minimum that achieve that goal.
What about \u0024 ($), \u0040 (@), and \u0060 (`)?
- John Hauser
Paul D. DeRocco
David R Tribble wrote:
>
> I would wager that >50% of all C/C++ code is not intended to be
> portable.
And 99% of all C/C++ code is not intended to be portable to machines that
don't speak ASCII.
--
Ciao, Paul D. DeRocco
Paul mailto:pder...@ix.netcom.com
Clive D.W. Feather
In article <37D5A7F6...@cs.berkeley.edu>, John Hauser
<jha...@cs.berkeley.edu> writes
>Larry Jones:
>> A bigger drawback is the constraint in 6.4.3 that "A universal
>> character name shall not specify a character whose short identifier
>> is less than 00A0...".
>Clive Feather:
>> We meant to exclude:
>> - the C basic source characters
>> - the C0 and C1 control spaces (0 to 31, 127 to 159).
>> The cited words are the minimum that achieve that goal.
>
>What about \u0024 ($), \u0040 (@), and \u0060 (`)?
The *cited* words (as opposed to the quoted ones) continue with "...
other than 0024 ($), 0040 (@), or 0060 (`),".
They then add: "nor one in the range D800 through DFFF inclusive.",
which exclude the multi-Unicode encoding values.
--
Clive D.W. Feather | Internet Expert | Work: <cl...@demon.net>
Tel: +44 20 8371 1138 | Demon Internet Ltd. | Home: <cl...@davros.org>
Fax: +44 20 8371 1037 | | Web: <http://www.davros.org>
Written on my laptop; please observe the Reply-To address
Douglas A. Gwyn
> Max TenEyck Woodbury wrote:
> > In any case there is no NEED to add \e. Including it would
> > encourage writing non-portable code.
Lack of \e as a standard escape doesn't prevent you from writing
a non-portable equivalent. I don't see how to make \e portable
anyway, without restricting the run-time codeset choices more
that we ever have before.
---
Paul D. DeRocco
"Douglas A. Gwyn" wrote:
>
> Lack of \e as a standard escape doesn't prevent you from writing
> a non-portable equivalent. I don't see how to make \e portable
> anyway, without restricting the run-time codeset choices more
> that we ever have before.
If the standard requires BEL (which is meaningless in printed output) or VT
(which I've never found support for in any printer I've used since the
70's), why can't it require ESC? The only codesets I'm aware of are ASCII
and EBCDIC. They both have codes for CR, LF, HT, VT, FF, BS and BEL. And
they both have codes for ESC (0x27 in EBCDIC).
Is it any more likely that some obscure codeset out there doesn't have an
ESC character, than that it doesn't have a BEL or VT character? Are there
any real-world codesets out that have CR, LF, HT, VT, FF, BS and BEL, but
don't have ESC? If there exists a codeset that doesn't have, say, BEL, and
the compiler deals with \a in some nonstandard manner (perhaps with an
error message), it could do the same for \e if it doesn't have ESC.
The objections to \e seem awfully farfetched, compared to its obvious
advantages in typability and readability.
--
Ciao, Paul D. DeRocco
Paul mailto:pder...@ix.netcom.com
Max TenEyck Woodbury
>
> David R Tribble wrote:
> >
> > I would wager that >50% of all C/C++ code is not intended to be
> > portable.
>
> And 99% of all C/C++ code is not intended to be portable to machines that
> don't speak ASCII.
And 90%+ of all portability problems arise because a program that was
never intended to be ported has to be ported. The whole Y2K mess has
come up for similar reasons. This kind of thinking should NOT be
encouraged!
Pete Becker
"Paul D. DeRocco" wrote:
>
> "Douglas A. Gwyn" wrote:
> >
> > Lack of \e as a standard escape doesn't prevent you from writing
> > a non-portable equivalent. I don't see how to make \e portable
> > anyway, without restricting the run-time codeset choices more
> > that we ever have before.
>
> If the standard requires BEL (which is meaningless in printed output) or VT
The standard doesn't require BEL or VT. It requires '\a' and '\f' and
describes what effects they have.
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
Ken Hagan
Max TenEyck Woodbury wrote in message
>And 90%+ of all portability problems arise because a program that was
>never intended to be ported has to be ported. The whole Y2K mess has
>come up for similar reasons. This kind of thinking should NOT be
>encouraged!
I think the Y2K mess is a result of "not thinking", rather than "thinking
badly". C++ is not one of those fascist languages which teaches you
"good programming".
Constructs which produce unportable code are already quite common.
(reinterpret_cast?) "\e" is being advocated as a convenience for those
(many) people working on systems which have such a beast. I think I
could make a stronger case for \e than for \a.
Steve Clamage
"Ken Hagan" <K.H...@thermoteknix.co.uk> writes:
>Max TenEyck Woodbury wrote in message
>>And 90%+ of all portability problems arise because a program that was
>>never intended to be ported has to be ported. The whole Y2K mess has
>>come up for similar reasons. This kind of thinking should NOT be
>>encouraged!
>I think the Y2K mess is a result of "not thinking", rather than "thinking
>badly".
You have to put yourself in the position of a programmer in
the late 1960's. Mainframe computers had a few hundred Kbytes of
memory. Minicomputers had maybe 64K of memory. Disk drives were
physically large and expensive, used only for system programs,
swap space, and spooling. (A 10Mb drive was considered big.)
Computers used banks of tape drives for data.
You are writing a program to handle millions of records of
data, each containing several dates. If you can save 2 bytes
per date, it can make the difference between acceptable and
unacceptable overall performance.
You're not stupid. You know that a 2-digit date interface will
fail after 1999. But you know for sure that your program will
no longer be in use that far in the future. Why give up
performance to avoid a problem that will never happen?
That isn't "not thinking" or "thinking badly". It's sound
engineering.
Now put yourself in the position of a DP manager in the 1970's
or 1980's. Assume you know about the 2-digit date problem.
You've got a set of programs that are reliable enough. Replacing
them would cost several large fortunes, and you don't have the
budget for it. Year 2000 is still a long way off, and the
cost in money, time, and possible lost reliability while a
new set of programs mature has no short-term or medium-term
payoff. You could never sell it to top management even if you
thought it was a good idea. Well, you'll be retired before
1999, and it will be somebody else's problem.
I think Max's evaluation is correct.
--
Steve Clamage, stephen...@sun.com
Max TenEyck Woodbury
"Paul D. DeRocco" wrote:
>
> If the standard requires BEL (which is meaningless in printed output) or VT
> 70's), why can't it require ESC? The only codesets I'm aware of are ASCII
> and EBCDIC. They both have codes for CR, LF, HT, VT, FF, BS and BEL. And
> they both have codes for ESC (0x27 in EBCDIC).
>
> Is it any more likely that some obscure codeset out there doesn't have an
> ESC character, than that it doesn't have a BEL or VT character? Are there
> any real-world codesets out that have CR, LF, HT, VT, FF, BS and BEL, but
> don't have ESC? If there exists a codeset that doesn't have, say, BEL, and
> the compiler deals with \a in some nonstandard manner (perhaps with an
> error message), it could do the same for \e if it doesn't have ESC.
>
> The objections to \e seem awfully farfetched, compared to its obvious
> advantages in typability and readability.
At best you have argued here that \v and \a should be dropped from the
standard, not that \e should be added. The old values are kept because
old programs use them and because \v is part of the input language. A
compiler that refused to compile a program with an \a in it would not
be a conforming compiler. You will gain nothing with this line of argument.
If you want to make your case, you'll need to explain why \e has to be added,
not why other escaped characters are useless. The only positive argument I've
seen so far is that you would find it convenient and you don't want to use
existing portable methods. That's not enough to mandate such a change and
require all implementations to comply.
Clive D.W. Feather
In article <7rbbgb$sem$1...@engnews1.eng.sun.com>, Steve Clamage
<cla...@eng.sun.com> writes
>>I think the Y2K mess is a result of "not thinking", rather than "thinking
>>badly".
It's neither, as Steve partially explained:
>You have to put yourself in the position of a programmer in
>the late 1960's. Mainframe computers had a few hundred Kbytes of
>memory.
[...]
>You are writing a program to handle millions of records of
>data, each containing several dates. If you can save 2 bytes
>per date, it can make the difference between acceptable and
>unacceptable overall performance.
Furthermore, I seem to recall reading (in _The_Mythical_Man_Month,
perhaps) that mainframe memory was *rented* for sums of around $1000 per
kilobyte per month. Suppose your software handed 500 dates in memory at
a time (not unreasonable when merging data) and was responsible for 20%
of machine use (also not unreasonable for a major application). Then the
2 bytes for the century cost *two hundred dollars per month*. Prices
have gone up by at least a factor of 10 by then.
>You're not stupid. You know that a 2-digit date interface will
>fail after 1999. But you know for sure that your program will
>no longer be in use that far in the future.
Even if it is, you can afford to wait several years and let those $200
per month build up to pay the changeover cost in 1995.
>Now put yourself in the position of a DP manager in the 1970's
>or 1980's. Assume you know about the 2-digit date problem.
>You've got a set of programs that are reliable enough. Replacing
>them would cost several large fortunes,
[...]
And it's not unlikely that you'll be moving to a new machine or even
architecture before then. So you can put the rewrite off until the
porting work happens. Again, sound business practice.
--
Clive D.W. Feather | Internet Expert | Work: <cl...@demon.net>
Tel: +44 20 8371 1138 | Demon Internet Ltd. | Home: <cl...@davros.org>
Fax: +44 20 8371 1037 | | Web: <http://www.davros.org>
Written on my laptop; please observe the Reply-To address
Paul D. DeRocco
Pete Becker wrote:
>
> "Paul D. DeRocco" wrote:
> >
> > "Douglas A. Gwyn" wrote:
> > >
> > > Lack of \e as a standard escape doesn't prevent you from writing
> > > a non-portable equivalent. I don't see how to make \e portable
> > > anyway, without restricting the run-time codeset choices more
> > > that we ever have before.
> >
> > or VT
>
> describes what effects they have.
The standard requires "alert" and "vertical tab", though. (2.2 paras 1 and
3) I was merely using their common ASCII (and EBCDIC) abbreviations. Who's
to say that a compiler writer is more likely to encounter some obscure
execution character set that has no "escape", than that has no "vertical
tab" or "alert"?
What's more, it's obvious what a compiler writer should do when presented
with an execution character set that doesn't contain "escape", or for that
matter "vertical tab" or "alert". If the program uses \e, or \v or \a,
issue an error message, because the attempt to use _any_ character not
actually in the execution character set is a logical error.
--
Ciao, Paul D. DeRocco
Paul mailto:pder...@ix.netcom.com
Paul D. DeRocco
>
> "Paul D. DeRocco" wrote:
> >
> > that don't speak ASCII.
>
> never intended to be ported has to be ported. The whole Y2K mess has
> come up for similar reasons. This kind of thinking should NOT be
> encouraged!
I think the two questions are quite different. Adding \e to the legal list
of C++ escapes could be cleanly diagnosed as an error should someone try to
port a program containing it to a character set other than ASCII or EBCDIC
that has no ESC character. And the compiler error message would correctly
reflect an underlying logical problem that would need to be fixed. Y2K bugs
don't have anything to do with porting; they cannot be caught by a
compiler, and wind up being bugs in the code, which is quite another thing.
--
Ciao, Paul D. DeRocco
Paul mailto:pder...@ix.netcom.com
---
Douglas A. Gwyn
"Paul D. DeRocco" wrote:
> The standard requires "alert" and "vertical tab", though. ... I was
> merely using their common ASCII (and EBCDIC) abbreviations.
Here is a challenge for you: Write a functional specification for
the character which would probably be mapped to ESC in an ASCII
implementation, along the lines of the specifications for other
device control functions. (If we *were* to add \e, we'd have to
come up with such wording.) Then maybe you'll see why this is
not likely to be standardized *at this level*.
Douglas A. Gwyn
Max TenEyck Woodbury wrote:
> At best you have argued here that \v and \a should be dropped from the
> standard, not that \e should be added. The old values are kept because
> old programs use them and because \v is part of the input language.
Indeed, I would probably support changes along those lines,
even though some miniscule portion of existing source code
might contain them. In environments where they have a use,
I would expect C implementations to continue to support them
as an extension. (This would be allowed if such a change to
the spec were made properly.)
However, since nobody seems to be beating down our door
complaining about these, common sense says that they should
be left alone. There are more important things to worry about.
Al Stevens
>You have to put yourself in the position of a programmer in
>the late 1960's.
That's what I was doing then. Started in the late 1950s actually.
>Disk drives were
>physically large and expensive, used only for system programs,
>swap space, and spooling.
That's not entirely true. We were using disk drives for random access file
applications starting as early as 1959. As I remember, the software
technology (hashing, indexed-sequential, etc.) for doing that was well
understood even then, so someone must have been doing it even before we did.
Many commercial applications used sequential master files and were indeed
stored on tape, although a typical system might load them to disk to process
them, but we had interactive database queries and updates against permanent
disk files in the late 1950s.
>You're not stupid. You know that a 2-digit date interface will
>fail after 1999. But you know for sure that your program will
>no longer be in use that far in the future.
I have specific memories of thinking exactly that at the time.
>That isn't "not thinking" or "thinking badly". It's sound
>engineering.
Thanks. I've been feeling guilty for the past couple of years.
>Well, you'll be retired before
>1999, and it will be somebody else's problem.
Well, I didn't.
Paul D. Smith
[ moderator's note: This discussion has gone completely outside the
charter for comp.std.c++, however fascinating the history of
application program development may be. Further discussion that
does not in some small way relate to standard C++ should not
include comp.std.c++ in the list of newsgroups. -sdc ]
%% "Clive D.W. Feather" <cl...@on-the-train.demon.co.uk> writes:
cdwf> In article <7rbbgb$sem$1...@engnews1.eng.sun.com>, Steve Clamage
cdwf> <cla...@eng.sun.com> writes
>>> I think the Y2K mess is a result of "not thinking", rather than "thinking
>>> badly".
cdwf> It's neither, as Steve partially explained:
>> You have to put yourself in the position of a programmer in
>> the late 1960's. Mainframe computers had a few hundred Kbytes of
>> memory.
cdwf> [...]
>> You are writing a program to handle millions of records of
>> data, each containing several dates. If you can save 2 bytes
>> per date, it can make the difference between acceptable and
>> unacceptable overall performance.
cdwf> Furthermore, I seem to recall reading (in
cdwf> _The_Mythical_Man_Month, perhaps) that mainframe memory was
cdwf> *rented* for sums of around $1000 per kilobyte per
cdwf> month. Suppose your software handed 500 dates in memory at a
cdwf> time (not unreasonable when merging data) and was responsible
cdwf> for 20% of machine use (also not unreasonable for a major
cdwf> application). Then the 2 bytes for the century cost *two hundred
cdwf> dollars per month*. Prices have gone up by at least a factor of
cdwf> 10 by then.
I can't believe this is the real reason.
If it really were a case of data storage constraints and money, why
weren't programmers using only _one_ byte, and storing a range of 255
years in it? They'd have saved lots of money, and we'd be set until at
least 2155 (to pick a fairly reasonable epoch). Even if you had only
6-bit bytes you could get a lot better than 20-odd years out of two
bytes.
--
-------------------------------------------------------------------------------
Paul D. Smith <psm...@baynetworks.com> Network Management Development
"Please remain calm...I may be mad, but I am a professional." --Mad Scientist
-------------------------------------------------------------------------------
These are my opinions---Nortel Networks takes no responsibility for them.
Francis Glassborow
In article <37D97855...@ix.netcom.com>, Paul D. DeRocco
<pder...@ix.netcom.com> writes
>I think the two questions are quite different. Adding \e to the legal list
>of C++ escapes could be cleanly diagnosed as an error should someone try to
>port a program containing it to a character set other than ASCII or EBCDIC
>that has no ESC character.
I think you misunderstand what the Standard would require. There could
not be such an error because a compiler would be required to support \e
just as it is required to support \a etc.
BTW exactly what would be the definition of \e? I know exactly what \a,
\t etc. do (even though some systems may provide trivial meanings to
some of them) Note that the external representation of these are not
required to be single characters. E.g. \n maps to NL,CR on some
systems. While \a often maps to BEL it could map to anything, though
sensibly that should cause some form of alert. I think it would be
perfectly acceptable to arrange that \a flashed the screen (might be
quite useful for deaf users)
Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
Kai Henningsen
cla...@eng.sun.com (Steve Clamage) wrote on 10.09.99 in <7rbbgb$sem$1...@engnews1.eng.sun.com>:
> "Ken Hagan" <K.H...@thermoteknix.co.uk> writes:
>
> >Max TenEyck Woodbury wrote in message
> >>And 90%+ of all portability problems arise because a program that was
> >>never intended to be ported has to be ported. The whole Y2K mess has
> >>come up for similar reasons. This kind of thinking should NOT be
> >>encouraged!
>
> >I think the Y2K mess is a result of "not thinking", rather than "thinking
> >badly".
>
> You have to put yourself in the position of a programmer in
> the late 1960's. Mainframe computers had a few hundred Kbytes of
> memory. Minicomputers had maybe 64K of memory. Disk drives were
> physically large and expensive, used only for system programs,
> swap space, and spooling. (A 10Mb drive was considered big.)
> Computers used banks of tape drives for data.
>
> You are writing a program to handle millions of records of
> data, each containing several dates. If you can save 2 bytes
> per date, it can make the difference between acceptable and
> unacceptable overall performance.
On the other hamd, you *know* (or at least, you'd knew if you thought for
a minute) that this is bound to make (many) programs using this trick
simply wrong, without waiting for 2000-01-01.
You know, I remember hearing about grandmothers called in for baby
vaccination, because someone had a Y1900 problem. That cannot have been
later then, say, 1975; and there's no reason to believe 1960 was really
any different.
That is, the mistake is in assuming a program can get away with handling
only 100 years. Very often, that's just not true, even without looking at
archaeology.
> You're not stupid. You know that a 2-digit date interface will
> fail after 1999.
You are stupid, because you forget that it may well fail *tomorrow*. When
you have to deal with someone past their 100th birthday. Or when you have
to deal with a deed from 61 years ago. Or one that will run for 41 years.
It's really not true that century problems only happen when the calendar
reaches 2000-01-01. And it never *was* true in the first place.
> That isn't "not thinking" or "thinking badly". It's sound
> engineering.
It's crappy engineering. And I say that even though I've done nothing to
solve a similar problem in a project I once worked with.
Kai
--
http://www.westfalen.de/private/khms/
"... by God I *KNOW* what this network is for, and you can't have it."
- Russ Allbery (r...@stanford.edu)
Greg Brewer
Let me attempt to bring this back on topic.
While the Y2K problem may have its roots in old systems implemented when
data space was very expensive, I was fighting against implementations that
contained the Y2K bug throughout the 80's. The problem was similar to a Y2K
bug that existed on my checks. Until last year, the date portion of my
checks had "______________, 19__" on them and my deposit slips still do.
After this year, I expect my checks will start having "_______, 20__"
printed on them.
The problem is that when you enter 80 for the year, people automatically
assume 1980. I expect this kind of coding will start creeping back into our
coding some time after 2020. With that in mind, I'm wondering if C/C++
wouldn't benefit from a function that converts a 2 digit year to a 4 digit
year. Mind you now, this is not well thought out and I thought others might
have ideas that enhance it. Consider that at least for the first 20 years
or so, a value of 14 will probably be taken as 2014 and a value of 84 will
often mean 1984. Around the middle of the century, 14 and 84 will both
refer to 20xx dates. Toward the end of the 21st century, 84 will likely
mean 2084 and 14 will be 2114. I take this from my current Y2K bug fixes
where I code a 2 digit years less than some value means 20yy and a 2 digit
year greater than 19yy while a 4 digit year is not changed.
The reason I think that creating a standard function might be a good idea is
that it would standardize the rotation rates. Lets take 33 and 66.
if (given_year > 50 && current_year < 33) return last_century +
given_year;
if (given_year < 50 && current_year > 66) return next_century +
given_year;
return current_century + given_year;
Again, this is not a well thought out idea; just something that has occurred
to me recently.
Greg Brewer
Paul D. Smith <paus...@nortelnetworks.com> wrote in message
news:p5lnaet...@baynetworks.com...
>
> [ moderator's note: This discussion has gone completely outside the
> charter for comp.std.c++, however fascinating the history of
> application program development may be. Further discussion that
> does not in some small way relate to standard C++ should not
> include comp.std.c++ in the list of newsgroups. -sdc ]
Kai Henningsen
> BTW exactly what would be the definition of \e? I know exactly what \a,
> \t etc. do (even though some systems may provide trivial meanings to
> some of them)
Does that "etc." include \v? And can you explain to me what, exactly, \v
does in any kind of non-printer context?
\e would be the codeset escape function. I certainly know what *that* is.
And it's supported in *far* more situations than \v is.
Kai
--
http://www.westfalen.de/private/khms/
"... by God I *KNOW* what this network is for, and you can't have it."
- Russ Allbery (r...@stanford.edu)
---
Kai Henningsen
> "Paul D. DeRocco" wrote:
> > The standard requires "alert" and "vertical tab", though. ... I was
> > merely using their common ASCII (and EBCDIC) abbreviations.
>
> Here is a challenge for you: Write a functional specification for
> the character which would probably be mapped to ESC in an ASCII
> implementation, along the lines of the specifications for other
> device control functions.
You mean using lots of concepts not defined in the standard?
\e (escape) The codeset escape function. Invokes a different
interpretation for one or more following characters.
There. That wasn't all that hard, now was it?
You could add a footnote listing some relevant standards that use it (for
example, ISO 2022).
>(If we *were* to add \e, we'd have to
> come up with such wording.) Then maybe you'll see why this is
> not likely to be standardized *at this level*.
I don't think this argument works.
Pete Becker
>
> DAG...@null.net (Douglas A. Gwyn) wrote on 11.09.99 in <37D9B107...@null.net>:
>
> > "Paul D. DeRocco" wrote:
> > > The standard requires "alert" and "vertical tab", though. ... I was
> > > merely using their common ASCII (and EBCDIC) abbreviations.
> >
> > Here is a challenge for you: Write a functional specification for
> > the character which would probably be mapped to ESC in an ASCII
> > implementation, along the lines of the specifications for other
> > device control functions.
>
> You mean using lots of concepts not defined in the standard?
>
> \e (escape) The codeset escape function. Invokes a different
> interpretation for one or more following characters.
>
So an implementation in which printf("\ea") displayed the letter a would
not be conforming, because the letter a isn't a different interpretation
of the character constant 'a'.
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
Francis Glassborow
<kaih=7OmpF...@khms.westfalen.de> writes
>Does that "etc." include \v? And can you explain to me what, exactly, \v
>does in any kind of non-printer context?
>
>\e would be the codeset escape function. I certainly know what *that* is.
>And it's supported in *far* more situations than \v is.
\v is unambiguously 'vertical tab' whether that has or has not any
effect on the output is entirely dependent on hardware. Now you tell me
exactly what you mean be a codeset escape function. IMO not only is it
dependent on the codeset but how it is used and what its significance is
is also equally dependent. IOWs \v has a single uniform meaning that
may be implemented differently on different equipment, but the meaning
of \ea could be entirely different for different codesets.
Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
James...@dresdner-bank.com
In article <7rj23q$24kd$1...@news.hal-pc.org>,
This is sort of what the Java DateFormat class (which also parses)
does. Two digit years are presumed to be in a 100 year interval
starting at a given date. The default starting date is the current date
minus 80 years; this value can be set by the programmer, however.
--
James Kanze mailto: James...@dresdner-bank.com
Conseils en informatique orientée objet/
Beratung in objekt orientierter Datenverarbeitung
Ziegelhüttenweg 17a, 60598 Frankfurt, Germany Tel. +49(069)63198627
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Francis Glassborow
In article <7OmpF$WX...@khms.westfalen.de>, Kai Henningsen
<kaih=7OmpF$WX...@khms.westfalen.de> writes
>You mean using lots of concepts not defined in the standard?
>
>\e (escape) The codeset escape function. Invokes a different
> interpretation for one or more following characters.
But I do not find that in any way portable and so has, from my
perspective, very little utility.
Francis Glassborow Journal Editor, Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
Pete Becker
Kai Henningsen wrote:
>
> fra...@robinton.demon.co.uk (Francis Glassborow) wrote on 11.09.99 in <egKSkRA3Dj23EwF$@robinton.demon.co.uk>:
>
> > BTW exactly what would be the definition of \e? I know exactly what \a,
> > \t etc. do (even though some systems may provide trivial meanings to
> > some of them)
>
> does in any kind of non-printer context?
>
> \e would be the codeset escape function. I certainly know what *that* is.
Do you? Please explain what '\e' would do. Complete the following
paragraph (paraphrased from the C standard):
'\a' produces an audible or visible alert. '\b' moves the active
position to the previous position on the current line. '\f' moves hte
active position to the initial position at the start of the next logical
page. '\n' moves the active position to the initial position of the next
line. '\r' moves the active position to the initial position of the
current line. '\t' moves the active position to the next horizontal
tabulation position on the current line. '\v' moves the active positon
to the initial position of the next vertical tabulation position. '\e'
.....
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
Paul Jarc
Francis Glassborow <fra...@robinton.demon.co.uk> writes:
> In article <7OmpF...@khms.westfalen.de>, Kai Henningsen
> <kaih=7OmpF...@khms.westfalen.de> writes
>
> \v is unambiguously 'vertical tab' whether that has or has not any
> effect on the output is entirely dependent on hardware. Now you tell me
> exactly what you mean be a codeset escape function.
You tell me exactly what you mean by a vertical tab. If an
implementation isn't required to do anything in particular with \v,
why should it be with \e?
> IOWs \v has a single uniform meaning that may be implemented
> differently on different equipment, but the meaning of \ea could be
> entirely different for different codesets.
The same is true of \v, since according to C9X 5.2.2p2 the
interpretations of these escape sequences are only intended, not
required.
paul
Kai Henningsen
fra...@robinton.demon.co.uk (Francis Glassborow) wrote on 14.09.99 in <FWw0JXAY...@robinton.demon.co.uk>:
> In article <7OmpF...@khms.westfalen.de>, Kai Henningsen
> <kaih=7OmpF...@khms.westfalen.de> writes
> >Does that "etc." include \v? And can you explain to me what, exactly, \v
> >does in any kind of non-printer context?
> >
> >\e would be the codeset escape function. I certainly know what *that* is.
> >And it's supported in *far* more situations than \v is.
>
> \v is unambiguously 'vertical tab' whether that has or has not any
> effect on the output is entirely dependent on hardware. Now you tell me
> exactly what you mean be a codeset escape function.
It changes the interpretation of one or more following characters.
>IMO not only is it
> dependent on the codeset but how it is used and what its significance is
> is also equally dependent.
Just like \v, then, except it's useful in more contexts. (Incidentally, if
\v and \a context validity isn't completely disjunct, then it's surely
close to - \v is practically only found on printers, and \a is practically
never found on printers.)
>IOWs \v has a single uniform meaning that
> may be implemented differently on different equipment, but the meaning
> of \ea could be entirely different for different codesets.
Actually, the meaning is just as uniform.
Kai
--
http://www.westfalen.de/private/khms/
"... by God I *KNOW* what this network is for, and you can't have it."
- Russ Allbery (r...@stanford.edu)
David R Tribble
> > >
> > > Here is a challenge for you: Write a functional specification for
> > > the character which would probably be mapped to ESC in an ASCII
> > > implementation, along the lines of the specifications for other
> > > device control functions.
> >
> >
> > \e (escape) The codeset escape function. Invokes a different
> >
>
> So an implementation in which printf("\ea") displayed the letter a
> would not be conforming, because the letter a isn't a different
> interpretation of the character constant 'a'.
We should choose words that make "\ea" implementation-defined, to
wit:
\e (escape)
The codeset escape function. Produces an implementation-defined
interpretation for one or more following characters.
Now "\ea" could very well result in "a". As could "\e[Ha".
-- David R. Tribble, da...@tribble.com --
David R Tribble
>
> David R Tribble wrote:
> >
> > portable.
>
> And 99% of all C/C++ code is not intended to be portable to machines
> that don't speak ASCII.
What with IBM having embraced Unix for OS/390 (USS), this is slowly
becoming less true. And then, of course, there's Unicode looming
on the horizon (which, it's true, is really just fat ASCII)...
-- David R. Tribble, da...@tribble.com --
---
David R Tribble
>
> Max TenEyck Woodbury wrote:
> > At best you have argued here that \v and \a should be dropped from
> > the standard, not that \e should be added. The old values are kept
> > because
> > old programs use them and because \v is part of the input language.
>
> Indeed, I would probably support changes along those lines,
> even though some miniscule portion of existing source code
> might contain them. In environments where they have a use,
> I would expect C implementations to continue to support them
> as an extension. (This would be allowed if such a change to
> the spec were made properly.)
If nothing else, every C/C++/LEX/YACC lexical analyzer would have to
be rewritten if those characters were eliminated.
Kai Henningsen
> The reason I think that creating a standard function might be a good idea is
> that it would standardize the rotation rates. Lets take 33 and 66.
> if (given_year > 50 && current_year < 33) return last_century +
> given_year;
> if (given_year < 50 && current_year > 66) return next_century +
> given_year;
> return current_century + given_year;
The obvious solution is to take the closest version. I've implemented that
myself, and I believe I've seen it standardized somewhere.
That is, for a two-digit year of 17, when the current year is 1999, have a
look at 1817, 1917, and 2017. The absolute delta to our year is 182, 82,
and 18 years; so 2017 it is. (Of course, you can optimize this so you do
not actually need to determine a minimum of three differences.)
This fails for 49 (1949 is 50, 2049 is also 50). Just pick one is probably
good enough in most cases. (And if it isn't, you need extra information to
know what's better.)
Of course, just using 4 digit dates is always preferreble, but sometimes
you have to deal with data that just doesn't have those.
Oh, yes, another important point: if you're dealing with *old* data, then
obviously using the current year is the wrong thing to do :-)
Kai
--
http://www.westfalen.de/private/khms/
"... by God I *KNOW* what this network is for, and you can't have it."
- Russ Allbery (r...@stanford.edu)
Kai Henningsen
> Kai Henningsen wrote:
> >
> > DAG...@null.net (Douglas A. Gwyn) wrote on 11.09.99 in
> > <37D9B107...@null.net>:
> >
> > > "Paul D. DeRocco" wrote:
> > > > The standard requires "alert" and "vertical tab", though. ... I was
> > > > merely using their common ASCII (and EBCDIC) abbreviations.
> > >
> > > Here is a challenge for you: Write a functional specification for
> > > the character which would probably be mapped to ESC in an ASCII
> > > implementation, along the lines of the specifications for other
> > > device control functions.
> >
> > You mean using lots of concepts not defined in the standard?
> >
> > \e (escape) The codeset escape function. Invokes a different
> > interpretation for one or more following characters.
> >
>
> So an implementation in which printf("\ea") displayed the letter a would
> not be conforming, because the letter a isn't a different interpretation
> of the character constant 'a'.
If by that you imply that an implementation where \v moved down to the
next line, but not to the initial position, would not be conforming?
Or one where \v did nothing at all?
Or one where \v displayed a "male symbol" ( circle with arrow)?
I've seen all of those. And I've never seen or heard anyone complain. (And
incidentally, it was never one of the things the C implementation would
have been expected to influence by anyone who wasn't a standards lawyer.)
IMHO, it would have been *far* saner to say "IF the execution character
set is (ASCII, ISO 646, something like that), THEN these escape sequences
map to the following control characters (NOT effects); for other character
sets, the meaning is implementation-defined".
John Hauser
> You tell me exactly what you mean by a vertical tab.
It's like a horizontal tab (\t), only in the vertical direction. It
introduces some implementation-defined amount of vertical whitespace
(possibly none). The safest use would presumably always follow '\n',
as in "First line.\n\vSecond line.\n".
Now you tell us exactly what you mean by an escape (\e).
- John Hauser
Pete Becker
Kai Henningsen wrote:
>
> peteb...@acm.org (Pete Becker) wrote on 14.09.99 in <37DE50EC...@acm.org>:
>
> > Kai Henningsen wrote:
> > >
> > > \e (escape) The codeset escape function. Invokes a different
> > > interpretation for one or more following characters.
> > >
> >
> > So an implementation in which printf("\ea") displayed the letter a would
> > not be conforming, because the letter a isn't a different interpretation
> > of the character constant 'a'.
>
> If by that you imply that an implementation where \v moved down to the
> next line, but not to the initial position, would not be conforming?
>
I said nothing about '\v'. I asked how you would apply your definition
of '\e' in a particular case. Since you decline to answer, I assume that
my interpretation is correct.
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
Clive D.W. Feather
>The reason I think that creating a standard function might be a good idea is
>that it would standardize the rotation rates. Lets take 33 and 66.
> if (given_year > 50 && current_year < 33) return last_century +
>given_year;
> if (given_year < 50 && current_year > 66) return next_century +
>given_year;
> return current_century + given_year;
Firstly, that might not be an ideal point to rotate. Secondly, it's not
always the current year that matters, but rather some reference year
based on the data. So both given_year and current_year, and for that
matter current_century, would have to be parameters of the function, and
the 50, 33, and 66 ought to be as well.
So we now have a function which can be written in portable code in about
10% of the space required to actually describe it fully. Not a good
candidate for standardisation.
--
Clive D.W. Feather | Internet Expert | Work: <cl...@demon.net>
Tel: +44 20 8371 1138 | Demon Internet Ltd. | Home: <cl...@davros.org>
Fax: +44 20 8371 1037 | | Web: <http://www.davros.org>
Written on my laptop; please observe the Reply-To address
---
Paul Jarc
> Paul Jarc:
> > You tell me exactly what you mean by a vertical tab.
>
> It's like a horizontal tab (\t), only in the vertical direction. It
> introduces some implementation-defined amount of vertical whitespace
> (possibly none). The safest use would presumably always follow '\n',
> as in "First line.\n\vSecond line.\n".
But all that is intent only. AFAICT, the standard mandates nothing
with regard to what happens when \v is output.
> Now you tell us exactly what you mean by an escape (\e).
I didn't claim to have a meaning in mind for \e. I'm just disputing
the claim that \v is better defined in the standard than \e could be,
or that \v belongs in the standard more than \e.
paul
Pete Becker
>
> Pete Becker wrote:
> >
> > Kai Henningsen wrote:
> > >
> > > DAG...@null.net (Douglas A. Gwyn) wrote
> > >
> > > > "Paul D. DeRocco" wrote:
> > > >
> > > > Here is a challenge for you: Write a functional specification for
> > > > the character which would probably be mapped to ESC in an ASCII
> > > > implementation, along the lines of the specifications for other
> > > > device control functions.
> > >
> > > You mean using lots of concepts not defined in the standard?
> > >
> > > interpretation for one or more following characters.
> > >
> >
> > So an implementation in which printf("\ea") displayed the letter a
> > would not be conforming, because the letter a isn't a different
> > interpretation of the character constant 'a'.
>
> wit:
>
> The codeset escape function. Produces an implementation-defined
> interpretation for one or more following characters.
>
>
Well, the original question asked for just such a specification. Clearly
the one given is inadequate, and now we get a recipe for perhaps
producing one in the future. Not exactly a sound basis for a
discussion...
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
Clive D.W. Feather
In article <7OmpF$WX...@khms.westfalen.de>, Kai Henningsen
<kaih=7OmpF$WX...@khms.westfalen.de> writes
> interpretation for one or more following characters.
>
Yes. In a codeset using the shift-out and shift-in concept for switching
between character sets, there are two different codes (14 and 15 in
ASCII) with that meaning.
On a BBC micro - an ASCII based system - there are six or seven codes
that have that meaning [*]. Curiously 27 isn't one of them.
[*] Plus, in some screen modes, another 25 or so.
--
Clive D.W. Feather | Internet Expert | Work: <cl...@demon.net>
Tel: +44 20 8371 1138 | Demon Internet Ltd. | Home: <cl...@davros.org>
Fax: +44 20 8371 1037 | | Web: <http://www.davros.org>
Written on my laptop; please observe the Reply-To address
Clive D.W. Feather
>> \t etc. do (even though some systems may provide trivial meanings to
>> some of them)
>
>does in any kind of non-printer context?
It moves the current position to the next vertical tabulation mark.
That's a concept exactly as well defined as \t is. For example, vertical
tabulation marks might be every 10 lines from the start of the output
*or* the latest form feed.
Clive D.W. Feather
In article <7Os69...@khms.westfalen.de>, Kai Henningsen
<kaih=7Os69...@khms.westfalen.de> writes
>IMHO, it would have been *far* saner to say "IF the execution character
>set is (ASCII, ISO 646, something like that), THEN these escape sequences
>map to the following control characters (NOT effects); for other character
>sets, the meaning is implementation-defined".
No it wouldn't. They weren't trying to write an ASCII-only Standard.
David R Tribble
Paul Jarc wrote:
>
> John Hauser <jha...@cs.berkeley.edu> writes:
> > Paul Jarc:
> > > You tell me exactly what you mean by a vertical tab.
> >
> > It's like a horizontal tab (\t), only in the vertical direction. It
> > introduces some implementation-defined amount of vertical whitespace
> > (possibly none). The safest use would presumably always follow
> > '\n', as in "First line.\n\vSecond line.\n".
>
> But all that is intent only. AFAICT, the standard mandates nothing
> with regard to what happens when \v is output.
It's interesting to note what the C89/C90/C9X Rationale says about
\v:
5.2.2 Character display semantics
...
The vertical tab sequence ('\v') was added since many existing
implementations support it, and since it is convenient to have a
designation within the language for all the defined white space
characters.
...
To avoid the issue of whether an implementation conforms if it
cannot properly effect vertical tabs (for instance), the Standard
emphasizes that the semantics merely describe intent.
Which means that an implementation could very well simply ignore
'\v' characters, if it made sense to do so on that implementation.
> > Now you tell us exactly what you mean by an escape (\e).
>
> I didn't claim to have a meaning in mind for \e. I'm just disputing
> the claim that \v is better defined in the standard than \e could be,
> or that \v belongs in the standard more than \e.
Yep. Again, from the Rationale:
5.2.2 Character display semantics
...
Proposals to add '\e' for ASCII ESC ('\033') were not adopted
because other popular character sets have no obvious equivalent
(see §6.4.4.4).
6.4.4.4 Character constants
...
The C89 Committee considered proposals to add the character
constant '\e' to represent the ASCII ESC ('\033') character. This
proposal was based upon the use of ESC as the initial character
of most control sequences in common terminal driving disciplines
such as ANSI X3.64. However, this usage has no obvious counterpart
in other popular character codes such as EBCDIC.
Which is a lie - EBCDIC damn well does contain every single control
character from ASCII, including ESC (0x27). This comment also
implies, incorrectly, that "other popular character sets" all contain
a \v character.
-- David R. Tribble, da...@tribble.com --
Hyman Rosen
> I said nothing about '\v'. I asked how you would apply your definition
> of '\e' in a particular case. Since you decline to answer, I assume that
> my interpretation is correct.
Actually, no one seems to have been looking at the C++ Standard!
In 2.13.2 ¶3 it says "Certain nongraphic characters ... can be
represented according to Table 5." Table 5 looks like this for
the special characters:
new-line NL(LF) \n
horizontal tab HT \t
vertical tab VT \v
backspace BS \b
carriage return CR \r
form feed FF \f
alert BEL \a
That's all that the Standard says about them. Therefore, the proper
definition of \e in the Standard would be to add this line to Table 5:
escape ESC \e
In addition, 2.2 ¶3 would need to have "escape" added to the list of
control characters present in the execution character sets. Since
many people claim to find this useful, and its only effect is to
make a currently undefined usage defined, I see no reason not to add
it.
---
Paul D. DeRocco
"Clive D.W. Feather" wrote:
>
> Yes. In a codeset using the shift-out and shift-in concept for switching
> between character sets, there are two different codes (14 and 15 in
> ASCII) with that meaning.
>
> On a BBC micro - an ASCII based system - there are six or seven codes
> that have that meaning [*]. Curiously 27 isn't one of them.
>
> [*] Plus, in some screen modes, another 25 or so.
Why are we making this so difficult? In ASCII there is an ESC character. In
EBCDIC there is an ESC character. I don't believe there are any other
execution character sets, for which anyone will actually write a C++
compiler, that don't have an ESC character. If I'm wrong about this, then
I'd be surprised if this character set I'm as yet unaware of didn't also
have analogous problems with other missing control characters that are
already mentioned in the C++ standard.
Refusing to include \e for ESC seems to me to sacrifice a simple
enhancement that would be useful to many programmers in the real
world--I've got modules in production code that have literally hundreds of
instances of \x1B in strings--in deference to some obscure theoretical
possibility that will never occur, and that even if it did, could be
handled with a simple error message.
One might call this "standards puritanism".
--
Ciao, Paul D. DeRocco
Paul mailto:pder...@ix.netcom.com
Paul D. DeRocco
Pete Becker wrote:
>
> Kai Henningsen wrote:
> >
> > interpretation for one or more following characters.
> >
>
> not be conforming, because the letter a isn't a different interpretation
> of the character constant 'a'.
No less conforming than an implementation in which printf("\a") fails to
make a sound. The standard says \a is an alert character, and merely
requires that the execution character set include some such character, even
if a particular environment doesn't do anything with it.
Greg Brewer
news:4$KoHGFxq...@romana.davros.org...
> Firstly, that might not be an ideal point to rotate. Secondly, it's not
> always the current year that matters, but rather some reference year
> based on the data. So both given_year and current_year, and for that
> matter current_century, would have to be parameters of the function, and
> the 50, 33, and 66 ought to be as well.
>
> So we now have a function which can be written in portable code in about
> 10% of the space required to actually describe it fully. Not a good
> candidate for standardisation.
Well, you threw away everything I wanted to standardize then tell me that it
is a bad candidate for standardization. I agree that in all situations, the
operational values I set forth are undesirable. I even grant that the 50,
33, and 66 values may not be good values to use in most cases. My point was
that there are values that should work in most values and I think it would
be good to have a standard function that returns a year. I think that a
standard function would result in the uniform operation of everyone's code.
If the standard does not meet an individual need then don't use the standard
function; write your own. Its similar to sorting, if qsort meets your
requirements, use it if not, well ...
Allowing parameters as you describe negates the whole purpose. I do concede
one point. It occurs to me that if you are entering a value in a calendar
program then converting a 2 digit year to a 4 digit year using a +/- 50 year
range centering on the current year makes sense. However if you a looking
for historical data, then a 100 range ending with the current year makes
more sense. If its 2040 and you are looking for a piece of data from 68 you
sure don't mean 2068!
Greg Brewer
---
Nick Maclaren
David R Tribble <da...@tribble.com> wrote:
>
>Paul Jarc wrote:
>>
>> John Hauser <jha...@cs.berkeley.edu> writes:
>> > Paul Jarc:
>> > > You tell me exactly what you mean by a vertical tab.
>> >
>> > It's like a horizontal tab (\t), only in the vertical direction. It
>> > introduces some implementation-defined amount of vertical whitespace
>> > (possibly none). The safest use would presumably always follow
>> > '\n', as in "First line.\n\vSecond line.\n".
>>
>> But all that is intent only. AFAICT, the standard mandates nothing
>> with regard to what happens when \v is output.
>
> cannot properly effect vertical tabs (for instance), the Standard
> emphasizes that the semantics merely describe intent.
>
>Which means that an implementation could very well simply ignore
>'\v' characters, if it made sense to do so on that implementation.
Yes, and many do. However, one point that is often missed is that
vertical tab and form feed are defined by ASCII to be analogues of
line feed - i.e. the line terminators are 'CR-LF', 'CR-VT' or 'CR-FF'.
It has a special kludge that says LF may be treated as NL (i.e. a
'CR-LF' composite character), but has no such kludge for the others.
This (and the abominable treatment of tab as a data character) makes
it very difficult to interpret the C standard in a strict ASCII
context. Not that there are many left, of course.
>> > Now you tell us exactly what you mean by an escape (\e).
>>
>> I didn't claim to have a meaning in mind for \e. I'm just disputing
>> the claim that \v is better defined in the standard than \e could be,
>> or that \v belongs in the standard more than \e.
>
> The C89 Committee considered proposals to add the character
> constant '\e' to represent the ASCII ESC ('\033') character. This
> proposal was based upon the use of ESC as the initial character
> of most control sequences in common terminal driving disciplines
> such as ANSI X3.64. However, this usage has no obvious counterpart
> in other popular character codes such as EBCDIC.
>
>Which is a lie - EBCDIC damn well does contain every single control
>character from ASCII, including ESC (0x27). This comment also
>implies, incorrectly, that "other popular character sets" all contain
>a \v character.
That is correct. I made that comment on C89, and again on C9X. In
the latest draft, the C9X rationale has been fixed to remove the
reference to EBCDIC.
The obvious specification of '\e', which is PRECISELY what the ASCII
standard says, is that it has an implementation-defined effect.
I still can't see why people object to that so fiercely.
Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QG, England.
Email: nm...@cam.ac.uk
Tel.: +44 1223 334761 Fax: +44 1223 334679
Al Stevens
>Complete the following
>paragraph (paraphrased from the C standard):
>
>'\a' produces an audible or visible alert. '\b' moves the active
>position to the previous position on the current line. '\f' moves hte
>active position to the initial position at the start of the next logical
>page. '\n' moves the active position to the initial position of the next
>line. '\r' moves the active position to the initial position of the
>current line. '\t' moves the active position to the next horizontal
>tabulation position on the current line. '\v' moves the active positon
>to the initial position of the next vertical tabulation position. '\e'
>.....
....introduces a sequence of characters to be interpreted (in any
herein-undefined manner) by the printer/plotter/display device or by the
protocol language that serves as a device-independent layer between the
program and the device.
Pete Becker
>
> Pete Becker <peteb...@acm.org> writes:
> > I said nothing about '\v'. I asked how you would apply your definition
> > of '\e' in a particular case. Since you decline to answer, I assume that
> > my interpretation is correct.
>
> Actually, no one seems to have been looking at the C++ Standard!
> In 2.13.2 ¶3 it says "Certain nongraphic characters ... can be
> represented according to Table 5." Table 5 looks like this for
> the special characters:
>
> new-line NL(LF) \n
> horizontal tab HT \t
> vertical tab VT \v
> backspace BS \b
> carriage return CR \r
> form feed FF \f
> alert BEL \a
>
> That's all that the Standard says about them. Therefore, the proper
> definition of \e in the Standard would be to add this line to Table 5:
>
> escape ESC \e
I've been reading the C standard. Too bad the C++ standard screwed it
up. <g> So what do you take this to mean if the platform's character set
does not define NL, HT, VT, etc.?
>
> In addition, 2.2 ¶3 would need to have "escape" added to the list of
> control characters present in the execution character sets. Since
> many people claim to find this useful, and its only effect is to
> make a currently undefined usage defined, I see no reason not to add
> it.
Defined as what? That is, what should the implementation do if there is
no character whose name is ESC?
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
Chris Dollin
>
> Kai Henningsen wrote:
> >
> > \e (escape) The codeset escape function. Invokes a different
> > interpretation for one or more following characters.
> >
>
> So an implementation in which printf("\ea") displayed the letter a would
> not be conforming, because the letter a isn't a different interpretation
> of the character constant 'a'.
An interpretation is a mapping, not the result of the mapping on
a single character.
So if_"\ea" meant the same as "a" that could be because \e had
introduced an interpreation in which the sequence
\e(Annie Haslem Is A Goddess)
was translated to a GIF of said singer (and no other sequences
had non-trivial translations.
[Hemihydrated seriousness. Just add alcohol.]
--
Chris "at the Royal Albert Hall" Dollin
Pete Becker
>
> Pete Becker wrote in message <37DE5025...@acm.org>...
> >Complete the following
> >paragraph (paraphrased from the C standard):
> >
> >'\a' produces an audible or visible alert. '\b' moves the active
> >active position to the initial position at the start of the next logical
> >page. '\n' moves the active position to the initial position of the next
> >line. '\r' moves the active position to the initial position of the
> >current line. '\t' moves the active position to the next horizontal
> >tabulation position on the current line. '\v' moves the active positon
> >to the initial position of the next vertical tabulation position. '\e'
> >.....
>
> ....introduces a sequence of characters to be interpreted (in any
> herein-undefined manner) by the printer/plotter/display device or by the
> protocol language that serves as a device-independent layer between the
> program and the device.
Suppose I'm implementing the standard library on a system whose display
device is mapped to an 80x25 array of 16-bit storage cells that hold
character codes and color codes. I know how to write the code that deals
with \a, \t, \r, \v, etc. What code does this definition (or any other
proposed definition) require me to write to handle \e?
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
Adam Spragg
Hyman Rosen wrote:
>
> Pete Becker <peteb...@acm.org> writes:
> > I said nothing about '\v'. I asked how you would apply your definition
> > of '\e' in a particular case. Since you decline to answer, I assume that
> > my interpretation is correct.
>
> Actually, no one seems to have been looking at the C++ Standard!
> In 2.13.2�3 it says "Certain nongraphic characters ... can be
> represented according to Table 5." Table 5 looks like this for
> the special characters:
>
> new-line NL(LF) \n
> horizontal tab HT \t
> vertical tab VT \v
> backspace BS \b
> carriage return CR \r
> form feed FF \f
> alert BEL \a
>
> That's all that the Standard says about them. Therefore, the proper
> definition of \e in the Standard would be to add this line to Table 5:
>
> escape ESC \e
>
> control characters present in the execution character sets. Since
> many people claim to find this useful, and its only effect is to
> make a currently undefined usage defined, I see no reason not to add
> it.
One post I noticed mentioned a point as if in passing that I feel is
quite relevant - the '\e' escape character does nothing by itself. It's
purpose is to alter the meaning of at least one other character in the
output sequence. However, the number of characters it alters is totally
device-dependent, and escape-sequence dependent.
For any other 'special character' (I wanted to say escape sequence
there, but realised it could be confusing :), say '\t', If I code the
following :
printf("This is a\ttest");
Then I know that the characters "This is a" will be output, then a tab
character (whatever it does) and then 't', 'e', 's', 't'. This can be
said for any of the current special characters.
'\e' would be fundamentally different in this way, because :
printf("This is an \eescape sequence");
will output "This is an ", followed by the escape sequence, which does
nothing, followed by absolutely anything, which could change according
to the output device. Which C doesn't really have a concept of.
\ee on one device could be a control code that means 'print all the
follwing characters in upper case, giving me 'SCAPE SEQUENCE' on the end
of my output. The same program on the same computer sending output to a
different device could well interpret this as "'\ees' - equivalent to
form feed."
This sort of thing not only possibly changes the nature of all following
output, but alters how much you actually get as well.
It just doesn't really seem to fit in the 'C' language to me.
Adam
--
Why is it that the smaller and easier a bug is to fix, the less I want
to actually fix it?
----------------
The opinions expressed in this email are mine alone, and do not
neccesarily represent those of my employer, my parents, or the people
who wrote the email software I use.
Pete Becker
Al Stevens wrote:
>
> Pete Becker wrote in message <37DE5025...@acm.org>...
> >Complete the following
> >paragraph (paraphrased from the C standard):
> >
> >'\a' produces an audible or visible alert. '\b' moves the active
> >active position to the initial position at the start of the next logical
> >page. '\n' moves the active position to the initial position of the next
> >line. '\r' moves the active position to the initial position of the
> >current line. '\t' moves the active position to the next horizontal
> >tabulation position on the current line. '\v' moves the active positon
> >to the initial position of the next vertical tabulation position. '\e'
> >.....
>
> ....introduces a sequence of characters to be interpreted (in any
> herein-undefined manner) by the printer/plotter/display device or by the
> protocol language that serves as a device-independent layer between the
> program and the device.
Under the C standard, the effect of writing '\e' in a character string
is undefined. Under this definition it produces undefined results if
it's sent to a display device. I don't think that's much of an
improvement. In either case, if your vendor tells you what '\e' does on
their system you can use it, and if they don't, you can't.
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
Pete Becker
"Paul D. DeRocco" wrote:
>
> Pete Becker wrote:
> >
> > Kai Henningsen wrote:
> > >
> > > \e (escape) The codeset escape function. Invokes a different
> > > interpretation for one or more following characters.
> > >
> >
> > So an implementation in which printf("\ea") displayed the letter a would
> > not be conforming, because the letter a isn't a different interpretation
> > of the character constant 'a'.
>
> make a sound. The standard says \a is an alert character, and merely
> requires that the execution character set include some such character, even
> if a particular environment doesn't do anything with it.
No, because the standard permits '\a' to do nothing when the display
device does not support it. There is no such permission in the proposed
"definition" of the effect of '\e': It says that the interpretation is
different. If you would like to propose different words, please do so.
Pete Becker
Nick Maclaren wrote:
>
> In article <37DFC7F4...@tribble.com>,
> David R Tribble <da...@tribble.com> wrote:
> >
> >Which is a lie - EBCDIC damn well does contain every single control
> >character from ASCII, including ESC (0x27). This comment also
> >implies, incorrectly, that "other popular character sets" all contain
> >a \v character.
>
> That is correct.
Well, no. It's not a lie, it's a misstatement. A lie is a misstatement
that is made with the intention of deceiving someone.
Hyman Rosen
Pete Becker <peteb...@acm.org> writes:
> I've been reading the C standard. Too bad the C++ standard screwed it
> up. <g> So what do you take this to mean if the platform's character set
> does not define NL, HT, VT, etc.?
I don't take it to mean anything. Presumably the implementation on such
a platform would ascribe some meaning to them.
> Defined as what? That is, what should the implementation do if there is
> no character whose name is ESC?
The same thing it does when there is no character whose name is BEL :-)
Since the Standard didn't see fit to further specify the behavior, I
don't either. At worst, the implementation would just assign \e to be
some arbitrary control character, or a printing character outside of
the usual 96.
Pete Becker
Hyman Rosen wrote:
>
> Pete Becker <peteb...@acm.org> writes:
> > I've been reading the C standard. Too bad the C++ standard screwed it
> > up. <g> So what do you take this to mean if the platform's character set
> > does not define NL, HT, VT, etc.?
>
> I don't take it to mean anything. Presumably the implementation on such
> a platform would ascribe some meaning to them.
Well, you can't say both that it doesn't mean anything and that the
implementation is free to do whatever it wants. Either it's
implementation-specific or it isn't. Choose one. <g>
>
> > Defined as what? That is, what should the implementation do if there is
> > no character whose name is ESC?
>
> The same thing it does when there is no character whose name is BEL :-)
The C standard says: "\a (alert) Produces an audible or visual alert."
> Since the Standard didn't see fit to further specify the behavior, I
> don't either. At worst, the implementation would just assign \e to be
> some arbitrary control character, or a printing character outside of
> the usual 96.
>
So you'd find it acceptable for \e to be mapped, for example, to \a, and
produce an alert, and then to display the rest of the escape sequence as
ordinary characters?
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
Al Stevens
>Under the C standard, the effect of writing '\e' in a character string
>is undefined. Under this definition it produces undefined results if
>it's sent to a display device. I don't think that's much of an
>improvement. In either case, if your vendor tells you what '\e' does on
>their system you can use it, and if they don't, you can't.
Pete, you're losing me here. Under the C and C++ standards the definitions
of *all* the \x characters produce undefined results if they are sent to a
display device. Nowhere (that I've found) does the standard say what effect
\v or any of the others has when sent to a display device. The standard kind
of says what effect they have when you code them in a string or character
literal but not completely because the standard cannot specify the value of
the resulting character without tying them to specific character sets. It
uses conventional names such as BEL, HT, and FF, but it assigns no values or
behavior to them other than to say "alert," "backspace," etc. Those are only
names; they do not specify behavior. The standard says things about how
std::endl inserts a newline into the stream, for example, but it says
nothing (that I have found) about what effect the newline has on the
display. I fail to see what there is about \e that would be any different.
Could you point me to those places I overlooked where that behavior is
specified?
Pete Becker
Al Stevens wrote:
>
> >Under the C standard, the effect of writing '\e' in a character string
> >is undefined. Under this definition it produces undefined results if
> >it's sent to a display device. I don't think that's much of an
> >improvement. In either case, if your vendor tells you what '\e' does on
> >their system you can use it, and if they don't, you can't.
>
> Pete, you're losing me here. Under the C and C++ standards the definitions
> of *all* the \x characters produce undefined results if they are sent to a
> display device. Nowhere (that I've found) does the standard say what effect
> \v or any of the others has when sent to a display device. The standard kind
> of says what effect they have when you code them in a string or character
> literal but not completely because the standard cannot specify the value of
> the resulting character without tying them to specific character sets. It
> uses conventional names such as BEL, HT, and FF, but it assigns no values or
> behavior to them other than to say "alert," "backspace," etc. Those are only
> names; they do not specify behavior. The standard says things about how
> std::endl inserts a newline into the stream, for example, but it says
> nothing (that I have found) about what effect the newline has on the
> display. I fail to see what there is about \e that would be any different.
> Could you point me to those places I overlooked where that behavior is
> specified?
From the ANSI C standard, cl. 2.2.2:
\a (alert) Produces an audible or visible alert. The active position shall
not be changed.
\b (backspace) Moves the active position to the previous position on the
current line. If the active position is at the initial position of
a line, the behavior is unspecified.
....
--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.com
Paul Jarc
> Al Stevens wrote:
> > [\e] introduces a sequence of characters to be interpreted (in any
> > herein-undefined manner) by the printer/plotter/display device or by the
> > protocol language that serves as a device-independent layer between the
> > program and the device.
>
> etc. What code does this definition (or any other proposed
> definition) require me to write to handle \e?
You handle \e however you like, the same as for the others. You
aren't *required* to do anything in particular with the others, so why
do you expect a requirement for \e?
paul
---
Al Stevens
>> herein-undefined manner) by the printer/plotter/display device or by the
>> protocol language that serves as a device-independent layer between the
>> program and the device.
>
>device is mapped to an 80x25 array of 16-bit storage cells that hold
>with \a, \t, \r, \v, etc. What code does this definition (or any other
>proposed definition) require me to write to handle \e?
Anything or nothing. Same as for the others. You "know how to write the
code" only because you know by convention and tradition what those
characters mean, but not because the standard specifies their behavior when
sent to a display device.
For example, where does the standard require you to provide any specific
behavior for /v other than to treat it as white space? Interestingly,
2.13.2/3 says, "If the character following a backslash is not one of those
specified, the behavior is undefined," then it neglects to define the kind
of behavior we're discussing for the ones it specifies except to say that
they cause some undefined character value to occur in character and string
literals. At least that's what a search on \v and "vertical tab" reveals
except to include \v as one of the whitespace characters in preprocessor
directives. So \v behavior is defined when \v appears in source code but not
when sent to a display device.
Not that there's anything wrong with that, but it fails to make the case for
or against including \e as part of the formal language definition. Inclusion
of the others is the legacy of tradition. The omission of \e was a
deficiency in that tradition, IMHO, and occurred probably because whatever
terminal was on the PDP-11 (Decwriter?) at the time C was developed made no
use of the ESC character (he said, ducking).
Larry Jones
> The C89 Committee considered proposals to add the character
> constant '\e' to represent the ASCII ESC ('\033') character. This
> proposal was based upon the use of ESC as the initial character
> of most control sequences in common terminal driving disciplines
> such as ANSI X3.64. However, this usage has no obvious counterpart
> in other popular character codes such as EBCDIC.
>
> character from ASCII, including ESC (0x27). This comment also
> implies, incorrectly, that "other popular character sets" all contain
> a \v character.
I raised the same objection. The response was that it didn't say that
the *character* has no obvious counterpart, but rather that the *usage*
doesn't. That is, no one uses escape sequences in an EBCDIC
environment, they use channel control programs and other esoterica
instead. While this still isn't strictly true, it comes much closer.
(I still don't think it's a particularly good reason for rejecting the
proposal, but the rules of the game are that the committee needs a good
reason for accepting something, not for rejecting it.)
-Larry Jones
When you're SERIOUS about having fun, it's not much fun at all! -- Calvin
Hyman Rosen
> So you'd find it acceptable for \e to be mapped, for example, to \a, and
> produce an alert, and then to display the rest of the escape sequence as
> ordinary characters?
I would rather that \e was not equal to any other \c (single letter)
value. I would definitely find it acceptable for the remainder of
the characters to be displayed normally. Remember that in the vast
majority of implementations (perhaps even all of them), the special
characters are simply output through low level calls without any
special handling whatsoever. Even in MS environments where \n turns
into two characters on certain output streams, that translation is
handled transparently by low level read and write calls which the
C and C++ runtime uses.
Al Stevens
>> [erroneous drivel snipped ]
Please ignore my previous posts on this thread. I found what Pete was
referring to in the C standard, a document that I tend to neglect because it
is a paper copy that I can't search in lazy mode.
Greg Brewer
news:7rrdt2$9...@nfs0.sdrc.com...
> environment, they use channel control programs and other esoterica
> instead. While this still isn't strictly true, it comes much closer.
I did. I used to have to send control sequences to laser printers hooked up
with a protocol converter. The \e sequence would not have helped me though;
I was using REXX.
Greg Brewer
Christopher Eltschka
Greg Brewer wrote:
[...]
> Allowing parameters as you describe negates the whole purpose. I do concede
> one point. It occurs to me that if you are entering a value in a calendar
> program then converting a 2 digit year to a 4 digit year using a +/- 50 year
> range centering on the current year makes sense. However if you a looking
> for historical data, then a 100 range ending with the current year makes
> more sense. If its 2040 and you are looking for a piece of data from 68 you
> sure don't mean 2068!
Maybe the following interface would make sense:
enum date_range { past_date=-1, nearest_date, future_date };
int get_full_year(int year, date_range range = nearest_date);
Brian B. McGuinness
"Paul D. DeRocco" wrote:
> Why are we making this so difficult? In ASCII there is an ESC character. In
> EBCDIC there is an ESC character. I don't believe there are any other
> execution character sets, for which anyone will actually write a C++
> compiler, that don't have an ESC character. If I'm wrong about this, then
> I'd be surprised if this character set I'm as yet unaware of didn't also
> have analogous problems with other missing control characters that are
> already mentioned in the C++ standard.
So the simplest solution would be to define '\e' as the ESC character and
not worry about what its effect might be on any specific device; let the
device driver's designer worry about that.
For clarity, we could specify:
In ASCII, '\e' = '\x1B'
In EBCDIC, '\e' = '\x27'
... (mention any other cases here) ...
In other codesets the meaning of '\e' is implementation-dependent.
This should be simple enough for any compiler writer to implement and
would cause '\e' to have the effect that most people would expect.
--- Brian
Christopher Eltschka
John Hauser wrote:
>
> Paul Jarc:
> > You tell me exactly what you mean by a vertical tab.
>
> It's like a horizontal tab (\t), only in the vertical direction. It
> introduces some implementation-defined amount of vertical whitespace
> (possibly none). The safest use would presumably always follow '\n',
> as in "First line.\n\vSecond line.\n".
>
\e means that the implementation may interpret an implementation
defined (not necessarily fixed) number of following characters
in an implementation defined way on output.
It makes sense to put restrictions on some of the standard
streambufs (f.ex. that stringstreambuf may _not_ interpret
them) and corresponding stdio functions (like sprintf).
Usually the interpretation will be done by the external device
(terminal/terminal emulator, printer), but it may be done by
the I/O library itself (f.ex., a C++ compiler could decide to
emulate VT100 on non-VT100 devices).
Paul Jarc
> > specified?
>
> From the ANSI C standard, cl. 2.2.2:
>
> \a (alert) Produces an audible or visible alert. The active position shall
> not be changed.
>
> \b (backspace) Moves the active position to the previous position on the
> current line. If the active position is at the initial position of
> a line, the behavior is unspecified.
> ....
But the beginning of that paragraph, which you have consistently
ignored, says (in C9X 5.2.2p2):
# Alphabetic escape sequences representing nongraphic characters in
# the execution character set are intended to produce actions on
# display devices as follows:
What you quoted does *not* define how these escape sequences are
handled. It specifies intent only.
paul
Clive D.W. Feather
In article <7roqa9$a8i$1...@news.hal-pc.org>, Greg Brewer
<nospa...@brewer.net> writes
>> So we now have a function which can be written in portable code in about
>> 10% of the space required to actually describe it fully. Not a good
>> candidate for standardisation.
>
>Well, you threw away everything I wanted to standardize then tell me that it
>is a bad candidate for standardization.
Exactly.
>I even grant that the 50,
>33, and 66 values may not be good values to use in most cases.
Okay, so they need parameterising. You've just admitted that your
function isn't any use in most cases.
>I think that a
>standard function would result in the uniform operation of everyone's code.
>If the standard does not meet an individual need then don't use the standard
>function; write your own.
This is an area where it is really bad to have "uniform operation". The
problem of handling 2 digit dates is one that programmers have to
*think* about, not just pick a quick answer off the shelf. So they
should at the very least be thinking about the boundaries for switching,
not just saying "50, 33, and 66" for everything.
>It occurs to me that if you are entering a value in a calendar
>program then converting a 2 digit year to a 4 digit year using a +/- 50 year
>range centering on the current year makes sense.
I disagree. If I'm entering something into *my* calendar, I won't be
interested in dates before I was born. I probably won't be interested in
dates before last year.
And this is the whole point - *every* use of dates has to be thought
about, and there is no one right solution.
--
Clive D.W. Feather | Internet Expert | Work: <cl...@demon.net>
Tel: +44 20 8371 1138 | Demon Internet Ltd. | Home: <cl...@davros.org>
Fax: +44 20 8371 1037 | | Web: <http://www.davros.org>
Written on my laptop; please observe the Reply-To address
Clive D.W. Feather
In article <37E004CE...@ix.netcom.com>, Paul D. DeRocco
<pder...@ix.netcom.com> writes
>> Yes. In a codeset using the shift-out and shift-in concept for switching
>> between character sets, there are two different codes (14 and 15 in
>> ASCII) with that meaning.
>>
>> On a BBC micro - an ASCII based system - there are six or seven codes
>> that have that meaning [*]. Curiously 27 isn't one of them.
>>
>> [*] Plus, in some screen modes, another 25 or so.
>
>Why are we making this so difficult? In ASCII there is an ESC character. In
>EBCDIC there is an ESC character. I don't believe there are any other
>execution character sets, for which anyone will actually write a C++
>compiler, that don't have an ESC character.
I've programmed in C for a BBC micro based system. It doesn't have an
ESC character.
> If I'm wrong about this, then
>I'd be surprised if this character set I'm as yet unaware of didn't also
>have analogous problems with other missing control characters that are
>already mentioned in the C++ standard.
It had alert, carriage return, newline, and backspace. Tabs - both
horizontal and vertical - were at every character position, but it
distinguished between space (overwrites) and tab (doesn't).
>I've got modules in production code that have literally hundreds of
>instances of \x1B in strings
What's wrong with:
#define ESC "\x1B"
for ASCII, if that's what you're on ?
Kai Henningsen
peteb...@acm.org (Pete Becker) wrote on 16.09.99 in <37E0F7C9...@acm.org>:
> Al Stevens wrote:
> >
> > Pete Becker wrote in message <37DE5025...@acm.org>...
> > >Complete the following
> > >paragraph (paraphrased from the C standard):
> > >
> > >'\a' produces an audible or visible alert. '\b' moves the active
> > >position to the previous position on the current line. '\f' moves the
> > >active position to the initial position at the start of the next logical
> > >page. '\n' moves the active position to the initial position of the next
> > >line. '\r' moves the active position to the initial position of the
> > >current line. '\t' moves the active position to the next horizontal
> > >tabulation position on the current line. '\v' moves the active positon
> > >to the initial position of the next vertical tabulation position. '\e'
> > >.....
> >
> > ....introduces a sequence of characters to be interpreted (in any
> > herein-undefined manner) by the printer/plotter/display device or by the
> > protocol language that serves as a device-independent layer between the
> > program and the device.
>
> Suppose I'm implementing the standard library on a system whose display
> device is mapped to an 80x25 array of 16-bit storage cells that hold
> character codes and color codes. I know how to write the code that deals
> with \a, \t, \r, \v, etc. What code does this definition (or any other
> proposed definition) require me to write to handle \e?
You know that?
What do you do for \a?
What do you do for \t?
What do you do for \v?
How do you now these things?
And why don't you know what to do for \e the exact same way you know this
other stuff?
Kai
--
http://www.westfalen.de/private/khms/
"... by God I *KNOW* what this network is for, and you can't have it."
- Russ Allbery (r...@stanford.edu)