RE: The joy of type aliasing and C

Brian Hook <[email protected]>
Newsgroups gmane.games.devel.general
Message-ID <2003122813236.894920@GATEWAY>
> a pretty fruitless exercise. If you really want binary
> compatibility, then you have to accept that the basic types will
> have to be the same on all platforms, and that's something they are
> not prepared to accept, as it will hurt performance on non-
> conforming systems.

Spot on.  And I don't mind that a lot of operations are undefined or 
implementation defined, but what bothers me is the head-in-the-sand 
"we don't talk about these things" attitude.  It is pretty much 
impossible to write a portable C program that does anything useful.

> If the standards committee wanted to be actually helpful, they
> would have specified exceptions to these rules, such as: when the
> two types have identical size and alignment, type punning is well-
> defined.

Actually, if they had simply made it "implementation defined" with 
some caveats, that would have helped, because in practice this is all 
implementation defined and not truly "undefined".  "Undefined" has 
connotations of causing your computer to explode.

> The real insult is that idioms like *(int *)&f are commonly used,
> and generally handled as expected (by users not the standard) by
> most compilers. 

SHHHHHHHHHHHH!

> This is a case where the real standard is the
> standard which actually exists in practice and not the standard
> that some academics have made up.

Well, I wouldn't go that far, because in reality there are too many 
areas where what works in practice WILL explode on other systems.  The 
x86 has made this an unfortunate problem.

A common example is:

struct foo
{
   char b; /* assume tight packing */
   int  x;
};

char buffer[ 1024 ];
struct foo *f = ( struct foo * ) buffer;
int y;

fread( fp, buffer, 1, sizeof( buffer ) );

y = f->x; /* misaligned access, fine on x86, crashes on, say, SPARC */

So I understand their rather dogmatic desire to make sure everyone 
follow the rules, but I don't like the attitude that "writing real 
software is unclean, even if you know what rules you're breaking".

But I digress...the one thing I can definitely say I've taken away 
from this is that when someone yells at me for type-alias violation, 
I'll just turn around and say that code is undefined and therefore 
THEY'RE WRONG TOO, HAH! =)

Anyway, near as I can tell, if you want the int bits, and you can 
ASSUME that sizeof( float ) == sizeof( int ) and you can ASSUME a 
certain endianess, then the following should work no matter what:

float f = 1.0f;
int i = 0;
unsigned char *c = ( unsigned char * ) &f;

if ( sizeof( f ) ! = sizeof( i ) )
   explode();
/* do some endianess verification as well */
..
..
..
i = ( c[ 0 ] << 24 ) | ( c[ 1 ] << 16 ) | ( c[ 2 ] << 8 ) | ( c[ 3 ] 
);

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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.