osd7@homxa.UUCP (Orlando Sotomayor-Diaz) (02/24/85)
From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>
mod.std.c Digest Sat, 23 Feb 85 Volume 3 : Issue 9
Today's Topics:
About \e and \l
----------------------------------------------------------------------
Date: Sat, Feb 23 85 14:30 EST
From: Larry Rosler <attunix!lr>
Subject: About \e and \l
To: houxm!homxa!osd7
The addition of \e was discussed at length over a year ago. It was
rejected for the very simple reason (expressed in a question by one of
the submitters) that it is not a portable concept, merely a convenience
for expressing the value of a particular ASCII control character in an
*apparently* portable way. This was viewed as being against the intent
of the \ escapes, which is to express portable abstractions of output
control in single-character constructs. A programmer wishing to encode
the ASCII character ESC can write the equivalent of:
#define Esc '\033'
or
#define ESC "\033"
as appropriate. The string literal can be concatenated with other
string literals using the concatenation invention deprecated by one of
the correspondents.
I had not previously seen a proposal for \l to represent "line- feed
without carriage-return". It is certainly a portable concept, though
its mapping into ASCII 012 is not in accordance with the C tradition
(derived from MULTICS originally!) that the latter is NL, not LF. A
different representation might have to be invented, and its value would
not have to be portable. Can anyone suggest such a value? The
committee will have to be persuaded that this particular invention
fills a real need.
Note that it is essential that each \ escape represent exactly one
character in a string, so that characters can be indexed in an array
portably. But the external representation is entirely unspecified --
it is the responsibility of the run-time I/O support to achieve the
required correspondence. This is explicit in the draft, particularly
in the discussion of \n (which may well be represented externally as
ASCII 015 012, or even by the end of a (gasp) record in file systems
that don't conform to the UNIX* model). Portability of external data
is not in the purview of this standard.
Larry Rosler, attunix!lr
[ Chairman of the ANSI X3J11 Language Subcommittee ]
------------------------------
End of mod.std.c Digest - Sat, 23 Feb 85 22:41:02 EST
******************************
USENET -> posting only through cbosgd!std-c.
ARPA -> ... through cbosgd!std-c@BERKELEY.ARPA (NOT to INFO-C)
In all cases, you may also reply to the author(s) above.