c11

As we know from from C11-memory_order: http://en.cppreference.com/w/c/atomic/memory_order And the same from C++11-std::memory_order: http://en.cppreference.com/w/cpp/atomic/memory_order On strongly-ordered systems ( x86 , SPARC, IBM mainframe), release-acquire ordering is automatic. No additional CPU instructions are issued for this synchronization mode , only certain compiler optimizations are affected (e.g. the compiler is prohibited from moving non-atomic stores past the atomic store-release or perform non-atomic loads earlier than the atomic load-acquire) But is this true for x86-SSE

Assume the following two pieces of code: char *c = "hello world"; c[1] = 'y'; The one above doesn't work. char c[] = "hello world"; c[1] = 'y'; This one does. With regards to the first one, I understand that the string "hello world" might be stored in the read only memory section and hence can't be changed. The second one however creates a character array on the stack and hence can be modified. My question is this - why don't compilers detect the first type of error? Why isn't that part of the C standard? Is there some particular reason for this? C compilers are not required to detect the

I'm trying to write a lex/yacc grammar for C11 based off of N1570. Most of my grammar is copied verbatim from the informative syntax summary, but some yacc conflicts arose. I've managed to resolve all of them except for one: there seems to be some ambiguity between when '_Atomic' is used as a type specifier and when it's used as a type qualifier. In the specifier form, _Atomic is followed immediately by parentheses, so I'm assuming it has something to do with C's little-used syntax which allows declarators to be in parentheses, thus allowing parentheses to immediately follow a qualifier. But

This question follows this previous question about the definedness of memcpy(0, 0, 0) , which has been conclusively determined to be undefined behavior. As the linked question shows, the answer hinges on the contents of C11's clause 7.1.4:1 Each of the following statements applies unless explicitly stated otherwise in the detailed descriptions that follow: If an argument to a function has an invalid value (such as a value outside the domain of the function, or a pointer outside the address space of the program, or a null pointer, […]) […] the behavior is undefined. […] The standard function

I currently use gcc 4.6.3 . My understanding is that gcc by default uses the gnu89 standard and I would like to enable C11, the latest C standard. I tried: [pauldb@pauldb-laptop test ]$ gcc -std=c11 -o test test.c cc1: error: unrecognised command line option ‘-std=c11’ I replaced c11 with gnu11 and I get the same error. What is the correct way to enable the latest C standard for gcc? (Note: I'm interested in the latest C standard and not the latest C++ one.) ouah The correct option is -std=c11 . However, it is not available in gcc 4.6 . You need at least gcc 4.7 to have this option supported.

I know that compilers use __STDC__ to indicate that a compiler is standard C and, from, there, you can use __STDC_VERSION__ to figure out which level of the standard you're using. I also know that C90 had no value, C90 amendment 1 had 199401L and C99 had 199901L . The latest C1x draft I have simply states it as 201ymmL and I'm assuming it was made a less "vague" value in the final standard. My guess is that it will be 201112L since that's when C11 was ratified but I'd like to be certain. I thought I could try using gcc -std=c1x but the version of gcc I'm running doesn't support that yet. Does

I have the following question: How are anonymous structures (or unions) properly initialized according to the current C1X draft ? Is this legal: struct foo { int a; struct { int i; int j; }; int b; }; struct foo f = { 1, 2, 3, 4 }; struct foo g = { 1, { 2 }, 3 }; In GCC, g.j == 0 and g.b == 3 , while in tcc g.j == 3 and g.b == 0 . The current draft says: "[...] unnamed members of objects of structure and union type do not participate in initialization. Unnamed members of structure objects have indeterminate value even after initialization.". Can this be really true? Isn't struct foo h = { 0 };