Lev Serebryakov wrote this message on Thu, May 01, 2014 at 11:54 +0400: > Hello, Ronald. > You wrote 26 ???????????? 2014 ??., 1:21:47: > > RFG> The (modified/quieted) code example under discussion is as follows: > RFG> variable = value0; /* initialization */ > RFG> if (condition) variable = value1; > RFG> if (!condition) variable = value2; > RFG> use (variable); > > RFG> Please note that variable *is* *always* set to some value (either value1 > RFG> or value2) after initialization. The "error condition" that you seem > RFG> concerned about having explicitly flagged does not in fact exist in the > RFG> example code snippet under discussion. > I have only one question: which memory model do you have in mind when you > do this statement? I assume he's talking about the abstract machine as defined in the C standard, like C99... which implies single threaded execution... > Please note, that now you could hardly find single-core/single-threaded CPU > (even current ARMs are multi-cored now) and only two non-functional > languages with formally specified memory model I know is C++11 and Java. > I belive, Ada should have well-defined memory model, but I know next to > nothing about Ada. > > I could easily write code like shown above in Java, which left "variable" > with value0 up to line with "use()" and it will be not a bug in JVM, but bug > in code: everything depend on variables which are used in "condition" and > "variable" itself. Yes, it is not possible (in Java!) when everything is > arguments to method or local (on stack), but as soon I don't know YOUT > memory model and that YOUR compiler and execution environment implements > this mode PROPERLY, I could not be sure, that even "localness" of data > helps. > > And please note, that different CPUs has very different memory model (even > now, when Alpha is long-dead), and as C is very down-to-hardware language > and C standard doesn't have any real memory-model described, so it is very > hard to reason about this C code, if it i C. You can properly reason about this code.. Per the C standard (5.1.2.3 para 2&3): Accessing a volatile object, modifying an object, modifying a file, or calling a function that does any of those operations are all side effects,11) which are changes in the state of the execution environment. Evaluation of an expression may produce side effects. At certain specified points in the execution sequence called sequence points, all side effects of previous evaluations shall be complete and no side effects of subsequent evaluations shall have taken place. (A summary of the sequence points is given in annex C.) In the abstract machine, all expressions are evaluated as specified by the semantics. An actual implementation need not evaluate part of an expression if it can deduce that its value is not used and that no needed side effects are produced (including any caused by calling a function or accessing a volatile object). It is up to the compiler to ensure that the abstract machine is properly translated to the CPU and memory model of said CPU... So, as long as condition is an object that is not volatile (or accessed through volatile pointers), it's state cannot change, and there for is the equivalent to if/else, though the definition of condition was left out making this hard to decide, but considering the original discussion, we should make that assumption... -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "[email protected]"