Reply to thread

Message: [QUOTE="Keith Thompson, post: 2422512"] Not really. Strictly speaking, the "as if" rule has to do with expression evaluation. In the C99 standard, the index entry for "as-if rule" points to 5.1.2.3, Program execution, which says: 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). I'm starting to lose track of what we're talking about. Let me try to summarize. The standard requires int8_t to be a typedef for a signed integer type with width 8 (and a couple of other characteristics). Since plain char is not a "signed integer type" even if it happens to be signed (see 6.2.5), int8_t cannot legally be a typedef for plain char. Either it's a typedef for signed char (if CHAR_BIT==8), or it's a typedef for and extended signed integer type with the required properties, or int8_t is not defined. For any implementation, the following is a constraint violation requiring a diagnostic: char *cptr = 0; int8_t *iptr = cptr; /* incompatible types */ An implementation that makes int8_t a typedef for plain char (which we'll assume is signed) but is otherwise conforming most likely would not issue a diagnostic for the initialization of iptr; because of this, we can tell that the implementation is not conforming. An implementation that makes int8_t a typedef for plain char but then contrives to appear to be conforming anyway would have to issue the required diagnostic for the initialization of iptr. Unless the implementer is exceedingly clever and has way too much time on his hands, it would probably also issue annoying diagnostics for constructs that don't require them. For example: typedef char plain_char; char *cptr = 0; plain_char *pcptr = cptr; /* annoying diagnostic (?) */ Spurious diagnostic like this don't make the implementation non-conforming, of course. But if the implementer were sane, he would simply make int8_t a typedef for signed char as soon as he realized that making it a typedef for char is not allowed. Do you have some examples in mind? Satisfying comformance isn't "mere" in my opinion; it's what implementations are supposed to do, just as writers of application software can and do go out of their way _merely_ to produce correct output. As for diagnostics, I've found that the ones required by the C standard are insufficient -- which is why good compilers and related tools produce additional non-required diagnostics. I'm trying to understand just what your point is. Can you summarize it in a few sentences? [/QUOTE]

Verification