c11

问题 The following example is given in the C11 standard, 6.5.2.3 The following is not a valid fragment (because the union type is not visible within function f): struct t1 { int m; }; struct t2 { int m; }; int f(struct t1 *p1, struct t2 *p2) { if (p1->m < 0) p2->m = -p2->m; return p1->m; } int g() { union { struct t1 s1; struct t2 s2; } u; /* ... */ return f(&u.s1, &u.s2); } Why does it matter that the union type is visible to the function f? In reading through the relevant section a couple times,

问题 For two (or more) struct s: Base and Sub with a common first (unnamed) struct , is it safe to convert/cast from Base to Sub and vice versa? struct Base{ struct{ int id; // ... }; char data[]; // necessary? } struct Sub{ struct{ int id; // same '...' }; // actual data }; Are these functions guaranteed to be safe and technically correct? (Also: is the zero-length char data[] member necessary and useful?) struct Base * subToBase(struct Sub * s){ return (struct Base*)s; } struct Sub * baseToSub

问题 I was trying to write some macros for type safe use of _Bool and then stress test my code. For evil testing purposes, I came up with this dirty hack: _Bool b=0; *(unsigned char*)&b = 42; Given that _Bool is 1 byte on the implementation sizeof(_Bool)==1 ), I don't see how this hack violates the C standard. It shouldn't be a strict aliasing violation. Yet when running this program through various compilers, I get problems: #include <stdio.h> int main(void) { _Static_assert(sizeof(_Bool)==1, "

问题 I am looking for a processor that performs read acquire/store release with the same semantic as specified in the C11/C++11 standards. x86 processor synchronization is much too strong so that it is impossible to test a lock-free algorithm using acquire/release semantic. The same seems to apply to ARM processor because this architecture offers either stronger or weaker read/store synchronizations. Maybe ARMv8.3 may offer the right semantic but I believe there are no ARMv8.3 processor on the

问题 Is there a way to subtract one pointer from another in C11 and have the result be always defined? The standard says the behavior is undefined if the result is not representable as type ptrdiff_t. I am open to a solution relying on static assertions that are expected to pass on a reasonable implementation in a modern general purpose 32 or 64 bit environment. I would like to avoid solutions that rely on any sort of runtime checks. If the pointed to type has size greater than 1, I can static

问题 About the arguments of main() , the 2011 C standard says (5.1.2.2.1:2): If the value of argc is greater than zero, the array members argv[0] through argv[argc-1] inclusive shall contain pointers to strings, which are given implementation-defined values by the host environment prior to program startup. Should the word “string” in this context be interpreted as “0-terminated string”, that is, a sequence of non-0 characters followed by a final '\0', or do/may some implementations pass arguments

问题 Inspired by comments to my answer here. Is this sequence of steps legal in C standard (C11)? Make an array of function pointers Take a pointer to the first entry and cast that pointer to function pointer to void* Perform pointer arithmetic on that void* Cast it back to pointer to function pointer and dereference it. Or equivalently as code: void foo(void) { ... } void bar(void) { ... } typedef void (*voidfunc)(void); voidfunc array[] = {foo, bar}; // Step 1 void *ptr1 = array; // Step 2 void

问题 I'm trying to fix an undefined reference to memcpy_s() error. I've included string.h in my file and the memcpy() function works okay, and I've also tried including memory.h . I'm on x64 Windows 7 and using gcc 4.8.1 to compile. #include <stdlib.h> #include <stdio.h> #include <string.h> void doMemCopy(char* buf, size_t buf_size, char* in, int chr) { memcpy_s(buf, buf_size, in, chr); } memory for buf has been allocated in the main function, which calls doMemCpy(buf, 64, in, bytes) . in is a

问题 In these two examples, does accessing members of the struct by offsetting pointers from other members result in Undefined / Unspecified / Implementation Defined Behavior? struct { int a; int b; } foo1 = {0, 0}; (&foo1.a)[1] = 1; printf("%d", foo1.b); struct { int arr[1]; int b; } foo2 = {{0}, 0}; foo2.arr[1] = 1; printf("%d", foo2.b); Paragraph 14 of C11 § 6.7.2.1 seems to indicate that this should be implementation-defined: Each non-bit-field member of a structure or union object is aligned

问题 I was wondering about the following: is the new _Alignas alignment specifier in C11 applicable to structure members? I've always assumed that much, but a thorough reading of the N1570 public draft seems to indicate that an alignment-specifier cannot appear in a specifier-qualifier-list , which is where I'd expect it to be, if it were supported. I've read the grammar a couple of times but can't figure out how _Alignas is supposed to be permitted in a structure member declaration. However, it