Re: [9fans] how to avoid a memset() optimization

["Douglas A. Gwyn" <gwyn@arl.army.mil>]

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.