Re: Is C99 the final C? (some suggestions)

From: Arthur J. O'Dwyer (ajo_at_nospam.andrew.cmu.edu)
Date: 11/30/03 

Date: Sat, 29 Nov 2003 23:37:08 -0500 (EST)

On Sun, 30 Nov 2003, Sidney Cadot wrote:
>
> Michael B. wrote:
> > I was just thinking about this, specifically wondering if there's any
> > features that the C specification currently lacks, and which may be
> > included in some future standardization.
>
> I think C99 has come a long way to fix the most obvious problems in C89
> (and its predecessors). I for one would be happy if more compilers would
> fully start to support C99, It will be a good day when I can actually
> start to use many of the new features without having to worry about
> portability too much, as is the current situation.

  Agreed. Although besides the mixing of declarations and statements,
I can't think of any C99 features I *use* that are lacking in C90.
I think // comments are obscene; I have no use for variable-width
arrays; any time I need an exactly 32-bit integer type, I'm probably
not writing completely portably anyway and might as well use 'int'
itself; and so on.

> There's always some things that could be improved of course. My personal
> wish-list would include (in no particular order):
>
> * mandatory support for fixed-width integers (in C99, this is optional).

  This would make some platforms incompatible with C; up to this
point, C has never [to my knowledge] *required* any fixed-width
data types. How about those 9-bit-byte mainframes everyone likes
to bring up?

> * support for a "packed" attribute to structs, guaranteeing that no
> padding occurs.

  Needs elaboration. As stated, this is flatly impossible. Even
on a vanilla Win/Intel platform,

  struct { char c; double d; } x;

simply *cannot* be organized to completely avoid padding. Unless
you'd just allow the compiler to throw a warning saying "Whoops!
This struct can't be 'un-padded'!" But then you'd have implementation-
defined behavior, which is basically what we have in C99 anyway.

> * some mandatory semantics for floating-points types; e.g. the assurance
> that integers between certain limits can be represented exactly in the
> FP types (with associated constants in limits.h)

  This either already exists, or would require only a small change,
I think. FP types already have mantissa and exponent parts; all
this would require would be a standard minimum mantissa length.

> * deprecation of implicit casts of fp-types to integer types (perhaps
> supported by a mandatory compiler warning).

  No such thing as an "implicit cast." And I really don't see
the point of this one, although I have vague recollections that
you don't like any of C's implicit conversions (you heretic
malloc-caster, you!). I think warnings about "possible loss of
data" or "wider type converted to shorter type" are QoI issues
at most.

> * deprecation of implicit casts of void* to other pointer types (perhaps
> supported by a mandatory compiler warning). This is a desire not
> likely to be shared by many here, though ;-)

  Right. Not least because it would break just about every
C program written in the last 10 years. And that's a somewhat
conservative estimate.
  If you want Java, you know where to find it. One of the great
things about C is that it is (IMHO) more elegant than Java, with
the latter's uber-strict typing rules and plethora of casts.
Compare a C++ client program to a Java one sometime, and marvel
at the difference. (But that's just me, and it's OT here anyway.)

> * upgraded status of enum types (they are currently quite
> interchangeable with ints); deprecation of implicit casts from
> int to enum (perhaps supported by a mandatory compiler warning).

  Agreed, it would be nice for enums to be more "special." On
the other hand, the biggest use for enums is as a drop-in replacement
for #defined integer constants, and I don't want to lose that
capability. (Yes, "constant" consts would fix *that* problem, but
that would basically turn C compilers into C++ compilers on a
complexity scale. I like the clear-cut distinction C makes between
"objects" like 'const int foo' and "values" like 'enum { foo }',
if you see what I mean.)

> * a clear statement concerning the minimal level of active function
> calls invocations that an implementation needs to support. Currently,
> recursive programs will stackfault at a certain point, and this
> situation is not handled satisfactorily in the standard (it is not
> adressed at all, that is), as far as I can tell.

  Agreed.

> * a library function that allows the retrieval of the size of a memory
> block previously allocated using "malloc"/"calloc"/"realloc" and
> friends.

  While this would be nice for newbies, it's redundant for Real
Programmers (tm) who know how to store numbers in variables, and
it would break lots of malloc implementations. I know, I've made
a couple. Not all the efficient malloc implementations actually
store the sizes of blocks anywhere.
  Unless you think it would be acceptable for

     msize(malloc(X)) > X

in some (or all) cases; then it'd still break libraries, but the
fix would be easier.

> * a #define'd constant in stdio.h that gives the maximal number of
> characters that a "%p" format specifier can emit. Likewise, for
> other format specifiers such as "%d" and the like.

  Interesting idea. This would be useful.

> * a printf format specifier for printing numbers in base-2.

  This, on the other hand, is kind of silly. Couldn't you
just write your own two-line function to do this? And after
base-2, what's stopping you from demanding a printf() that
can handle base-4, or base-9, or base-247? I think this is
an idea whose time will never come.
  (Not to mention all those Intro Programming instructors
who would have to find a new way of introducing recursion...)

