From mboxrd@z Thu Jan  1 00:00:00 1970
Message-Id: <200211141446.JAA19343@math.psu.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] how to avoid a memset() optimization
In-Reply-To: Your message of "Thu, 14 Nov 2002 10:21:29 GMT."
             <3DD357DE.7070903@null.net>
From: Dan Cross <cross@math.psu.edu>
Date: Thu, 14 Nov 2002 09:46:56 -0500
Topicbox-Message-UUID: 1f418848-eacb-11e9-9e20-41e7f4b1d025

> 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.

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?  It seems
like that, combined with, e.g., smemset() would solve the
problem.  smemset(), from a design perspective, really is the
right approach, and expecting inexperienced programmers to
understand all the subtleties of volatile aren't.  Example:
``what's this volatile thing do?  Wow; I deleted it and the
code still compiles.  And it's much nicer looking without it.
(hum hum hum)''

> 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.

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.

> We do the best we can in the face of conflicting requirements.

Sometimes the best you can do creates more conflict, though.  Not
a dig, but a truism.

	- Dan C.