why gets "invalidate_cache" a const void ptr?

[Peter Dufault]

On Apr 9, 2010, at 2:44 , Gedare Bloom wrote:

>> Right. And you pass a pointer to the "invalidate" function, it promises
>> you (through the "const" keyword) that it will NOT modify the passed in
>> object, but, at least from a CPU point of view, the memory area will
>> look different after the call.
>> 
>> That is exactly what I find illogical/wrong.
>> 
> I see your complaint: from the caller's point-of-view, the memory
> returned by accessing the pointer to const passed as an argument might
> be altered across the function call, although the memory itself didn't
> change, the cache was out-of-date.  However, the function does not
> actually write to the memory -- the memory was written before by
> something else, perhaps DMA or d/i cache mismatch.  I'm not sure
> whether it is better to elide the const modifier or not, but it does
> let the compiler ensure that the invalidate function does not attempt
> to write to the memory location, which is certainly what is expected.
> Is "volatile const void*" acceptable to the compiler and does that
> make any more sense?
> 

"volatile const void *" is acceptable, and it describes what the region looks like in the point of view of the function.  Even when it's "const void *", though, want gcc defer to how the pointed-to object is declared in the caller?  That is, it won't optimize across the call since the pointed-to object could be changed indirectly by something invoked by the invalidate function.

Unless there is something in new aliasing rules, or memory barriers, etc, that I don't understand.  Which is certainly possible.

Does anyone know if "volatile const void *" is immune to spurious warnings?  For example, I can always pass a "non-const *" pointer down to a function expecting a "const *" since all the called function is doing is promising it won't change the object pointed to, does "volatile const *" just mean that the called function will treat the underlying object as if it might suddenly change, but won't change it?  I tried a few tests and didn't get warnings.

Peter
-----------------
Peter Dufault
HD Associates, Inc.      Software and System Engineering