c99

On a 32-bit system, what does ftell return if the current position indicator of a file opened in binary mode is past the 2GB point? In the C99 standard, is this undefined behavior since ftell must return a long int (maximum value being 2**31-1 )? Ahmed Masud on long int long int is supposed to be AT LEAST 32-bits, but C99 standard does NOT limit it to 32-bit. C99 standard does provide convenience types like int16_t & int32_t etc that map to correct bit sizes for a target platform. on ftell/fseek ftell() and fseek() are limited to 32 bits (including sign bit) on the vast majority of 32-bit

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) This compiler seems not to support this (i'm unsure): MS Visual C++ PS. some C/C++ compilers are

I would like to use complex numbers as defined in C99, but I need to support compilers which do not support it (MS compilers come to mind). I don't need many functions, and implementing the needed functions on compilers without support is not too difficult. But I have a hard time implementing the 'type' itself. Ideally, I would like to do something like: #ifndef HAVE_CREAL double creal(complex z) { /* .... */ } #endif #ifndef HAVE_CREALF float creal(float complex z) { /* ... */ } #endif But I am not sure I see how to do this if the compiler cannot recognize 'float complex'. I would actually

This is some code I'm compiling on Linux: #include <net/if.h> int main() { struct ifreq ifr; } gcc test.c is fine. gcc -std=gnu99 test.c is fine. gcc -std=c99 test.c fails with the following error: test.c: In function ‘main’: test.c:4:16: error: storage size of ‘ifr’ isn’t known What's different about C99 that it doesn't like the definition of struct ifreq in Linux? It's a chain of consequences of preprocessing and GNU C vs C99. First up, net/if.h : net/if.h includes features.h Later on, it defines struct ifreq inside a #ifdef __USE_MISC block. So: What is __USE_MISC ? -- it is stuff common to

Is it a good idea to use C99 VLA? When is it appropriate to use VLA compared to malloc/free? (since VLA may blow up stack?) Yes, except in cases where you know your stack can blow up. You can also change the size of the stack if necessary, it's different how on every OS but it's possible. The advantages of VLA are: Fast : adjusting the stack pointer and/or the frame pointer would have been done anyway so the cost of a VLA is nearly 0. Easy : a simple definition, no pointer to initialize, to check to free and no risk of memory leaks. It's automatically thread safe as each thread has its own

It is nearly impossible(*) to provide strict IEEE 754 semantics at reasonable cost when the only floating-point instructions one is allowed to used are the 387 ones. It is particularly hard when one wishes to keep the FPU working on the full 64-bit significand so that the long double type is available for extended precision. The usual “solution” is to do intermediate computations at the only available precision, and to convert to the lower precision at more or less well-defined occasions. Recent versions of GCC handle excess precision in intermediate computations according to the