problem about strict-aliasing-Record and share programming errors

  • curiousguy
    c++ floating-point bits strict-aliasing type-punning
    I am trying to extract the bits from a float without invoking undefined behavior. Here is my first attempt:unsigned foo(float x) {unsigned* u = (unsigned*)&x;return *u; }As I understand it, this is not guaranteed to work due to strict aliasing rules, right? Does it work if a take an intermediate step with a character pointer?unsigned bar(float x) {char* c =

  • curiousguy
    c++ casting reinterpret-cast strict-aliasing type-punning
    I’ve been reading about strict aliasing quite a lot lately. The C/C++ standards say that the following code is invalid (undefined behavior to be correct), since the compiler might have the value of a cached somewhere and would not recognize that it needs to update the value when I update b;float *a; … int

  • curiousguy
    c++ c unions strict-aliasing type-punning
    In the comments of this answer it is said that it would be undefined behavior to split up an integer into their bytes using a union like follows. The code given at that place is similar though not identical to this, please give a note if have I changed undefined-behavior-relevant aspects of the code.union addr {uint8_t addr8[4];uint32_t addr32; };Up to now I thought this would be a fine approach to do things like addr = {127, 0, 0, 1}; and get the corr

  • curiousguy

  • brofield
    optimization gcc strict-aliasing
    Close: The problem was the use of a pointer to a stack variable that had gone out of scope. Nothing to do with optimization. Pity that valgrind can’t find stack errors…I have a segfault that appears only when enabling -O1 level optimization in gcc 4.4.4 (CentOS 5.5). All other optimization levels (0,2,3,s) are fine. I haven’t managed to create a reduced test case for it yet, but it appears to be related to an arra

  • curiousguy
    c++ c unions strict-aliasing type-punning
    I was working and was considering using a union. I decided against it, because the design really called for a struct/class, but it eventually lead to the following hypothetical question:Suppose you have a union like this contrived example:typedef union {char* array_c;float* array_f;int* array_i; } my_array;. . . and then you allocate one of th

  • R..
    c arrays undefined-behavior strict-aliasing
    One of the examples of undefined behavior from the C standard reads (J.2):— An array subscript is out of range, even if an object is apparently accessible with thegiven subscript (as in the lvalue expression a[1][7] given the declaration inta[4][5]) (6.5.6)If the declaration is changed fro

  • Zaibis
    c sockets gcc strict-aliasing
    Im asking my self, can i use the BSD sockets with strict aliasing on, without getting undefined behaviour by compiling with gcc?bind(sdL

  • Zaibis
    c c99 undefined-behavior pointer-arithmetic strict-aliasing
    I’m working now for some weeks with c99 focusing undefined behaviour. I wanted to test some strange code while trying to respect the rules. The result was this code:(plz forgive me the variable names, i had eaten a clown)int main(int arg, char** argv) {unsigned int uiDiffOfVars;int LegalPointerCast1, LegalPointerCast2, signedIntToRespectTheRules;char StartVar;//Only use to have an adress from where we can move onchar *TheAccesingPointer;int iTargetOfPointeracces;iTargetOfPointeracces= 0x55555555;TheAccesingPointer = (char *) &StartVar;LegalPointerCast2 = (int) &StartVar;LegalPointerCast1 = (int) &iTargetOfPointeracces;if ((0x80000000 & LegalPointerCast2) != (0x80000000 & LegalPoi

  • Gerasimos R
    c++ unions strict-aliasing
    I know that for the code below, “Illegal” below is undefined (while some compilers allow it), because union member “a” is active, and then we read from union member “b”. The question is, does the code in “AmILegal” fix it, or am I doing something scary and even more obscure? Can I use memcpy to achieve the same effect or is there another undefined behaviour I am invoking there?EDIT: Maybe the examp

  • Framester
    c optimization gcc pointers strict-aliasing
    I used the following piece of code to read data from files as part of a larger program.double data_read(FILE *stream,int code) {char data[8];switch(code) {case 0x08:return (unsigned char)fgetc(stream);case 0x09:return (signed char)fgetc(stream);case 0x0b:data[1] = fgetc(stream);data[0] = fgetc(str

  • timrau
    c gcc type-conversion unions strict-aliasing
    Do you have any horror stories to tell? The GCC Manual recently added a warning regarding -fstrict-aliasing and casting a pointer through a union:[…] Taking the address, casting the resulting pointer and dereferencing the result has undefined behavior [emphasis added], even if the cast uses a union type, e.g.:union a_union {int i;double d;};int f() {double d = 3.0;return ((union a_union *)&d)->i;}Does anyone have an example to illustrate this undefined behavior?Note this question is not about what the C99 standard says, or does not say. It is about the actual functioning of gcc, and other existing compilers, today.I am only guessing, but one potential problem may lie in the setting of d to 3.0. Because d is a temporary variable which is never directly read, and which is never read via a ‘somewhat-compatible’ pointer, the compiler may not bother to se

  • curiousguy

  • meagar
    c pointers casting c99 strict-aliasing
    This is the fast inverse square root implementation from Quake III Arena:float Q_rsqrt( float number ) {long i;float x2, y;const float threehalfs = 1.5F;x2 = number * 0.5F;y = number;i = * ( long * ) &y; // evil

  • Mankarse
    c const language-lawyer strict-aliasing
    Does the following code in C have defined behavior?int main() {const int i = 0;return *(int*)(&i); }I ask because 6.5/7 lists “a qualified version of a type compatible with the effective type of the object” as a valid alias. But the effective type of the object is const int, and I don’t think int is a qualified version of const int (although the reverse is true). Neither are int a

  • Leonid

Originally posted 2013-08-31 08:08:01.