> * I think I would like to see a real string-type as a first-class
> citizen in C, implemented as a native type. But this would open
> up too big a can of worms, I am afraid, and a good case can be
> made that this violates the principles of C too much (being a
> low-level language and all).

  Yep.

> * Normative statements on the upper-bound worst-case asymptotic
> behavior of things like qsort() and bsearch() would be nice.
> O(n*log(n)) for number-of-comparisons would be fine for qsort,
> although I believe that would actually preclude a qsort()
> implementation by means of the quicksort algorithm :-)

  Given that the Standard gives minimum bounds on the size of
any array, any *specific* qsort() implementation is O(foo) by
definition, as one can write O(foo) <= C*foo for a specific,
but very large, value of C.
  In other words, I bet you can't write a loophole-free version
of this idea. And with loopholes, it's not worth changing the
existing wording.

> * mandatory constants for many things that currently need to
> be tested by autoconf and similar tools, e.g. endianness.

  Sounds good, until I consider that the Standard doesn't even
mandate that integers *be* stored in one endianness or the other.
Surely POSIX standardized this anyway, for those platforms that
care so awful much about it.

> * deprecate trigraphs. Let's end the madness once and for all.

  Haven't they been deprecated yet? ;-)

> * a reliable and easy way to walk over all integers in a certain
> interval, including the MAX value for that type, by means of a
> for loop; eg., currently
>
> for(unsigned i=0;i<=UINT_MAX;i++) ...
>
> doesn't work as intended.

  What do you suggest? A new looping construct? :-) This is
an artifact of the way C handles numbers, and it won't go away
by wishing. Better to use one of the myriad ways already
standardized, e.g.

     i = 0;
     do {
       ...
     } while (++i != 0);

Ugly, but functional. And I'm sure this is a FAQ anyway.

> * a "reverse comma" type expression, for example denoted by
> a reverse apastrophe, where the leftmost value is the value
> of the entire expression, but the right-hand side is also
> guaranteed to be executed.

  Where's the sequence point? How on earth would this
construct possibly be useful to anybody? And who uses the
reverse apostrophe character for anything, anyway? :)

> * triple-&& and triple-|| operators: &&& and ||| with semantics
> like the 'and' and 'or' operators in python:
>
> a &&& b ---> if (a) then b else a
> a ||| b ---> if (a) then a else b
>
> (I think this is brilliant, and actually useful sometimes).

  I think something like this is a GNU C extension; IIRC
they added a?>b for "max(a,b)". Anyway, I don't see the
advantage over

     result = a? b: 0; /* &&& */
     (result = a) && (result = b); /* ||| */

The second one is just about as cryptic...

> * a way to "bitwise invert" a variable without actually
> assigning, complementing "&=", "|=", and friends.

  Huh? You want to add logical-negation and arithmetic-negation
"assignment operators" while you're at it? This is a purely
vanity "improvement"; all modern compilers contain optimizers
that can optimize "i = ~i" into the equivalent of "NOT EAX"
anyway. No need to make the code illegible too.

> * 'min' and 'max' operators (following gcc: ?< and ?>)

  Ditto the "Huh?" This is what functions were built to
do. You know, curly braces and all that? (Question for
those who know; Chris Torek, maybe?: Do any processors
incorporate 'min' and 'max' instructions, or is the ?<
operator going to get compiled into the same thing as the
function call (inlined), anyway?)

> * a div and matching mod operator that round to -infinity,
> to complement the current less useful semantics of rounding
> towards zero.

  I think the math library may already have these. If
not, then yes, this is a good idea.

my $.02,
-Arthur

Relevant Pages

  • Re: Is C99 the final C? (some suggestions)
    ... >>fully start to support C99, It will be a good day when I can actually ... > this would require would be a standard minimum mantissa length. ... >> supported by a mandatory compiler warning). ... >> calls invocations that an implementation needs to support. ...
    (comp.lang.c)
  • Re: [F77] storing bytes data
    ... >> I don't know that there is a standard for one byte integers, ... > There is no guarantee that all compilers support them, ... > that don't support one. ... > of 256 different values in default character. ...
    (comp.lang.fortran)
  • Re: Strange Behaviour of Salford Compiler
    ... > Although the standard can be cryptic at times, ... > implemented relatively early in many compilers. ... but say that it can't support some features. ...
    (comp.lang.fortran)
  • Re: My question is , will C continue to dominate the embedded systems ?
    ... >become a standard superset for embedded compilers? ... The issue is does a hosted C compiler need to support ... conforming compiler targeting embedded systems need to support say ... C compilers need to support a core language and specify clearly what ...
    (comp.arch.embedded)
  • Re: cariage control
    ... > the printing conventions of the old ASA printer standard. ... compilers don't do that, including most of the compilers that I ... I know that some operating systems support ... I want to be able to beat on the vendors that do this and convince ...
    (comp.lang.fortran)