c99

问题 This question is almost a duplicate of some others I've found, but this specifically concerns POSIX, and a very common example in pthreads that I've encountered several times. I'm mostly concerned with the current state of affairs (i.e., C99 and POSIX.1-2008 or later), but any interesting historical information is of course interesting as well. The question basically boils down to whether b will always take the same value as a in the following code: long int a = /* some valid value */ void

问题 Why does not GCC compile the C99 by default? I mean why is it necessary to add --std=c99 flag everytime a code in C99 is written? 回答1: Edit: As of GCC 5, -std=gnu11 is the default. See Porting to GCC 5. See C Dialect Options, gnu89 is the default. `gnu89' GNU dialect of ISO C90 (including some C99 features). This is the default for C code. As @tsv mentioned, ISO C99 is not fully supported yet: `c99' `c9x' `iso9899:1999' `iso9899:199x' ISO C99. Note that this standard is not yet fully

问题 Is the difference of two non-void pointer variables defined (per C99 and/or C++98) if they are both NULL valued? For instance, say I have a buffer structure that looks like this: struct buf { char *buf; char *pwrite; char *pread; } ex; Say, ex.buf points to an array or some malloc'ed memory. If my code always ensures that pwrite and pread point within that array or one past it, then I am fairly confident that ex.pwrite - ex.pread will always be defined. However, what if pwrite and pread are

问题 Which modern compilers support the Gnu Statement expression (C and C++ languages). What versions should I have to use a statement expressions? Statement expression is smth like ({ code; code; retval }) : int b=56; int c= ({int a; a=sin(b); a}) I already know some such compilers: GCC >=3 Clang/LLVM >= ? Intel C++ Compiler >= 6.0 (Linux version, check page 4; bit limited) Sun Studio >= 12 (New Language Extensions) IBM XL for z/OS (marked as IBM extension) Open64 (as it uses osprey-gcc frontend)

问题 One does usually associate 'unmodifiable' with the term literal char* str = "Hello World!"; *str = 'B'; // Bus Error! However when using compound literals, I quickly discovered they are completely modifiable (and looking at the generated machine code, you see they are pushed on the stack): char* str = (char[]){"Hello World"}; *str = 'B'; // A-Okay! I'm compiling with clang-703.0.29 . Shouldn't those two examples generate the exact same machine code? Is a compound literal really a literal, if

问题 Recent versions of Visual Studio have seen improving support for C99. Does the latest version, VS2017, now support all of C99? If not, what features of C99 are still missing? 回答1: No. https://docs.microsoft.com/en-us/cpp/visual-cpp-language-conformance The compiler’s support for C99 Preprocessor rules is incomplete in Visual Studio 2017. Variadic macros are supported, but there are many bugs in the preprocessor’s behavior. https://docs.microsoft.com/en-us/cpp/build/walkthrough-compile-a-c

问题 When you have string in C, you can add direct hex code inside. char str[] = "abcde"; // 'a', 'b', 'c', 'd', 'e', 0x00 char str2[] = "abc\x12\x34"; // 'a', 'b', 'c', 0x12, 0x34, 0x00 Both examples have 6 bytes in memory. Now the problem exists if you want to add value [a-fA-F0-9] after hex entry. //I want: 'a', 'b', 'c', 0x12, 'e', 0x00 //Error, hex is too big because last e is treated as part of hex thus becoming 0x12e char problem[] = "abc\x12e"; Possible solution is to replace after

问题 here is very simplified code of problem I have: enum node_type { t_int, t_double }; struct int_node { int value; }; struct double_node { double value; }; struct node { enum node_type type; union { struct int_node int_n; struct double_node double_n; }; }; int main(void) { struct int_node i; i.value = 10; struct node n; n.type = t_int; n. int_n = i; return 0; } And what I don't undestand is this: $ cc us.c $ cc -std=c99 us.c us.c:18:4: warning: declaration does not declare anything us.c: In

问题 I used to think that in C99, even if the side-effects of functions f and g interfered, and although the expression f() + g() does not contain a sequence point, f and g would contain some, so the behavior would be unspecified: either f() would be called before g(), or g() before f(). I am no longer so sure. What if the compiler inlines the functions (which the compiler may decide to do even if the functions are not declared inline ) and then reorders instructions? May one get a result

问题 Quoting from the C-std section 6.7.2.1, struct s { int n; double d[]; }; This is a valid structure declaration. I am looking for some practical use of this kind of syntax. To be precise, how is this construct any more or less powerful than keeping a double* as the 2nd element? Or is this another case of 'you-can-do-it-in-multiple-ways'? Arpan 回答1: The C FAQ answers precisely this question. The quick answer is that this structure will include the double array inside the structure rather than a