Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!pwa-b!mmintl!franka
From: franka@mmintl.UUCP (Frank Adams)
Newsgroups: net.lang.c
Subject: What should be added to C
Message-ID: <1462@mmintl.UUCP>
Date: Fri, 16-May-86 20:51:52 EDT
Article-I.D.: mmintl.1462
Posted: Fri May 16 20:51:52 1986
Date-Received: Tue, 20-May-86 07:00:51 EDT
References: <590@brl-smoke.ARPA> <3570@nsc.UUCP>
Reply-To: franka@mmintl.UUCP (Frank Adams)
Organization: Multimate International, E. Hartford, CT
Lines: 72

As has been noted, one should use restraint in adding new features to a
language.  What follows is a list of the features I would support adding to
the *next* version of C (after the current standard is complete).

o Min and max operators.  These would get used all over the place.  These
should be usable to the left of the assignment operator, as most but not all
C operators are.

o An andif clause for if statements.

o The ability to define multi-line pre-processor macros, using #begdef and
#enddef statements.  #if and other conditionals in the body of the
definition would be evaluated when the macro was not interpreted, not when
it is encountered.

o A typeof operator, similar to sizeof.

o := as a synonym for =.  Compilers could have an option to permit := only.

o Permit a continue statement in switch, meaning that the next label should
be fallen through to.  Compilers and/or lint could produce when a program
falls through without a continue statement.

o Any sort of multi-level break statement.  There is no syntacticly clean
way of adding this to C.

o Elimination of the eight-character truncation of internal variable names
done by some compilers.  (This may be in the current spec; I haven't read
that document.)  The entire length of a variable name should be significant.

I do not support the following:

o ^^ for logical exclusive or.  Unlike the other "short-circuit" forms (&&
and ||), this doesn't save any execution -- both operands must be evaluated.
A good optimizing compiler should be able to tell that both operands to an ^
must be 0 or 1 if they are the result of comparisons or other logical
operators; if a typedef is used for booleans, boolean variables can likewise
be recognized.

o Doing anything about the array/pointer relationship.  What we have now is
a mess, but any attempt to fix it will produce a worse mess, either in the
language or with existing code.

o A separate boolean data type (sigh).  This is a good thing to have in a
language, but not a good thing to add to C as it exists.  I might support
having bool predefined as enum {false, true}; but the implications for
existing code are not trivial.

There are several things which are not part of the language definition, but
which would be useful in compilers.  These consist mostly of flagging
certain statements with (at least) warning messages.

o Statements with obviously unpredictable side effects (such as
a[i] = b[i++];) should be flagged.

o An integer constant passed to a function, which is taken to be long
instead of int because of its size, should be flagged.  (This need not be
done if the parameter types for the function have been declared.)

o A comparison which always yields the same result because of type
considerations (e.g., comparing a signed character to 128) should be flagged.

o There should be an option to flag statements of the form if (v = e) ...
(Actually, I wouldn't be averse to a coding standard which forbade such
things, in favor of if (v = e, v) ...)

I am aware that some of these things are flagged by some compilers.  Please
don't bother either me or the rest of the net by telling us about compilers
which do so.

Frank Adams                           ihnp4!philabs!pwa-b!mmintl!franka
Multimate International    52 Oakland Ave North    E. Hartford, CT 06108