Re: how to avoid a memset() optimization

> >{
> > char key[16];
> > strcpy(key, "whatever");
> > encrpts(key);
> > memset(key, 0, 16);
> >}
> [ how to be sure the memset isn't optimized away? ]


> >[Declaring the array volatile is the right way to do it. The reason
> >volatile exists is to tell the compiler not to do otherwise valid
> >optimizations. -John]
>
> I hesitate to contradict the master, but I vote against 'volatile" for
> key[]. If you declare key[] volatile, then you have to cast away the
> volatility when passing it to strcpy(), encrpts(), and memset(), which
> do not deal with volatile strings. In this example, there's no reason
> why they should.
>
> You want the compiler to assume a reference to key[] after memset(),
> which is what you're assuming when you worry about someone seeing
> it. Try declaring key[] static or external instead. That warns the
> compiler that you're assuming a lifetime beyond main().
>
> If you absolutely need key[] to be auto, then you've got a problem.
> Consider writing your own memset() that accepts a volatile.
> --
> mac the naïf
> [I don't see any reason that casting away the volatile wouldn't work. -John]


Calling memset to set a volatile variable or array in C is undefined
behaviour. Modifying or accessing any volatile data through a
pointer-to-non-volatile is undefined behaviour. When a volatile object
is modified, all accesses to that object have to happen exactly as
programmed (no as-if rule here). But if you call memset, it is
completely undefined how many accesses there are, and in which order
they happen, so this just cannot work correctly with volatile data.


[Oops, it's true, and casting away volatile makes the memset
discardable. In this case, since the buffer is small, a for loop
seems reasonable. -John]

Return to the comp.compilers page.
Search the comp.compilers archives again.