> A read of a 'volatile uint64_t', btw, is supposed to make sure that it
> reads from the original memory locations, not cached copies of it in
> register or spread across multiple registers.
No. The computing model in ANSI/ISO C doesn't really go below the level
of source code.
Volatile only guarantees that the compiler will not remove reads/writes
that, based on its analysis of the program source, it thinks are
redundant. For example:
volatile unsigned char* p = get_address();
*p = *p = 5
The compiler is not allowed to remove either assignment.
int i = *p + *p;
The compiler must dereference the pointer twice.
There is no guarantee about caching, atomicity, etc. In fact, there is no
mention of it.
> Even if it can't be
> accessed atomically, the guarantee is that it will fetch from memory,
> so that it can be changed outside the current program flow (signal
> handlers, shm, mmap, and the like). Yes, it needs to be locked (all
> possible concurrent access needs to be locked, ideally, even though
> that's a performance hog).
This is mostly right, but the one wrong bit (the guarantee) is the most
important part.
--
STSM
Senior Security Architect
DataPower SOA Appliances
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [email protected]
Automated List Manager [EMAIL PROTECTED]
