osd7@homxa.UUCP (Orlando Sotomayor-Diaz) (02/15/85)
mod.std.c Digest Fri, 15 Feb 85 Volume 3 : Issue 3
Today's Topics:
Comments on Standard, Section B
Range cases: A suggestion, and a dum-dum.
----------------------------------------------------------------------
Date: Tue, 12 Feb 85 11:10:05 pst
From: cbosgd!ucbvax!ucsfcgl!arnold (Ken Arnold)
Subject: Comments on Standard, Section B
To: cbosgd!std-c@BERKELEY
[The comments here apply to draft X3J11/84-161. -Mod-]
*Problem: Portability/Ambiguity
*Reference: B.2.2.1 Hosted environment (Note) (p. 6)
*Description:
If the host environment cannot supply argument strings with
alphabetic data in both upper- and lower-case, for maximal
portability the implementation should ensure that the argument
strings are received in lower case.
I believe that "should ensure" ought to be "must ensure". "Should" can
imply "it would be nice if", but "must" makes it clearly a
requirement. Somebody, somewhere, will someday misinterpret this, and
then argue they were correct within the scope of the document. (Of
course, if "should" is meant in this way, it is still unclear, since
someone will misinterpret "should" to be "must").
*Problem: Suggested Enhancement
*Reference: B.3.2. Character display semantics (p. 9)
*Description:
As long as were at adding new '\x' characters, let's add a really
useful one: '\e' for ESCAPE ('\033'). I have had to #define ESCAPE for
many, many programs, and have not once had to use '\v' for anything.
If we're adding '\a' (which is reasonable), we might as well add this
useful constant, too.
*Problem: Incomplete
*Reference: B.3.4.1 Numerical Limits (p. 10)
*Description:
This section needs to have the macro name for each number given here,
so that there is no unclarity about which limit corresponds to which
macro name in D.4 Limits. It also (at least) needs a "Forward
Reference":
Forward Reference: Limits (Sec. D.4)
*Problem: Possible over-zealousness allowed
*Reference: B.3.4.2 Other Constraints (p. 11)
*Description:
External identifiers beginning with a leading underscore, and
all identifiers beginning with two underscores, are reserved
for use by the implementation and must not be used by a
program, except to specify implementation-defined values.
Some over-zealous implementor will try and make this a compiler-
enforced option unless otherwise instructed. I suggest the following
addition to the end of this paragraph.
This must not be enforced by the compiler.
*Problem: Portability, Generally Disgusting
*Reference: B.3.4.2 Other Constraints (p. 11)
*Description:
External identifiers may be limited to as few as 6 significant
characters with case distinctions ignored, due to restrictions
imposed by linkers.
As I pointed out in my first article, this is ridiculous. I simply
refer you to that, with the following brief comments. Having written a
loader, I know how much work it is, and writing a loader to handle
binaries with a larger fixed limit (31, say) is no more difficult than
implementing several of the other new features of this language
specification. Case distinction is a different problem, of course; see
my comments on "Allowable Deletions".
Ken Arnold
------------------------------
Date: Fri, 8 Feb 85 15:55:16 est
From: cbosgd!watmath!kpmartin (Kevin Martin)
Subject: Range cases: A suggestion, and a dum-dum.
To: cbosgd!std-c
First, the suggestion:
In addition to allowing a case of the form:
case 10..20:
it should be possible to say:
case >20:
with the somewhat obvious meaning of "all values greater than 20".
This avoids having to say things like
case 21..32767:
or
case 21..MAX_INT:
(The former breaks if your ints aren't 16 bits. The latter breaks if your
switch expression was actually a long, in which case you should have
said MAX_LONG. This is especially troublesome if your switch expression
type is actually a typedef over which you have no control because it
is supplied by a library package)
Similarly,
case <20:
and maybe
case >=20:
case <=20:
could be allowed too.
Such constructs would likely show up most often to do a three-way
decision based on the value returned by strcmp (or other such compare
functions)
I am not sure what to do with these if the switch expression is of an
unsigned type...
Now, the dum-dum: According to the draft proposed standard I have
(Nov. 12th, a mouldy oldie), the statement
case 10..20:
will give a syntax error. Why? Section C.1 says that the next token is the
longest sequence of characters that can form a token. Section C.1.3.1 allows
"10." to be a legit floating constant. And ".20" also. So the example is
tokenized as:
keyword floating-constant floating-constant colon
To avoid the error, you must say:
case 10 ..20: /* note the extra blank */
This comes from the unfortunate use of '.' as the range marker.
(as an aside, why didn't they use '...' instead of '..', since the former
is also a legit token).
A better choice would have been ("would be" if this can still be changed)
case 10::20:
This is the syntax used by the B language (C's predecessor) for ranges
Kevin Martin, UofW Software Development Group
------------------------------
End of mod.std.c Digest - Fri, 15 Feb 85 07:47:59 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.
--
Orlando Sotomayor-Diaz /AT&T Bell Laboratories, Red Hill Road
/Middletown, New Jersey, 07748 (HR 1B 316)
Tel: 201-949-9230 /UUCP: {ihnp4, houxm}!homxa!osd7