From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu From: "Douglas A. Gwyn" Message-ID: <3DD3D463.BE431AC7@arl.army.mil> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <3DD357DE.7070903@null.net>, <200211141446.JAA19343@math.psu.edu> Subject: Re: [9fans] how to avoid a memset() optimization Date: Thu, 14 Nov 2002 16:59:33 +0000 Topicbox-Message-UUID: 1fff37f8-eacb-11e9-9e20-41e7f4b1d025 Dan Cross wrote: > I don't have my copy of C99 handy, but can you put volatile > in a function's prototype as a hint to the compiler that calls > to that function should *not* be optimized away? Yes, if declared properly, the accesses through the pointer to volatile objects would be required to occur, although other optimizations (such as in-lining) could still be performed. One could in principle cast non-volatile object references to volatile pointers when invoking a function, but if the prototype didn't include the volatile qualifer it is currently a constraint violation. > smemset(), from a design perspective, really is the right approach memset((volatile void*)p,n,0) would be similar if it were allowed. > I personally think that C should have a byte type, and not > char. Char is really about bytes masquerading as characters, > not character data. Dennis is right however, that you need > a type with sizeof(that_type) == 1. Oh, I agree. In fact my 1986 proposal chose "short char" as the name for the byte type in order not to introduce a new keyword. The only change to applications would be for malloc invocations for char arrays to be modified to match the usage style for other arrays: p = malloc(n*sizeof(char)); in fact at around that time I adopted that style for my own programming and it wasn't a lot of trouble. One advantage to separating the storage unit size from particular data types is that it supports bit-addressable architectures, where short char might occupy 1 bit. I've often needed bit arrays and it has been a pity that the language wouldn't support an efficient allocation of them. Indeed there has been a chicken-and- egg cycle here; one computer architect contacted me hoping that the forthcoming C standard would offer such support, since he was agitating for bit addressability in a new architecture in the works. Unfortunately, he was met by the objection "If we had that feature it would not be available to the HLL programmer anyway." My general feeling is that it is way too late to "fix" C, but a C-like language could be designed to take into account what we should have learned from actual C experience. However, I don't know who I would trust to get it right.