RE: The joy of type aliasing and C

   I don't know about C99, but the C++ standard simply states that the
compiler is allowed to assume that there no aliasing between pointers of two
different types. This means that in the following snippet, the value of 'i'
may be different depending on how aggressive the compiler is when
optimising:

  float f = 0.0f;
  int* ip = (int*) f;

  *ip = 2345;
  f = 4532.3f;
  int i = *ip;

   This is a real issue that could cause very strange bugs on various
platforms (PS2 is the most common target where this can pop up).

   However, as I said I am unsure about C. I don't think it has this rule as
it's been touted as one reason why C++ code can actually be quicker than C
code. C99 introduces restricted pointers which allow the same thing but I
believe you have to hint the compiler explicitly rather than relying on a
semi-obscure language rule.

/Stef!
--
Stefan Boberg
CTO @ Digital Illusions CE



-----Original Message-----
From: Brian Hook [mailto:[email protected]] 
Sent: den 26 december 2003 19:04
To: [email protected]
Subject: [GD-General] The joy of type aliasing and C

About a year and a half ago there was a fairly major brouhaha on the 
algorithms list about this line of code:

int x = * ( int * ) &somefloat;

Now, let's push aside endianess and size issues, the concern was that 
since there was "type-aliasing" that Something Bad could happen.  
Something Bad, of course, being a rather ambiguous statement.

I'm aware of all the bad things that can happen if you have 
type-aliasing in conjunction with pointer aliasing, which is related, 
but that one line above doesn't seem like it should be bad _with a 
legal C compiler_.

The major concern are optimizations that the compiler may make that 
affect order.  For example:

somefloat = 1.0f;
x = * ( int * ) &somefloat;

In theory, a heavily optimizing C compiler would see that the 
assignment to somefloat should not affect the assignment to x since 
they are incompatible types, which may allow it to decide to assign to 
somefloat _after_ the assignment to x.

But that would be illegal.  The C specification states that the end of 
every expression is a sequence point, and thus the assignment to 
somefloat MUST be flushed before any subsequent statements are 
executed.

So, I can buy that the aliasing thing is a serious concern if there is 
concern about a C compiler aggressively optimizing and doing it 
incorrectly, but that doesn't seem to be the argument.

Of course, granted, using a union makes more sense and is a bit 
cleaner, I'm fine with that:

union 
{
   int i;
   float somefloat;
} u;

u.somefloat = 1.0f;
x = u.i;

But according to the C standard, the above is undefined ("If the value 
being stored in an object is accessed from another object that 
overlaps in any way the storage of the first object, then the overlap 
shall be exact and the two objects shall have qualified or unqualified 
versions of a compatible type; otherwise, the behavior is  
undefined.").

Anyone have something more authoritative on this issue?

Brian




-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click
_______________________________________________
Gamedevlists-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_idU7


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Gamedevlists-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gamedevlists-general
Archives:
http://sourceforge.net/mailarchive/forum.php?forum_id=557