From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu Date: Wed, 2 May 2007 08:32:43 +0000 From: "Douglas A. Gwyn" Message-ID: <4637917B.19AC54E1@null.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: Subject: Re: [9fans] kenc Topicbox-Message-UUID: 55b9b588-ead2-11e9-9d60-3106f5b1d025 Saint Sexburga wrote: > surely you can sympathise with those of us who feel that they are > drowning in the rising tide of complexity of modern computing > "standards". C99 is the least of our worries, but even here, do you > feel that Dennis Ritchie was entirely wrong in his answer to the > question "Are you satisfied with C99?", when he said, amongst other > things: > "I was satisfied with the 1989/1990 ANSI/ISO standard. The new C99 > standard is much bulkier, and though the committee has signaled that > much of their time was spent in resisting feature-suggestions, there > are still plenty of accepted ones to digest. I certainly don't desire > additional ones, and the most obvious reaction is that I wish they had > resisted more firmly" and "Of the new things, restricted pointers > probably are a help; variadic macros and bool are just adornment." It's certainly true that the bulk of C99 seems excessive; largely it is due to having a parallel set of wchar_t-oriented functions duplicating the functionality of the char-oriented ones (which I predicted back in 1986 when we were still debating how to accommodate extended character sets). A lot has also been added in areas such as floating-point that is of interest to a limited portion of the programming community. Unfortunately, a lot of useful things naturally fall into the "limited interest" category; we try to accommodate those interests with libraries when feasible, but the key point is standardization so that applications are readily portable across platforms (including Plan 9, to the extent that it supports such standards). Variadic macros are sufficiently useful (typically for printf-like error handling) that GCC had already invented a form of them; we would have liked to simply adopt that existing practice, but found enough potential problems with it that we adopted a slightly different solution. Bool is another example of numerous incompatible extensions to achieve the effect (usually by programmers in this instance, rather than in compilers), which is a good indication of a facility crying out for a standardized solution. It obviously isn't a "deep" feature, which it can't be given the need to remain compatible with existing C, but it is useful to have. > Doug, I'm not getting at you, but do you never feel, enough is enough? I understand the frustration. Many standards and portions therefof can be ignored if you don't need to use certain specified features. Unfortunately, a very large amount of "infrastructure" has evolved and a very large amount of current software has been built upon it. Not long ago I tried to build GCC 4.0 on Solaris 8 and found that I needed to install about a dozen nonstandard support libraries before I could get it to build. (I think that current releases of Solaris and Linux are shipped with most or all of those libraries.) In fact I ran out of disk space and had to devise a workaround to get the job done. You can imagine that adapting such software is a problem due to the large number of library interfaces that must be understood. I don't see any way to undo the situation..