Paul Eggert wrote:
Thanks, I didn't know about this extension. However, it has undefined behavior in standard C, so we can't use it in code intended to be portable everywhere.
I wondered about that, because it seems like the kind of thing that would have undefined behaviour, but I looked at the C standard, and on my reading it actually doesn't. The relevant wording is # An object whose identifier is declared with no linkage and without the # storage-class specifier "static" has /automatic storage duration/. # [...] storage is guaranteed to be reserved for a new instance of # the object on each entry into the block with which it is associated; # the initial value of the object is indeterminate. To have an indeterminate value does not amount to undefined behaviour. When we have no initialising clause at all, clearly the indeterminate value is not a problem if we don't rely on the value; that is how the code is currently correct. An "x = x" initialiser amounts to an assignment using that initial indeterminate value. Crucially, there's nothing saying that using an indeterminate value per se invokes undefined behaviour. My reading is that an indeterminate value is some actual value, though we don't know which value it is, and that copying it by assignment or initialisation just copies whatever value it is without trouble. Thus "x = x" is truly a no-op. So I think we'd be fine to adopt the "x = x" idiom without any conditionality. Of course, the idiom might elicit *more* warnings from compilers other than gcc, and that could be a reason to use it conditionally even if correctness isn't on the line. One also might want to hide it behind a macro even if used unconditionally, on the grounds that the macro name makes clearer what's going on. -zefram