From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu From: "Douglas A. Gwyn" Message-ID: <3DD357DE.7070903@null.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit References: , <29597830.1037174088@WAAKZAAMHEID> Subject: Re: [9fans] how to avoid a memset() optimization Date: Thu, 14 Nov 2002 10:21:29 +0000 Topicbox-Message-UUID: 1e797146-eacb-11e9-9e20-41e7f4b1d025 rob pike wrote: > It's not a bug, it's an allowed optimization. > does in fact sum it up well. I think there's actually a need > for a C-like language again, since C is pretty much gone from > the earth. (Even when the compiler resists the needless > complexity, the libraries and ohmygod include files suffice > to bloat and confuse beyond redemption.) The problem is of > course that only curmudgeons like me feel the need; everyone > else wants the rat's nest, which is why we got it in the first > place. Actually I argued in committee for requiring all indicated accesses without requiring introduction of volatile qualification, but essentially all the compiler vendors said that their customers typically preferred faster (optimized) code and would reject any C standard (thus standard-conforming compilers) that disallowed whatever optimizations could be thought up that didn't change the outcome of the computation. At least with the introduction of volatile qualification there is a standard way for the programmer to obtain the specific behavior desired in this case. C as you imagine it was never really in existence; even on the PDP-11, certain access patterns (such as dereference of constants in the range 0160000-017777t) were specially (kludge) excluded from optimization, so that device drivers wouldn't be broken by non-1-to-1 translations from source code to accesses. "volatile" addresses such issues as well as we could with a simple portable mechanism. The main reason for the growth of library functios and include files is that it is relatively easy to add new features, but once enough people have developed applications that depend on them, it is horribly painful and expensive to remove the features. In the case of duplicate sets of character/string functions, I largely lay the blame for that on Dennis's public insistence that it was fundamental to C that sizeof(char)==1. That in effect guaranteed that the same size object could not be used both for basic storage unit and for character code, so the traditional str* functions immediately became inadequate. It would have been nice to junk them, but obviously they were too widely used by then and had to be standardized. We do the best we can in the face of conflicting requirements.