> From: David Jacobson [mailto:dmjacob...@sbcglobal.net] > Sent: Tuesday, 27 August, 2013 23:28
> On 8/27/13 1:33 AM, Dave Thompson wrote: > >> From: owner-openssl-...@openssl.org On Behalf Of Yuan Kang > >> Sent: Tuesday, 27 August, 2013 00:54 > > > >> I don't think that it is true that "(signed char)(*p) >= 0" > >> is always true, <snip> > > Mr Weimer didn't say it IS always true, he said a compiler > > IS ALLOWED TO ASSUME it is. As I adjusted, the compiler does > > have to document that it does this. > > I don't know who would issue such rules, or who would enforce them. > The C standard is issued basically by ISO and "national bodies" like ANSI. (If you want more details I can give them, but most people don't care.) No authority enforces it, but there are reports of people using it in private contracts. Mostly implementors who want to support portable C programming, and programmers who want to write such, obey voluntarily. > > Whether a given compiler > > does it depends on the writers of that compiler, and quite > > likely on the target architecture, and quite possibly on > > the optimizations implemented by the compiler and used. > > > > As I added, gcc (at least the versions I have) documents > > that it doesn't do so. > I really doubt that. > Look in info at "C Implementations" "Integers Implementation". > Here is (from memory) a code snippet I tested on gcc <snip: addition wraparound of 'tested-positive' (signed) int's with -O2 or higher thinks negative is positive> > The fact that the value of an operation with signed arithmetic that > overflows (the + operator) is undefined, and the result of and > operation where at least one operand is undefined (the < > operator), is Almost. In the standard, overflow of signed* arithmetic is Undefined Behavior (UB), a term defined in subclause 3.4.3: 1 undefined behavior behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements 2 NOTE Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message). 3 EXAMPLE An example of undefined behavior is the behavior on integer overflow. This means there doesn't have to be any value to <; one realistic possibility is that + traps (which gcc can with -ftrapv). The standard allows anything at all, and the canonical example on comp.lang.c is that UB "makes demons fly out your nose" but this is rarely implemented <G>. * 'signed' here is limited to signed integers. The standard says unsigned integer computation wraps-around instead of overflowing, so when 3.4.3p3 says 'integer overflow' it only means signed. Judging from c.l.c, many people think of unsigned integers as overflowing and then wrapping-around to 'fix' the overflow; that kind of 'overflow' isn't UB. Floating-point is mathematically signed, but not labelled signed in C because there is no unsigned floating-point to distinguish; FP overflow may be UB but if the implementation implements IEC 60559 aka IEEE 754 -- which most CPUs and many compilers today do -- then FP overflow is well-defined. > undefined. That allows the compiler to reason using ordinary > mathematical operations rather than computer operations. > [and deduce that nonneg+nonneg must be nonneg, unless -fwrapv] That's what gcc does in this UB case, and it's a reasonable choice, but not the only possible or allowed one. But the issue upthread was *conversion*, not arithmetic. That is covered by a different subclause in the standard, and is not labelled overflow; there is no convenient standard term, so I used "out-of-range". The result of out-of-range narrowing to signed integer is Implementation Defined (ID), which is much more constrained than UB: there must be a value, and that value must be documented by the implementation -- which gcc does, as above. But the value need not be the same across implementations, so portable code can't rely on it. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
