Question About Sequence Points and Interrupt/Thread Safety

Presumably you mean:

#error need 8 bit system

:-)

Using a string literal here looks less weird in syntax-colouring editors. I'd recommend the string literal form, even though both are valid.

-- [mdw]

Why?

The increments of i and assignments to buffer[i] both count as side effects because they are "modifying an object".

Yes, it's well documented that compilers do this sort of thing. The question, does the Standard really allow them to do it? (Stay tuned...)

Hi Eric, it's good to hear from you. I think you and your co-author have provided a real service to the community, both to implementors and to people who are involved in discussion about the Standard (including, hopefully, those actually on the ISO committee). Also, and I think I said this before, whether or not the paper has an error in this small matter, on a larger scale what it's saying is right, and I certainly never meant to imply otherwise.

Yes, however, that freedom is explicitly curtailed by the statement in 6.7.3p6, describing the requirements of volatile. The key question is, how much freedom remains after meeting those requirements? I'm still planning to address that question in more detail in an upcoming post, talking about the semantics of volatile.

You're absolutely right to point this out, and it's likely these paragraphs are responsible for most of the confusion about what the requirements for volatile actually are. This area is one of the most subtle in the whole Standard, yet it's discussed in only a few paragraphs, and the actual statements of requirements are far from clear.

I'm sorry I haven't yet been able to get to the more detailed explanation on the semantics of volatile. Hopefully I will sometime in the next day or so.

My comments do use the term 'full expression'. However, that use is more a happenstance of the phrasing than any intent to refer to the provisions in the Standard as to full expressions.

There are three problems with this argument.

One, the most obvious and the most natural reading for "any expression" is... any expression. For it to be anything other than the entire containing expression, there should be some other text somewhere in the Standard that suggests 'any expression' be given a different reading. But there doesn't seem to be any such text.

Two, in the expression 'x = a + b + c + v;', the part of it that accesses v, does an addition, and assigns to x isn't an expression; it's only pieces of something larger (that is an expression). Whatever the term 'any expression' describes, it should at least /be/ an expression.

Three, using 'full expression' instead of 'any expression' would clearly do the wrong thing. For example, consider this declaration of a variable length array (again 'v' is volatile):

int foo[v];

No full expressions in sight. Yet we certainly want the expression 'v' that specifies the array size evaluated according to the rules of volatile-referring expressions.

The reason for having UCHAR_MAX is so it can be tested in preprocessor directives. Anywhere in regular code, the expression ((unsigned char)-1) provides the appropriate value, without having to remember the name of the preprocessor symbol that supplies it.

Yuck. And again I say, Yuck. (Good analysis, Ben.)

This means expresisons like '~0u' can result in undefined behavior. Another wonderful consequence of the "value-preserving" rule in integer promotions.

Harrumph, harrumph, harrumph.

Seems like it might be a good idea to start putting

extern char no_dangerous_implementations[ UINT_MAX > INT_MAX ];

in program source, just as a nice defensive habit.

But wait a minute... this reading of the standard means that stores to local variables are also "modifying an object" and are therefore side effects that have to be made visible. This would seem to preclude almost all interesting compiler optimizations including register allocation.

Yep. That's why it is sometimes said that "volatile" disables optimizations for a particular variable. However, the degree to which it also prohibits optimizations involving _other_ variables in the same (or surrounding) expressions are unclear...

How?

Not via integer promotion, as unsigned int doesn't undergo any such promotion, and not via arithmetic conversions, as they only apply to operators with a plurality of operands.

I can't think of any other ways for its type to invisibly change.

Phil

No. 6.5.3.3. The operand of unary + and - also get promoted. For anyone worried about this in practise, it only happens on those odd implementation where int can represent all the values of unsigned int.

(You may be confusing integer promotion with "the usual arithmetic conversions".)

Yikes, the devil is in the details.

-- An object or expression with an integer type whose integer conversion rank is less than or equal to the rank of int and unsigned int.

Oh my ${DEITY} - unsigned int is promoted to int everywhere in such cases! Did the standards committee really want the 'or equal to'? It seems to make unsigned arithmetic as such practically impossible, all attempts would end up being just work on ints that would get implicitly converted to unsigned at the end. I suspect this might lead to some unintuitive expression evaluations, but can't think of any off the top of my head.

Nope, see what I wrote, I distinguish the two clearly. I simply overlooked the 'or equal to' nature, which quite frankyly scares me.

Phil

depends on your editor. My editor thinks preprocessor stuff over-rules string literals. Letting your editor dictate your coding style just seems wrong to me.

because error takes a sequence of pre-processor tokens not a string literal. I was being pedantic.

UINT_MAX + UINT_MAX would be undefined behaviour rather than UINT_MAX - 1. This is devastatingly awful! I think we're only safe because there aren't any such implementations.

I don't have my copy of C90[1] handy, so I can't tell whether this bug was actually in C90 as well.

-- [mdw]

I wasn't thinking of my editor in particular, but of syntax-colouring editors in general, some of which may become confused by random preprocessing tokens.

Besides, editors are valuable tools, and it seems sensible to play to their strengths rather than press their weak points. Of course, some tools are more onerous to accommodate than others; I'd discard a tool that was too awful, but the level of acceptable awfulness will vary from person to person.

-- [mdw]

Is a string literal not a preprocessing token, then? 6.4p1 would disagree.

I can be pedantic too.

-- [mdw]