osd7@homxa.UUCP (Orlando Sotomayor-Diaz) (02/28/85)
From: Orlando Sotomayor-Diaz (The Moderator) <cbosgd!std-c>
mod.std.c Digest Wed, 27 Feb 85 Volume 3 : Issue 12
Today's Topics:
"string" "concatenation", etc.
'\e'
'\l' and '\e'
case >20:
----------------------------------------------------------------------
Date: Wed, 27 Feb 85 13:39:26 est
From: psuvax1!dae@cbosgd.ATT.UUCP (Dave Eckhardt)
Subject: "string" "concatenation", etc.
To: 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.
Somewhat on the same subject, 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]);
....
No flames on advisability, please--this is C we're talking
about, right?
Third topic: I wouldn't have thought it quite right to
consider a real *addition* to the language, since I thought
that we were *standardizing* it, but after the "case 20..30"
business cropped up, I thought it only fair to throw in my
own favorite addition:
struct foo
{
int freeble;
union
{
int bar;
char cbar;
} /* un_named */ ;
} mumbo;
mumbo.bar = 3;
(I know the spacing may look bad. Try setting your tabs to four spaces
and see what happens then.) It seems to me relatively unambiguous what
I mean here, and it obviates the need for naming the union (which may
really be nothing but an opportunity to save space, and so may not have
a descriptive name), and also the need for more typing, ie,
"mumbo.un_named.bar".
To back up my feeling that there's nothing impossible in implementation,
our (4.2) cc compiles the structure just fine--it just complains about
illegal member usage when I try to use it.
--Daemon
------------------------------
Date: Tue, 26 Feb 85 22:13:56 PST
From: Richard Mathews <ucbvax!lcc.rich-wiz@UCLA-LOCUS.ARPA>
Subject: '\e'
To: cbosgd!std-c@BERKELEY
My first impression of \e was "but what if your character set does not
have an escape character?" It seemed that adding this feature would be a
very bad idea. Then it occurred to me that if \e is not there, everyone
will just go on using \033, which is even more character set dependent.
If C had a \e character, the compiler could generate the most reasonable
thing for your machine. If there is no reasonable thing, it could generate
an error message. Given the choice between \033 and \e, I would strongly
prefer the latter.
Richard M. Mathews
Locus Computing Corporation lcc!richard@ucla-cs
{ucivax,trwrb}!lcc!richard
{ihnp4,randvax,sdcrdcf,ucbvax,trwspp}!ucla-cs!lcc!richard
[ See my comment about this below. -- Mod -- ]
------------------------------
Date: Tue 26 Feb 85 00:50:27-PST
From: Bob Larson <ucbvax!BLARSON%ECLD@ECLA.ARPA>
Subject: '\l' and '\e'
To: cbosgd!std-c@BERKELEY
Both '\l' and '\e' are useful and mainly portable concepts. Os9 C
(microware) already has '\l', and maps both '\n' and '\r' to '\015',
its end of record delimiter.
I agree that most use of '\e' is not extremely portable, however it
does apply to most machines, and does increase readability of code
sufficiently to make it worthwhile. Non-ascii machines should be
allowed (required) to complain when compiling code containing it, but
that code needs modification anyway. (Do you really think that '\033'
is as portable as '\e', given that a #define to ESC is optional?)
Bob Larson <Blarson@Usc-Ecld.Arpa>
-------
[ Comment: It is easier, and sometimes necessary, to write
non-portable code than portable code. However, it is
very desirable to design a portable C standard, no matter
what type of C code one has to write.
-- Mod --
]
------------------------------
Date: 27 Feb 85 09:47:47 EST (Wed)
From: Craig Partridge <ucbvax!craig@loki.ARPA>
Subject: case >20:
To: cbosgd!std-c@BERKELEY
I got caught -- when I raised the objection to case >20:, etc.
I expected to see people sending in code fragments but I didn't expect
anyone to be able to come up with a fragment that showed this feature
was potentially useful and could not be done with default and subranges.
But I'm afraid Kevin Martin's example meets these standards (and my
hat off to him for doing it so cleanly).
I do, however, have one further concern -- and if someone
finds a good answer to this I promise to shut up on this subject.
"How often would this feature be useful?" If we are agreed (are we?) that
it doesn't add new functionality to C, but improves the code for solving
certain classes of problems, how common are the problems to which
"conditional" cases may be applied?
Craig Partridge
craig@bbn-loki (ARPA)
craig%loki@csnet-relay (CSNET)
{ihnp4,wjh12,decvax}!bbncca!craig (USENET)
------------------------------
End of mod.std.c Digest - Wed, 27 Feb 85 23:22: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.