AFAICT, another C disagreement between Clang (error diagnostic) and GCC (no diagnostic): C18 6.7.5p8, "if the definition of an object has an alignment specifier, any other declaration of that object shall either specify equivalent alignment or have no alignment specifier."
I may have found another bit of C that GCC 10.2 and Clang 11.0.0 can't agree on. C18 6.7.5 "an alignment specifier shall appear only in [...] the type name of a compound literal," but Clang's parser can't handle it if it comes immediately after the lparen. godbolt.org/z/hqxvnT
You know you have a true 10x developer when they're churning out thousands upon thousands of lines of bare-metal, performant C code, and still hitting 100% test coverage godbolt.org/z/Tb4abb
GCC 10.2 and Clang 11 just can't agree on whether you can put a C18 '_Static_assert' in a 'for' loop. GCC says sure, Clang says no way. godbolt.org/z/e8EEYM
Brian Gesiak retweeted
Replying to @modocache @mattjgalloway
One of my hot takes these days is that, if I made my own language, I don't think I would allow identifiers to be shadowed. In C in particular, it seems to enable some very strange semantics.
Never really read the C standard very closely before, but here's some fun trivia: in 'if' statements, both the body and the statement itself have their own scope. So you can define 'struct s' and then shadow it twice, all in one 'if' statement, without a compound-statement.
Probably one of the most efficient movers for millennials escaping to the suburbs with a collection of homogeneous objects that don't provide a copy constructor
Some interesting stuff going on here!
* C18 6.6p10: A C compiler may treat any expression as a constant expression.
* C18 6.7.6.2p5: Array with a non-constant size expression is a VLA.
* C18 6.5.3.4p2: 'sizeof' only evaluates its operand if it's a VLA.
This Post is from an account that no longer exists. Learn more
Happy Adopt-a-versary to our wonderful pup, Ellie! 2 years ago when we first met, you were scared and had rashes all over. Now you're healthy and happy as a clam!
It seems odd to me that C standardizes the 'offsetof' macro to take a 'member-designator' as its second operand, and that grammar element is never defined, AFAICT. GNU C documents it as having slightly different syntax than the standardized 'designator-list', which seems awkward.
In C a struct declaration is just a type-specifier, and the grammar allows type-specifiers in all sorts of fun and exciting places:
// Define 'struct str' within cast-expression:
void *p = (struct str { char *data; size_t length; } *)0;
// Use it:
struct str s;




















