From: utzoo!decvax!cca!gwyn@Brl@sri-unix Newsgroups: net.unix-wizards Title: Re: C extensions Article-I.D.: sri-unix.4046 Posted: Tue Oct 26 04:54:37 1982 Received: Wed Oct 27 04:57:01 1982 From: Doug Gwyn Date: 22 Oct 82 18:16:35-EDT (Fri) Some of the things you would like added to C are already possible. /usr/include/varargs.h implements variable-argument list support, although I wouldn't recommend its use for much more than i/o lists. It is a bit tricky to implement varargs on some architectures (sometimes registers are used for some arguments and memory for the others) but as far as I know it can always be done. There are two approaches to "retiring" variables when they are no longer needed (most useful for register variables). Often the code can be modularized so that no procedure uses more than the maximum number of registers; local variables are hidden from other sections of the code, of course. The other method is something that I use a lot but that some people hate: one can declare "local" variables at the start of any compound statement block (i.e., after a `{'); they "vanish" when the corresponding `}' is reached. Although local variables preempt any of the same name from the block's environment, good programming practice requires one to use distinct names (although using the same name in disjoint local symbol blocks, such as "i" for loop indices, doesn't pose a problem). One can easily implement "packages" as separately-compiled source files; declare all non-globally-known extern names "static". I also do this quite a bit and it works beautifully. Many of the changes to C since 6th Edition UNIX were made to support portable coding (e.g., type-casts, unions), so it is not advisable to continue to use the 6th Edition compiler. With a moderate effort, one can bring up the System III C compiler and library on a 6th Edition kernel. I did this at Geotronics; maybe someone there would be willing to export the package to save others having to reinvent the wheel. As for incorporating the preprocessor in the compiler, apart from the desire to compile "modules" (see above), this is an implementation decision. In fact Whitesmiths' C preprocessor can generate either C code with # lines resolved, or lexemes for pass one of the compiler proper. I think this is a nice idea but it has no direct effect on the language user. I am mystified by the "constant type class". Perhaps you mean read-only (therefore initialized!) data? The preprocessor provides already the Pascal style of "constant" via #define. I can't think of a clean general way to specify union initializers. A portable way to accomplish this would be to execute an init_data() function first thing in main(). Or, in a "package" you could have an "initialized" flag tested on each entry and initialization done if not already. Admittedly this adds run-time overhead; however, you would have to do this in Pascal anyway and in C it is only necessary for unions. I have yet to need initialized unions, although I am sure an example could be cooked up. I am glad to see some discussion of C improvements. For the most part, it is a very nice, clean language. There seem to be very few possibilities for (compatible!) enhancements beyond existing capabilities.