osd7@homxa.UUCP (Orlando Sotomayor-Diaz) (02/21/85)
mod.std.c Digest Thu, 21 Feb 85 Volume 3 : Issue 6
Today's Topics:
\e in strings for escape
preprocessor comments
----------------------------------------------------------------------
Date: Wed, 20 Feb 85 23:31:56 est
From: cbosgd!mark (Mark Horton)
Subject: \e in strings for escape
To: std-c@cbosgd.uucp
I'd like to provide a little background on \e.
Long ago, termcap had \E for escape. Bill Joy put it in, presumably
he used the capital letter because it was different from the C language.
Termcap also had the usual \r, \n, etc. The character was used
VERY HEAVILY in termcap - it was by far the most popular character.
In terminfo, I kept \E for compatibility, but I also included \e
as a synonym for escape, thinking it more consistent with the rest
of the characters. In practice, \E has remained the most heavily
used notation, mostly because \e wasn't well publicized and I forgot
about it.
I also added \l for linefeed. I realize that \n usually maps into
linefeed anyway, but the purpose of these symbols is to make programs
more portable. There are some operating systems where \n is represented
by a character other than \012, and there are plenty of operating
systems where lines in files are terminated with CRLF. There are also
many terminals where one sends CRLF at the end of each line (in fact,
most terminals are run in this mode.) Sometimes, code appears in C
programs that looks like
fprintf(file, "message\r\n");
where the file is a network descriptor or something else that requires
a CRLF. Such programs would be more portable if they read
fprintf(file, "message\r\l");
if \l were universal. In my opinion, an implementation ought to be
able to map \n onto an obscure control character, and use \012 for
a regular linefeed.
So I am in favor of adding both \e for ASCII ESC, and \l for ASCII LF,
to the C standard.
Mark Horton
[ Some questions:
\e - what happens on non-ASCII environment, or what should happen?
\n - the 11/12/84 draft says: "(new-line) Moves the printing position
to the leftmost printing position of the line immediately below
the current line." If this were the case, then \r\n wouldn't
be necessary. Also, \n looks like the combination \r\l,
but \l by itself is not defined in the draft.
-- Mod --
]
------------------------------
Date: Mon, 18 Feb 85 23:35:57 est
From: cbosgd!decvax!minow
Subject: preprocessor comments
To: cbosgd!std-c
Some (top of head) preprocessor comments.
First, there are a few trivial bugs. For example, the current draft
(84-161, Nov. 12, 1984) has two flavors of whitespace (VT and FF are
slightly different from SP and HT) [p. 59]. Also, on the same page,
there is a unnecessary restriction in the syntax of #include <s-char-seq>
(may not contain a > character).
I believe there is an error in the definition of preprocessor directives.
The general syntax is
# command arguments new-line
It appears that whitespace is not allowed between the arguments and
the newline. This means that
#if TRUE /* Always do this */
...
#else /* Never compiled */
...
is an error.
Several recent messages in mod.std-c have referenced Decus C.
The built-in Decus C preprocessor doesn't do #define macro(arg)
at all (it follows pure V6 syntax).
The Decus cpp I posted recently can be made to do all sorts of
un-standard things -- the standard kept changing, and the people
using field-test versions had to deal with existing (buggy) code,
so I implemented most of the Reiser extensions. (They can be
disabled when cpp is compiled.)
Readers concerned with C standardization should be aware that
Decus cpp is intended to be a laboratory for reviewers and
implementors. Although I assume that the program is well written,
it was not designed with real-world production considerations
(space/time/etc.) in mind.
Martin Minow
decvax!minow
------------------------------
End of mod.std.c Digest - Thu, 21 Feb 85 07:06:00 EST
******************************
USENET -> posting only through cbosgd!std-c.
ARPA -> replies to cbosgd!std-c@BERKELEY.ARPA (NOT to INFO-C)
In all cases, you may also reply to the author(s) above.