Alan Grimes alangrimes@starpower.net wrote: Also, the C compiler does not follow the C idiom of making all constants ALLCAPS. Since the C code is the moral equivalent of assembly code, and since said idiom is more honoured in the breach than the observance (and was a bad idea in the first place), why care?
4. A great many computations involve extracting bit-fields. In many cases these bit fields include important scalar information such as "sizeBits". A useful improvment would be to make these either bytes or short-ints and then let the C compiler figure out how best to extract them from the words... Years ago I had my fingers burned with C bitfields to the point where I *never* use them. If the compiler optimises, code that does explicit shifts and masks will be quite as efficient as bitfields. if it doesn't, you have worse things to worry about. Bitfields are a portability minefield, even between compilers on the same machine, even sometimes between different options for the *same* compiler on the same machine.
16. C99 adds block contexts.
Eh? C99 has exactly the same "blocks" as C89; the only change is that array sizes can be dynamic expressions, not just constant expressions.
The current cCompiler will take all inlined methods as well as loop variables and put them at the beginning of the generated function. Since any current C and even older C++ compilers will support for (int i; i < x ; i ++ ), it would be much better form to use this instead of heaping all variables at the beginning of the block. Oh, you mean NON-block declarations. There is absolutely no point in worrying about this one. I've seen a Scheme compiler which generated a separate variable for each subexpression in a function, so that some of the generated C had hundreds of variables. Any C compiler worth having these days will do lifetime analysis. Declarations in loop headers are nice for programmers, but for (int i; i < x; i++) ---stmt--- doesn't do anything that {int i; for (i = 0; i < x; i++) ---stmt---} doesn't do (except, of course, for using an uninitialised variable. (:-)) With an optimising compiler, putting the variable at the function-level block doesn't make any difference; what matters is where it is mentioned.