dsill@NSWC-OAS.arpa (Dave Sill) (01/07/88)
>Primary emphasis was placed on correcting technical errors >and removing unacceptable restrictions imposed by the specifications. Apparently there was room for considering new additions, e.g. noalias. >The Committee has received numerous suggestions for >enhancements, additions, and ``inventions''. >In responding to such suggestions, >we have been mindful of our obligation to >standardize existing practice, >rather than creating a new language. Regardless of whether it's a Good Idea or not, noalias can hardly be considered `existing practice'. The same goes for function prototypes; C++ really shouldn't be considered as a source of `prior art' for the C language. >However, >the Committee hopes that further modifications to the >draft Standard >can be limited to non-substantive editorial changes, >so that the final, official Standard >can be expeditiously published. In other words: "Let's fix the typos and ship this sucker, ready or not." I just wish I'd gotten involved with the "Standard" sooner. I feel like I've missed the boat. ========== The opinions expressed above are mine. Which is worse: ignorance or apathy? Who knows? Who cares?
gwyn@brl-smoke.ARPA (Doug Gwyn ) (01/08/88)
In article <11158@brl-adm.ARPA> dsill@NSWC-OAS.arpa (Dave Sill) writes: >>Primary emphasis was placed on correcting technical errors >>and removing unacceptable restrictions imposed by the specifications. >Apparently there was room for considering new additions, e.g. noalias. Yes, when necessary to address a deficiency, new inventions were not ruled out a priori. Thus, there are in fact some new features of ANSI C that you won't find in K&R Appendix A. An incomplete list: enum void signed long double const volatile noalias structure assignment function prototypes unary + %p format hexadecimal escapes multi-byte character support international locale support atexit() Many of these are either found in some recent C implementations or are based on features found in existing practice. Some of the features are genuinely new, and in the majority of cases it was quite clear that they were sufficiently useful to standardize them. You could quibble with a few of these, for example unary + (which is the only thing listed that I could really do without), but the list of additions beyond K&R Appendix A is remarkably short when compared to the hundreds of suggestions the committee received. Certainly X3J11 did not go nearly as far overboard with adding features as most programming language standards committees, for example Fortran-8x.