c99

First, here is what I understand and think what is true for the question. Use fast data types for single variables like counters or for loop indexes. For example: #define LOOP_COUNT (100U) uint_fast8_t index; for(index = 0; index < LOOP_COUNT; index++){ /* Do something */ } I suppose the most suitable type in here is uint_fast8_t since index can never exceed 255 and this will be the fastest implementation for all platforms. If I used unsigned int instead, it will be fastest in >=16 bits platforms but will be slower in <16 bits platforms as int is 16 bits minimum by standard. Also, if I used

I've recently learned how to program simple character drivers and while playing around with the code I noticed that I get a lot of the following GCC warnings thrown for my C99 code: warning: ISO C90 forbids mixed declarations and code I assume this is because the main Linux kernel Makefile is set to compile using a non-C99 standard. I searched around I found this answer here on stackoverflow: How to use make and compile as C99? So I naturally tried the following in my Makefile: ccflags-y := -std=gnu99 Unfortunately this didn't silence the GCC warnings. I checked the verbose output of make and

Speaking of string literals, the C99 standard says (6.4.5.6): It is unspecified whether these arrays are distinct provided their elements have the appropriate values. If the program attempts to modify such an array, the behavior is undefined. I couldn't find either a similar warning or an explicit guarantee for const variables. Can the expression &x == &y in the context const int x=12; const int y=12; evaluate to 1 ? What about a const variable and a string literal (i.e. is &x == "\014\000\000" guaranteed to be 0 even on a 32-bit little-endian platform)? For what it's worth, the section

I work on a code base which is mostly C with a little C++, and is mostly built with gcc but occasionally it needs to be built with MSVC. Microsoft's C compiler is still pretty much C89 with a few minor extensions, and it still doesn't support mixed code and variable definitions à la C++/C99. So I need to find a way to prevent developers from writing out-of-order code/variable definitions while they are working with gcc, otherwise the build subsequently breaks with MSVC. If I use gcc -std=c89 then everything breaks because C++-style comments are not allowed (there may be other issues too, but I

I have an API with a publicly facing struct A and an internal struct B and need to be able to convert a struct B into a struct A. Is the following code legal and well defined behavior in C99 (and VS 2010/C89) and C++03/C++11? If it is, please explain what makes it well-defined. If it's not, what is the most efficient and cross-platform means for converting between the two structs? struct A { uint32_t x; uint32_t y; uint32_t z; }; struct B { uint32_t x; uint32_t y; uint32_t z; uint64_t c; }; union U { struct A a; struct B b; }; int main(int argc, char* argv[]) { U u; u.b.x = 1; u.b.y = 2; u.b.z

I'm trying to compile a linux kernel module using a Makefile: obj-m += main.o all: make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules clean: make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean Which gives me: main.c:54: warning: ISO C90 forbids mixed declarations and code I need to switch to C99. After reading I noticed I need to add a flag -std=c99, not sure where it suppose to be added. How do I change the Makefile so it will compile as C99? It's got nothing to do with the makefile. ISO C90 forbids declaring variables anywhere but in the beginning of a block or the file -

In the 3.0.4 Linux kernel, mm/filemap.c has this line of code: retval = retval ?: desc.error; I've tried compiling a similar minimal test case with gcc -Wall and don't get any warnings; the behavior seems identical to: retval = retval ? retval : desc.error; Looking at the C99 standard, I can't figure out what formally describes this behavior. Why is this OK? As several others have said, this is a GCC extension, not part of any standard. You'll get a warning for it if you use the -pedantic switch. The point of this extension is not really visible in this case, but imagine if instead it was