c99

问题 I'm a little confused about the rules regarding restricted pointers. Maybe someone out there can help me out. Is it legal to define nested restricted pointers as follows: int* restrict a; int* restrict b; a = malloc(sizeof(int)); // b = a; <-- assignment here is illegal, needs to happen in child block // *b = rand(); while(1) { b = a; // Is this legal? Assuming 'b' is not modified outside the while() block *b = rand(); } Is it legal to derive a restricted pointer value as follows: int*

问题 This question already has answers here : Why are compound literals in C modifiable (2 answers) Closed last year . In C99 we can use compound literals as unnamed array. But are this literals constants like for example 100 , 'c' , 123.4f , etc. I noticed that I can do: ((int []) {1,2,3})[0] = 100; and, I have no compilation error and is guessable that the first element of that unnamed array is modified with 100. So it seems as array as compound literal are lvalue and not constant value. 回答1: It

问题 I'm using Visual Studio 2012 to develop simple Win32 C programs. I know that the VS compiler only supports C89, but I'd like to know if there is a way to override this limitation. In particular I'd like to declare variables anywhere in my code, instead of only at the beginning of scope blocks (as C89 requires). Thanks in advance. 回答1: The choices I see: stick with MSVC and switch to C++ stick with MSVC and use a precompiler that translates C99 to C90 (Comeau, c99-to-c89) switch to a toolchain

问题 The restrict keyword's behavior is defined in C99 by 6.7.3.1: Let D be a declaration of an ordinary identifier that provides a means of designating an object P as a restrict-qualified pointer to type T. If D appears inside a block and does not have storage class extern, let B denote the block. If D appears in the list of parameter declarations of a function definition, let B denote the associated block. Otherwise, let B denote the block of main (or the block of whatever function is called at

问题 I'm used to old-style C and and have just recently started to explore c99 features. I've just one question: Will my program compile successfully if I use c99 in my program, the c99 flag with gcc and link it with prior c99 libraries? So, should I stick to old C89 or evolve? 回答1: I believe that they are compatible in that respect. That is as long as the stuff that you are compiling against doesn't step on any of the new goodies. For instance, if the old code contains enum bool { false, true };

问题 For example, If I have, int a = 42; unsigned b = 10; int c = a + b; For this statement, int c = a + b; Would a be first converted to an unsigned int or would it be b that will be converted to a signed int ? Both unsigned int and signed have the same conversion rank so how do we know which one will be converted? Is there a Standard rule? 回答1: Short answer: Per C99 6.3.1.8-p1, a s value will be converted to an unsigned int by, per C99 6.3.1.3-p2, having UINT_MAX+1 added to it until it falls in

问题 I understand that there is both an ANSI standard and an ISO standard for C. Are there any differences between these two standards? If so, what are they? And if there is not a difference then what's the point of having two standards? 回答1: In 1990, the ANSI C standard (with a few minor modifications) was adopted by the International Organization for Standardization as ISO/IEC 9899:1990. This version is sometimes called C90. Therefore, the terms "C89" and "C90" refer to essentially the same

问题 This code: #define __STDC_FORMAT_MACROS #include <inttypes.h> #include <stdio.h> #include <stdlib.h> #include <stdint.h> int main(int argc,char **argv) { uint64_t val=1234567890; printf("%"PRId64"\n",val); exit(0); } Works for C99, C++03, C++11 according to GCC 4.5, but fails on C++11 according to GCC 4.7.1. Adding a space before PRId64 lets GCC 4.7.1 compile it. Which one is correct? 回答1: gcc 4.7.1 is correct. According to the standard, c++11 2.2 Phases of translation [lex.phases] 1 - The

问题 Hi recently I saw a lot of code on online(also on SO;) like: char *p = malloc( sizeof(char) * ( len + 1 ) ); Why sizeof(char) ? It's not necessary, isn't it? Or Is it just a matter of style? What advantages does it have? 回答1: Yes, it's a matter of style, because you'd expect sizeof(char) to always be one. On the other hand, it's very much an idiom to use sizeof(foo) when doing a malloc , and most importantly it makes the code self documenting. Also better for maintenance, perhaps. If you were

问题 I'm using GCC 4.6.2 (Mingw) and compiling with -Wextra . I'm getting strange warnings whenever I use designated initializers. For the following code typedef struct { int x; int y; } struct1; typedef struct { int x; int y; } struct2; typedef struct { struct1 s1; struct2 s2[4]; } bug_struct; bug_struct bug_struct1 = { .s1.x = 1, .s1.y = 2, .s2[0].x = 1, .s2[0].y = 2, .s2[1].x = 1, .s2[1].y = 2, .s2[2].x = 1, .s2[2].y = 2, .s2[3].x = 1, .s2[3].y = 2, }; I get warnings bug.c:24:3: warning: