osd7@homxa.UUCP (Orlando Sotomayor-Diaz) (03/02/85)
From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>
mod.std.c Digest Fri, 1 Mar 85 Volume 4 : Issue 1
Today's Topics:
\e, \l ASCII, and non-standard braindamage
a note about \e & \l
case >20:
----------------------------------------------------------------------
Date: 1 Mar 85 14:22:57 EST
From: John McNamee <ucbvax!jpm@BNL.ARPA>
Subject: \e, \l ASCII, and non-standard braindamage
To: cbosgd!std-c@BERKELEY
I have never understood why all the fuss over making C work on non-ASCII
machines. ASCII is *THE* standard for character data. If some vendors think
they have a better idea, and implement it on their hardware, they end up
with NON-STANDARD hardware. Why should C go out of its way to support such
braindamage at the expense of making life easier on the vast majority (who
are on ASCII machines)? \e and \l are good ideas and will be of use to the
majority of users. Compilers on non-ASCII machines can try to represent them
as best as they can given the host character set, or give an error.
Using octal constants is the alternative to using \e and \l, and such
constants are 100% non-portable to non-ASCII machines. At least with \e and
\l the compiler gets a chance to map into something reasonable in the host
character set or give you an error if it cant. Using octal escapes will
compile just fine and then not work at runtime. If I had to use a machine
with a non-ASCII character set, I'd rather have the compiler tell me that
some program isn't going to work then finding out the hard way.
--
John McNamee jpm@BNL.{ARPA,UUCP,BITNET}
------------------------------
Date: Wed, 27 Feb 85 21:57:12-0008
From: ihnp4!seismo!mcvax!ukc!qtlon!flame!ubu!snow!req
Subject: a note about \e & \l
To: ihnp4!houxm!homxa!
We can note that the existing C escapes each relate to a specific function:
\r - return the 'carriage'
\n - newline & return
\f - top of a new page or form
\t - move to next horizontal tab pos
\b - move back one space
\l - move down one line [ proposed ]
It seems to me that \e doesn't fall into such a neat category. It usually means
something like 'next few characters are special'.
In Emacs & 1 or 2 other places, it represents ASCII ESC.
In troff, it represents the current escape character (default in troff is \).
Where the latter is defined, this seems very reasonable. But what is the
meaning of \e from the output of an otherwise device-independent program?
It is NOT a device independent character or character sequence, and to have it
handled in the same way as \r and \t seems to me to be a bad thing, as it makes
a very non-portable construction appear superficially to be general &
predictable. Programs that use \e must know what device they're talking to!
There is a stronger case for \l, and I'd certainly like the facility. But I
can't help wondering about enter_standout_mode, delete_to_end_of_line, and all
of the other facilities provided by termcap/terminfo.
All of the existing escapes -- except possibly
\v - move to next vertical tab pos [ not in all compilers ] -- are interpreted
by the "standard" UN*X tty drivers so you can use /usr/bin/tabs, etc.
Maybe we want a simplified curses/termcap interface for such things, with a
generalized format for escape sequences so a set of postprocessors could be
used, rather like ditroff. But that's a change to UN*X -- or just the addition
of a library -- not a change to C itself.
Russell
------------------------------
Date: 1 Mar 85 11:11:13 CST (Fri)
From: plus5!hokey@cbosgd.ATT.UUCP (Hokey)
Subject: case >20:
To: cbosgd!std-c
Regarding open ended ranges, Craig Partridge asks "How often would this
feature be useful?" To a certain extent, it doesn't matter. There are
times it is the "best" way to handle conditions in a switch.
This is an equivalent case to struct/union initialization by position or
by name. Either would do the job, but there are stylistic considerations.
Both are really needed to "effectively" handle all the cases.
Hokey ..ihnp4!plus5!hokey
314-725-9492
------------------------------
End of mod.std.c Digest - Fri, 1 Mar 85 22:11:47 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.