osd7@homxa.UUCP (Orlando Sotomayor-Diaz) (03/03/85)
From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>
mod.std.c Digest Sun, 3 Mar 85 Volume 4 : Issue 2
Today's Topics:
"string" "concatenation", etc.
'\e', '\l', '\r', '\v'
indexing a character string
New \ escapes
ranges in case labels (2 msgs)
----------------------------------------------------------------------
Date: 2 Mar 85 09:06:38 CST (Sat)
From: ihnp4!utzoo!henry@cbosgd.ATT.UUCP
Subject: "string" "concatenation", etc.
To: ihnp4!cbosgd!std-c
> Is there any particular reason why this should be done by the compiler
> rather than by cpp? It would save adding another legal construct, and
> I can't think of any case where cpp could mis-interpret it.
Cpp is effectively part of the compiler; the separation is a detail of
implementation, not anything fundamental to the language. In fact, many
non-Bell C compilers integrate the preprocessor into the scanner. In
any case, putting the construct into the preprocessor makes no difference
to how it has to be handled in the standard, since the standard necessarily
describes the entire language, preprocessor and all.
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
------------------------------
Date: Sun, 3 Mar 85 5:34:16 EST
From: Doug Gwyn (VLD/VMB) <ucbvax!gwyn@Brl-Vld.ARPA>
Subject: '\e', '\l', '\r', '\v'
To: cbosgd!std-c@BERKELEY
I agree that the ISO character set standard should have been embraced
by the C standard, but the committee discussed the matter and decided
against it (except to the extent that trigraphs have been defined).
Embedding ESC in one's code is almost certainly non-portable anyway,
since there is little agreement on character escape sequences. Even
ANSI terminals support different sets of ESC sequences, and devices
such as line printers will get ESC actions totally wrong. Better to
encourage people to put their device dependencies in separate special
file modules that have to be looked at carefully when a package is
ported. The latest ANSI C proposal contains mechanisms for strings
that let one write ESC as a symbolic preprocessor constant anyway.
Even using ASCII, \l is problematic. On UNIX there is no such thing,
except on terminals in raw mode. Apple IIs do not have \r, instead,
so one might argue that \r should also be outlawed. However, there
is little concern over supporting Apple II native mode, whereas
UNIX definitely must be supported by the standard.
I wish \v would be removed from the standard. It is useless on most
systems, and on those where it has a use, it has implementation-
defined meaning. I think things like \r and \v were left in simply
because some code already legally used them, and the committee did
not want to gratuitously break already-existing carefully written
code. (It is okay to break sloppy garbage, I suppose!)
------------------------------
Date: 2 Mar 85 09:06:46 CST (Sat)
From: ihnp4!utzoo!henry@cbosgd.ATT.UUCP
Subject: indexing a character string
To: ihnp4!cbosgd!std-c
> ... is the following outlawed by the
> C standard (I have to ask since I don't have a copy):
>
> ....
> foo = state(something);
> printf("State is '%c'\n", "?abcd"[foo]);
> ....
This is perfectly legal C, acceptable to all current compilers (that I'm
aware of) and to the current draft standard. Nothing odd about it at all.
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
------------------------------
Date: Sun, 3 Mar 85 01:38 EST
From: Paul Schauble <ucbvax!Schauble@MIT-MULTICS.ARPA>
Subject: New \ escapes
To: cbosgd!std-c@BERKELEY
I find myself divided between two views. On the one hand, ASCII is
becoming sufficiently universal that assuming C uses that character set
may just be a non problem. I don't know of a much used machine that has
C running with another character set. Is there one?
On the other hand, if you want to be universal, perhaps the solution is
to provide a method for the programmer to define the escapes. Something
akin to define "\e" "\033".
Yes, I know that is ugly. Someone suggest another way.
Paul
------------------------------
Date: 2 Mar 85 09:06:54 CST (Sat)
From: ihnp4!utzoo!henry@cbosgd.ATT.UUCP
Subject: ranges in case labels
To: ihnp4!cbosgd!std-c
The people arguing about things like "case >20:" as an extension of
the "case 20..30:" notation may be interested to know that the 11 Feb
draft of the standard does *NOT* include "case 20..30:" as legal C
any more. Evidently the committee had second thoughts about the
gratuitous addition of case ranges, and removed them.
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
------------------------------
Date: Sat, 2 Mar 85 21:17:02 est
From: ihnp4!seismo!hadron!jsdy (Joseph S. D. Yao)
Subject: ranges in case labels
To: ihnp4!homxa!osd7
Cc: seismo!craig@bbn-loki.ARPA
I'd guess that having comparisons in a switch statement would be useful
quite often. This is based on my vague feelings and memory of how often
I have written code that tests the same variable for a number of
different conditions, and out of those, how many could not be done using
the simple equality switch statement. It might also reduce the number
of goto's in code, thus reducing its complexity?
Joe Yao hadron!jsdy@seismo.{ARPA,UUCP}
------------------------------
End of mod.std.c Digest - Sun, 3 Mar 85 10:59:38 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.