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

From: Paul Hsieh (qed_at_pobox.com)
Date: 12/02/03 

Date: 2 Dec 2003 09:56:16 -0800

Sidney Cadot <sidney@jigsaw.nl> 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).

It has? I can't think of a single feature in C99 that would come as
anything relevant in any code I have ever written or will ever write
in the C with the exception of "restrict" and //-style comments.
There are a number of features in C99 that I will steer away from if
this issue ever comes up.

> [...] 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.

I don't think that day will ever come. In its totallity C99 is almost
completely worthless in real world environments. Vendors will be
smart to pick up restrict and few of the goodies in C99 and just stop
there.
 
> 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).

Hmm ... no, if you can determine that a platform does not suppose such
a fixed-width type at compile time, that's probably good enough.
 
> * support for a "packed" attribute to structs, guaranteeing that no
> padding occurs.

Indeed, this is something I use on the x86 all the time. The problem
is that on platforms like UltraSparc or Alpha, this will either
inevitably lead to BUS errors, or extremely slow performing code.

If instead, the preprocessor were a lot more functional, then you
could simply extract packed offsets from a list of declarations and
literally plug them in as offsets into a char[] and do the slow memcpy
operations yourself.
 
> * 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).

I agree. Enums, as far as I can tell, are almost useless from a
compiler assisted code integrity point of view because of the
automatic coercion between ints and enums. Its almost not worth the
bothering to ever using an enum for any reason because of it.
 
> * 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.

That doesn't seem possible. The amount of "stack" that an
implementation might use for a given function is clearly not easy to
define. Better to just leave this loose.
 
> * a library function that allows the retrieval of the size of a memory
> block previously allocated using "malloc"/"calloc"/"realloc" and
> friends.

There's a lot more that you can do as well. Such as a tryexpand()
function which works like realloc except that it performs no action
except returning with some sort of error status if the block cannot be
resized without moving its base pointer. Further, one would like to
be able to manage *multiple* heaps, and have a freeall() function --
it would make the problem of memory leaks much more manageable for
many applications. It would almost make some cases enormously faster.
 
> * 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.
>
> * a printf format specifier for printing numbers in base-2.

Ah -- the kludge request. Rather than adding format specifiers one at
a time, why not instead add in a way of being able to plug in
programmer-defined format specifiers? I think people in general would
like to use printf for printing out more than just the base types in a
collection of just a few formats defined at the whims of some 70s UNIX
hackers. Why not be able to print out your data structures, or
relevant parts of them as you see fit?

> * 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).

The problem is that real string handling requires memory handling.
The other primitive types in C are flat structures that are fixed
width. You either need something like C++'s constructor/destructor
semantics or automatic garbage collection otherwise you're going to
have some trouble with memory leaking.

With the restrictions of the C language, I think you are going to find
it hard to have even a language implemented primitive that takes you
anywhere beyond what I've done with the better string library, for
example (http://bstring.sf.net). But even with bstrlib, you need to
explicitely call bdestroy to clean up your bstrings.

I'd be all for adding bstrlib to the C standard, but I'm not sure its
necessary. Its totally portable and freely downloadable, without much
prospect for compiler implementors to improve upon it with any native
implementations, so it might just not matter.
 
> * Normative statements on the upper-bound worst-case asymptotic
> behavior of things like qsort() and bsearch() would be nice.

Yeah, it would be nice to catch up to where the C++ people have gone
some years ago.

> 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 :-)

Anything that precludes the implementation of an actual quicksort
algorithm is a good thing. Saying Quicksort is O(n*log(n)) most of
the time is like saying Michael Jackson does not molest most of the
children in the US.
 
> * mandatory constants for many things that currently need to
> be tested by autoconf and similar tools, e.g. endianness.

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

Let's not and say we did.
 
> * 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.

Hmmm ... its not like you can't construct a loop to do this correctly,
so I'm not sure you need a language extension just for this. I think
this is too marginal.
 
> * 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.

This seems too esoteric.
 
> * 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).

Hmmm ... why not instead have ordinary operator overloading? While
this is sometimes a useful shorthand, I am sure that different
applications have different list cutesy compactions that would be
worth while instead of the one above.
 
> * a way to "bitwise invert" a variable without actually
> assigning, complementing "&=", "|=", and friends.

Is a ~= a really that much of a burden to type?
 
> * 'min' and 'max' operators (following gcc: ?< and ?>)

As I mentioned above, you might as well have operator overloading instead.
 
> * a div and matching mod operator that round to -infinity,
> to complement the current less useful semantics of rounding
> towards zero.

Well ... but this is the very least of the kinds of arithmetic operator
extensions that one would want. A widening multiply operation is
almost *imperative*. It always floors me that other languages are not
picking this up. Nearly every modern microprocessor in existence has
a widening multiply operation -- because the CPU manufacturer *KNOW*
its necessary. And yet its not accessible from any language. Probably
because most languages have been written on top of C or C++. And what
about a simple carry capturing addition?

> Personally, I don't think it would be a good idea to have templates
> in C, not even simple ones. This is bound to have quite complicated
> semantics that I would not like to internalize.

Right -- this would just be making C into C++. Why not instead
dramatically improve the functionality of the preprocessor so that the
macro-like cobblings we put together in place of templates are
actually good for something? I've posted elsewhere about this, so I
won't go into details. 

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

Relevant Pages

  • Re: good c compiler
    ... Language accepted is C99. ... In the mode where it comes closest to conforming to C90, it supports as extensions certain C99 features. ... However, at least diagnostic message is mandatory under C90 for some uses of most of those features, and lcc-win does not generate those mandatory diagnostics. ...
    (comp.lang.c)
  • Re: Boost process and C
    ... Most users of C want a compact and efficient language. ... complained that they don't want all the "new" features in C99 hence the ... I can't understand why people want to add a lot of C++ features to C. ...
    (comp.lang.c)
  • Re: book on C99
    ... >>Is there a book on the C language that covers the features added in ... > language from pre-standard through C99. ...
    (comp.lang.c)
  • Re: Where did the prophet really live?
    ... features were in the spoken language or not. ... Now the point that Macdonald makes is that Sabaic was the prestige ... medieval arab historians had reported inscriptions ...
    (soc.religion.islam)
  • Re: So what Standard are we working off?
    ... continuing to improve the language. ... standard, the addition of "auto" alone seems to make the standard ... there are basically no C99 compilers and there is no demand from ... support), and 2) Non-determinable integer scalar sizes, that are not ...
    (comp.lang.c)