Mailing List Archive

GCC-4.5.2 Has Serious Problems
Hello,

After banging my head for a while over some strange results, I began
to suspect GCC-4.5.2, the latest version in portage, was creating
faulty code.

It seems to a correct suspicion.

What follows is a short C program that reproduces my particular problem,
but there are likely many other situations where GCC could fail. The code
may be a difficult for some people to follow but only the output is what
actually matters. Simpler examples will certainly exist but I have not
had the chance to develop them.

The program is included here as both in-line text and as a file attachment
(gcc_test.c). The problem is described below.

------------------------------------

#include <stdio.h>
#include <stdlib.h>

int main(void)
{
int n;
double x;
unsigned long int arg;
unsigned long int *px = (unsigned long int*)&x;

x=0.0; n=0; arg=0x4010000000000000;
while(n<5)
{

printf("%lx %g\n",arg, x);

*px=arg;

printf("%lx %g\n\n",arg, x);
n++; arg=arg+0x0010000000000000;
}

exit(0);
}

-------------------------

What this code does is not very important (it uses pointers to enter
hexadecimal values into a floating point variable within a short loop).
The output is what matters.

Compiling with "gcc -O2 -march=native -o gcc_test gcc_test.c"
produces this output:

Loop: 0
Val = 4010000000000000, X before = 0
Val = 4010000000000000, X after = 0 --> X should be 4!!!

Loop: 1
Val = 4020000000000000, X before = 0
Val = 4020000000000000, X after = 4

Loop: 2
Val = 4030000000000000, X before = 4
Val = 4030000000000000, X after = 8

The printf statements are included before and after the variable, x,
is assigned a value. Notice how in the first iteration of the loop
the x variable does *not* get assigned a value. The value of x during
the first iteration should be 4.

The problem can be fixed by compiling the program with "O1"
optimization:

gcc -O1 -march=native -o gcc_test gcc_test.c

Using "O1" the output now becomes:

Loop: 0
Val = 4010000000000000, X before = 0
Val = 4010000000000000, X after = 4 --> Now it works!!!

Loop: 1
Val = 4020000000000000, X before = 4
Val = 4020000000000000, X after = 8

Loop: 2
Val = 4030000000000000, X before = 8
Val = 4030000000000000, X after = 16

This is now the correct output. In the first iteration the X variable
is assigned the proper value.

For anyone who wants to try to duplicate these results, please feel
free to do so.

So I will have to conclude that GCC-4.5.2 has serious problems.
This kind of erroneous behavior could appear anywhere.

Frank Peters
Re: GCC-4.5.2 Has Serious Problems [ In reply to ]
Frank Peters writes:

> After banging my head for a while over some strange results, I began
> to suspect GCC-4.5.2, the latest version in portage, was creating
> faulty code.
>
> It seems to a correct suspicion.
[...]

> The problem can be fixed by compiling the program with "O1"
> optimization:

Or -O3.


> For anyone who wants to try to duplicate these results, please feel
> free to do so.
>
> So I will have to conclude that GCC-4.5.2 has serious problems.
> This kind of erroneous behavior could appear anywhere.

Oh dear, that's scary. I can confirm this. With -O0, -O1 and -O3, all is
fine. -O2 gives the result you see. And with -Os, I get yet another
result (0/0, 4/4, 8/8).

This is an AMD Athlon(tm) Dual Core Processor 4850e, gcc has been
copmpiled with these use flags: fortran gtk mudflap multilib nls nptl openmp

Who will file the bug report now?

Wonko
Re: GCC-4.5.2 Has Serious Problems [ In reply to ]
On Fri, 01 Jul 2011 00:30:57 +0200
Alex Schuster <wonko@wonkology.org> wrote:

>
> Who will file the bug report now?
>

Thanks for the confirmation.

GCC-4.5.2, some may claim, is already old hat. I just tried
the same experiment using GCC-4.6.0 and there is no problem.
The program works with "O2" optimization. So I will be using
GCC-4.6.0 from now on.

But the problem does deserve some looking into, I would think.

Frank Peters
Re: GCC-4.5.2 Has Serious Problems [ In reply to ]
On 07/01/2011 12:45 AM, Frank Peters wrote:
> Hello,
>
> After banging my head for a while over some strange results, I began
> to suspect GCC-4.5.2, the latest version in portage, was creating
> faulty code.
>
> It seems to a correct suspicion.
>[...]
> int n;
> double x;
> unsigned long int arg;
> unsigned long int *px = (unsigned long int*)&x;

Your code is buggy, because you're breaking C's aliasing rules. You are
not allowed to use a different pointer type to dereference a variable of
a different type. Doing so results in undefined behavior.

Short answer, GCC is correct, you are wrong :-) To compile code that
breaks aliasing rules, always use the "-fno-strict-aliasing" option. In
this case:

gcc -O2 -fno-strict-aliasing
Re: GCC-4.5.2 Has Serious Problems [ In reply to ]
On 07/01/2011 02:35 AM, Nikos Chantziaras wrote:
> On 07/01/2011 12:45 AM, Frank Peters wrote:
>> Hello,
>>
>> After banging my head for a while over some strange results, I began
>> to suspect GCC-4.5.2, the latest version in portage, was creating
>> faulty code.
>>
>> It seems to a correct suspicion.
>> [...]
>> int n;
>> double x;
>> unsigned long int arg;
>> unsigned long int *px = (unsigned long int*)&x;
>
> Your code is buggy, because you're breaking C's aliasing rules. You are
> not allowed to use a different pointer type to dereference a variable of
> a different type. Doing so results in undefined behavior.

And here you can read more thorough information about strict aliasing:

http://labs.qt.nokia.com/2011/06/10/type-punning-and-strict-aliasing
Re: Re: GCC-4.5.2 Has Serious Problems [ In reply to ]
On Fri, 01 Jul 2011 02:44:36 +0300
Nikos Chantziaras <realnc@arcor.de> wrote:

> >
> > Your code is buggy, because you're breaking C's aliasing rules. You are
> > not allowed to use a different pointer type to dereference a variable of
> > a different type. Doing so results in undefined behavior.
>

Well, the error occurs only within the loop structure. If
I manually "unroll" the loop using the same pointers there
is no error when compiled with "O2."

IOW, the problem is how the loop is optimized under -O2.

Frank Peters
Re: GCC-4.5.2 Has Serious Problems [ In reply to ]
On 07/01/2011 03:04 AM, Frank Peters wrote:
> On Fri, 01 Jul 2011 02:44:36 +0300
> Nikos Chantziaras<realnc@arcor.de> wrote:
>
>>>
>>> Your code is buggy, because you're breaking C's aliasing rules. You are
>>> not allowed to use a different pointer type to dereference a variable of
>>> a different type. Doing so results in undefined behavior.
>>
>
> Well, the error occurs only within the loop structure. If
> I manually "unroll" the loop using the same pointers there
> is no error when compiled with "O2."
>
> IOW, the problem is how the loop is optimized under -O2.

When there's "undefined behavior", it really means just that: you cannot
make any assumptions about when the result is going to be correct and
when not. It might as well depend on whether it was raining yesterday.
Re: Re: GCC-4.5.2 Has Serious Problems [ In reply to ]
On Fri, 01 Jul 2011 02:44:36 +0300
Nikos Chantziaras <realnc@arcor.de> wrote:

> >> unsigned long int *px = (unsigned long int*)&x;

> And here you can read more thorough information about strict aliasing:
>
> http://labs.qt.nokia.com/2011/06/10/type-punning-and-strict-aliasing
>

Thanks for this link. I can see what's happening now.

These types of pointers are admittedly unusual, but it's the only
quick way I know to load a double variable with a certain bit pattern,
or to convert big/small endian values, etc. I ordinarily don't do these
things, but when I do I 'll keep this aliasing in mind.

Frank Peters
Re: GCC-4.5.2 Has Serious Problems [ In reply to ]
Nikos Chantziaras posted on Fri, 01 Jul 2011 03:11:09 +0300 as excerpted:

> On 07/01/2011 03:04 AM, Frank Peters wrote:
>> On Fri, 01 Jul 2011 02:44:36 +0300 Nikos Chantziaras<realnc@arcor.de>
>> wrote:
>>
>>
>>>> Your code is buggy, because you're breaking C's aliasing rules. You
>>>> are not allowed to use a different pointer type to dereference a
>>>> variable of a different type. Doing so results in undefined behavior.
>>>
>>>
>> Well, the error occurs only within the loop structure. If I manually
>> "unroll" the loop using the same pointers there is no error when
>> compiled with "O2."
>>
>> IOW, the problem is how the loop is optimized under -O2.
>
> When there's "undefined behavior", it really means just that: you cannot
> make any assumptions about when the result is going to be correct and
> when not. It might as well depend on whether it was raining yesterday.

I had wondered if this might be an "undefined behavior" optimization bug,
but don't personally know enough about C coding to tell.

However, what I have observed, both here and for instance in the recent
glibc memcp vs memmove instructions (don't ask me if those are
abbreviated correctly, I'm not a coder, just a user who followed the
situation as reported in the community press with some interest,
particularly because I DO tend to unmask and try new versions with such
issues before they're officially ready), is that in the quest for further
optimizations, all the "easy" stuff is pretty much already done. It's
now the harder, more obscure optimizations that might break code making
bad assumptions about "undefined behavior", etc, that's the leading edge
of technology, at least as seen in the FLOSS world encompassing gcc and
glibc.

The -fno-strict-aliasing thing was a big deal for gcc 4.5, precisely
because it DOES allow corner-case optimization where it wasn't tried
before, but does so by taking advantage of "undefined behavior" being
just that, undefined, to make assumptions about shortcuts the authors did
NOT take because to do so would be undefined, based on the absence of a
flag saying NOT to make such assumptions because the author DID take such
shortcuts, relying on the previous behavior where it is specifically
defined as "undefined".

As it happens, there was quite a lot of code making such assumptions,
that needed -fno-strict-aliasing in the short term, but hopefully,
recoded not to make invalid assumptions about the behavior of
specifically "undefined behavior" in the longer term.

It's just that sort of testing, bug reporting, and patching, that keeps
gentoo devs (and indeed, those of many distributions) busy, as new
versions of gcc and various system libraries come out, and why at times
they seem to take "forever" to stabilize, or even get unmasked into ~arch
(where gcc-4.6 has yet to appear, fwiw).

FWIW, I don't know a whole lot about fixing such things in the C/C++/
whatever code itself, but I've developed quite some experience finding
and applying patches from bugzilla, etc, that haven't made their way into
any package version available in the tree for negatively affected
packages that I use, yet, as I do frequently package.unmask new gccs,
etc, before they're officially unmasked, which generally takes place
after those patches have actually made it into in-tree versions... which
can be quite some time!

gcc-config helps as it makes it quite easy to switch between versions for
specific packages, but OTOH, that doesn't always help with for instance
kde, when cmake is built with and depends on the newer gcc, but one of
the kde packages trying to build with cmake is still broken with the
newer gcc. Switch to the newer gcc and you can't compile the broken-with-
it package, switch to the older one and cmake is broken, so you /still/
can't compile the package! If that occurs after you've already rebuild
90% of the system including 80% of kde with the new version... and it
DOES have you pulling your hair out! Been there! Done that! Which is
why I've not tried gcc 4.6 yet, tho I'm getting restless and beginning to
consider it.

So expect more of this type of thing as the gcc and glibc optimizers try
to squeeze ever more performance out of their optimizations, because all
the "safe" optimizations have been had, and they're deep into "undefined
behavior" territory now, taking advantage of the fact that it's undefined
to change it here and there, thus eking out yet another corner-case
optimization, whilst ensuring the gentoo devs don't run out of things to
do, ensuring compatibility of old code with new compiler and system
library versions. =:^]

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
Re: Re: GCC-4.5.2 Has Serious Problems [ In reply to ]
On Fri, 01 Jul 2011 02:44:36 +0300
Nikos Chantziaras <realnc@arcor.de> wrote:

>
> And here you can read more thorough information about strict aliasing:
>
> http://labs.qt.nokia.com/2011/06/10/type-punning-and-strict-aliasing
>

You've saved the day in more ways than one.

A few days ago I posted about a possible problem with a floating
point test called the UCBTEST. After examining the source code
of this test, I see violations of aliasing rules throughout.
It's hard to efficiently manipulate variables without them.

Of course, this code was written before the C99 standard and
so is exempt. But the use of "-fno-strict-aliasing" will
apply with the UCBTEST as well.

Thanks again for the information.

Frank Peters
Re: Re: GCC-4.5.2 Has Serious Problems [ In reply to ]
On Fri, 1 Jul 2011 00:58:46 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

>
> I had wondered if this might be an "undefined behavior" optimization bug,
>

Well, the amd64 users list may not be the appropriate place to discuss
C programming, but the problem here stems from attempting to do things
with C that are not supposed to be done with C. Such things are aptly
called "tricks" because they stray away from the convention.

Ideally, I suppose, for these purposes would be to use assembly language
routines mixed into the C code. But this is not as easy as with the
"tricks."

Anyway, I'm glad I presented this issue. It has definitely improved
my understanding. GCC has dozens, if not hundreds, of compile options
and I know the actual function of only a small few.

Frank Peters
Re: GCC-4.5.2 Has Serious Problems [ In reply to ]
Frank Peters posted on Thu, 30 Jun 2011 21:23:21 -0400 as excerpted:

> Anyway, I'm glad I presented this issue. It has definitely improved my
> understanding. GCC has dozens, if not hundreds, of compile options and
> I know the actual function of only a small few.

Indeed. The gcc manpage is a veritable treasure-trove of interesting
options, even (especially?) for those who who don't know C but either
aspire to be or already consider themselves Gentoo power-users.

And this sort of issue discussion is perfect for a gentoo list, as even
for those who don't really understand it, it provides a glimpse into the
sorts of things gentoo devs must deal with on a daily basis (yes, I guess
that is sort of repeating the point I made before, but it's true).

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
Re: Re: GCC-4.5.2 Has Serious Problems [ In reply to ]
On Fri, 1 Jul 2011, Frank Peters wrote:

> On Fri, 1 Jul 2011 00:58:46 +0000 (UTC)
> Duncan <1i5t5.duncan@cox.net> wrote:
>
>>
>> I had wondered if this might be an "undefined behavior" optimization bug,
>>
>
> Well, the amd64 users list may not be the appropriate place to discuss
> C programming, but the problem here stems from attempting to do things
> with C that are not supposed to be done with C. Such things are aptly
> called "tricks" because they stray away from the convention.

I don't think that is true - C has ALWAYS had rules on strict aliasing,
even from the first attempts at standardization.

Unfortunately it is only recently that common compilers and hardware have
really taken advantage of the way the language works to give better
optimizing performance by storing more variables in registers rather than
reloading pointers from memory every time. Mostly this is due to the
small number of registers in the x86 architecture, doesn't lend itself to
these optimisations as well as other architectures. Contrast with Itanium
for example with lots of registers, some of which are designed to be
preserved across a function call. FORTRAN compilers have taken advantage
of aliasing optimizations right from the beginning (ie, since the
1960's!), and commodity C compilers are only now just catching up! So
these are hardly new optimizations.

>
> Ideally, I suppose, for these purposes would be to use assembly language
> routines mixed into the C code. But this is not as easy as with the
> "tricks."

Not at all, it is about producing more efficient assembly, using the
language rules that have existed practically forever. If programmers have
become accustomed to violating those rules, then they'll just have to get
accustomed to not violating them. The rules aren't hard! And if you DO
want to alias pointers of different types, then there are well-defined
ways of doing that, and the resulting code tends to be much more readable
too.

Regards,
Ian
Re: GCC-4.5.2 Has Serious Problems [ In reply to ]
Frank Peters posted on Thu, 30 Jun 2011 21:04:29 -0400 as excerpted:

> On Fri, 01 Jul 2011 02:44:36 +0300 Nikos Chantziaras <realnc@arcor.de>
> wrote:
>
>> And here you can read more thorough information about strict aliasing:
>>
>> http://labs.qt.nokia.com/2011/06/10/type-punning-and-strict-aliasing
>>
> You've saved the day in more ways than one.
>
> A few days ago I posted about a possible problem with a floating point
> test called the UCBTEST. After examining the source code of this test,
> I see violations of aliasing rules throughout. It's hard to efficiently
> manipulate variables without them.
>
> Of course, this code was written before the C99 standard and so is
> exempt. But the use of "-fno-strict-aliasing" will apply with the
> UCBTEST as well.

Truthfully, I thought sure this was a direct follow-on to that! So I'm
happy to see that the same cause and solutions apply. =:^)

As I said in an earlier post, tho, expect there to be more problems like
that with code of that age as time goes on, because they're well past the
easy optimizations now, and into stuff like this. So it may be wise to
keep an eye out and test the minor gcc version bumps with an eye toward
such issues. They generally put out a porting guide, etc, with the new
version, that you can read for clues in case the tests start doing
unexpected things again.

(If you pay attention to flameeyes' blog, he tends to cover such things
reasonably early on after release of a new gcc version as well, as he
does tinderbox runs to see how bad the interaction of the new version is
with the current gentoo ~arch tree as a whole and eventually to test that
the latest ~arch packages are updated or patched to fix the problem,
before that gcc version gets unmasked to ~arch. By no means do I agree
with everything he says, but he really is an asset to gentoo and would be
sorely missed should one of his sick episodes make it impossible for him
to continue, or if he simply decided he had better things to do with his
time. The switch to --as-needed in Gentoo's default ldflags was largely
due to his work, explaining the issues for other devs, testing and filing
bugs, helping with the hard cases, and in general pushing it until it
happened, for instance, and every single gentoo user benefits from that
in the form of less mandatory rebuilds, every time they update. It may
well have happened without him, but it might have taken a decade longer,
too. And because gentoo devs normally push those patches upstream where
they can, that has been a benefit to the entire FLOSS community, not just
gentoo, as well, reducing "dependency hell" for everyone.)

--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
Re: Re: GCC-4.5.2 Has Serious Problems [ In reply to ]
Frank Peters <frank.peters@comcast.net> skribis:
> A few days ago I posted about a possible problem with a floating
> point test called the UCBTEST. After examining the source code
> of this test, I see violations of aliasing rules throughout.
> It's hard to efficiently manipulate variables without them.

C is essentially a glorified assembly language for PDP-11, designed
for bit-twiddling, which the original K&R book encouraged, and which
this code is doing. So all is well, from my point of view. :) Fancy
optimizations are not to be trusted on assembly code; never be afraid
to turn them off. You probably don’t need them, anyway. :)
Re: Re: GCC-4.5.2 Has Serious Problems [ In reply to ]
On Fri, 1 Jul 2011, Frank Peters wrote:

> On Fri, 1 Jul 2011 00:58:46 +0000 (UTC) Duncan <1i5t5.duncan@cox.net>
> wrote:
>
> >
> > I had wondered if this might be an "undefined behavior" optimization
> > bug,
> >
>
> Well, the amd64 users list may not be the appropriate place to discuss C
> programming, but the problem here stems from attempting to do things
> with C that are not supposed to be done with C. Such things are aptly
> called "tricks" because they stray away from the convention.

I don't think that is true - C has ALWAYS had rules on strict aliasing,
even from the first attempts at standardization.

Unfortunately it is only recently that common compilers and hardware have
really taken advantage of the way the language works to give better
optimizing performance by storing more variables in registers rather than
reloading pointers from memory every time. Mostly this is due to the
small number of registers in the x86 architecture, doesn't lend itself to
these optimisations as well as other architectures. Contrast with Itanium
for example with lots of registers, some of which are designed to be
preserved across a function call. FORTRAN compilers have taken advantage
of aliasing optimizations right from the beginning (ie, since the
1960's!), and commodity C compilers are only now just catching up! So
these are hardly new optimizations.

>
> Ideally, I suppose, for these purposes would be to use assembly language
> routines mixed into the C code. But this is not as easy as with the
> "tricks."

Not at all, it is about producing more efficient assembly, using the
language rules that have existed practically forever. If programmers have
become accustomed to violating those rules, then they'll just have to get
accustomed to not violating them. The rules aren't hard! And if you DO
want to alias pointers of different types, then there are well-defined
ways of doing that, and the resulting code tends to be much more readable
too.

Regards,
Ian
Re: Re: GCC-4.5.2 Has Serious Problems [ In reply to ]
On Thu, 30 Jun 2011 21:22:39 -0500
Barry Schwartz <chemoelectric@chemoelectric.org> wrote:

>
> C is essentially a glorified assembly language
>

IMO, that's why C is the best. It is very close to the machine
and the programmer has to be very attentive to details of hardware
as well as to software concepts.

> for bit-twiddling, which the original K&R book encouraged, and which
> this code is doing. So all is well, from my point of view. :)

Bit manipulations on integers and strings are natural. The difficulty
is with floating point variables which are not just bits but also
a complex format that does not respect byte boundaries. The ordinary bit
operators cannot apply to floating point. The only way to ordinarily get
data in/out is to use the built-in conversion routines. The language was
never designed, AFAIK, to directly manipulate floating point bits.

> Fancy
> optimizations are not to be trusted on assembly code; never be afraid
> to turn them off. You probably don’t need them, anyway. :)
>

Certainly true. But in this case, -fno-strict-aliasing is absolutely
necessary.

Also, I, as probably most others, would rather not concentrate so much
on the compiler as on the task of coding itself.

Frank Peters
Re: Re: GCC-4.5.2 Has Serious Problems [ In reply to ]
On Thu, Jun 30, 2011 at 6:23 PM, Frank Peters <frank.peters@comcast.net> wrote:
> On Fri, 1 Jul 2011 00:58:46 +0000 (UTC)
> Duncan <1i5t5.duncan@cox.net> wrote:
>
>>
>> I had wondered if this might be an "undefined behavior" optimization bug,
>>
>
> Well, the amd64 users list may not be the appropriate place to discuss
> C programming, but the problem here stems from attempting to do things
> with C that are not supposed to be done with C.  Such things are aptly
> called "tricks" because they stray away from the convention.
>
> Ideally, I suppose, for these purposes would be to use assembly language
> routines mixed into the C code.  But this is not as easy as with the
> "tricks."
>
> Anyway, I'm glad I presented this issue.  It has definitely improved
> my understanding.  GCC has dozens, if not hundreds, of compile options
> and I know the actual function of only a small few.
>
> Frank Peters
>
>

I think it's completely appropriate for this list. This distro expects
that we put CFLAG options in make.conf so I need to hear about this
stuff even if I don't have to background to completely understand
what's really causing the problem.

- Mark
Re: Re: GCC-4.5.2 Has Serious Problems [ In reply to ]
On Thu, 30 Jun 2011 21:36:38 -0700
Mark Knecht <markknecht@gmail.com> wrote:

>
> I think it's completely appropriate for this list. This distro expects
> that we put CFLAG options in make.conf so I need to hear about this
> stuff even if I don't have to background to completely understand
> what's really causing the problem.
>

In this case, or in the case of any program where "-fno-strict-aliasing"
could make a difference, the maintainer of the program would include
the option in the ebuild. The user would not have to worry too much
about it.

But yes, it is always good to know about the compiler flags.

To see exactly what compile flags are being used in your programs, here
is a neat method I picked up from somewhere. Just open a terminal and
enter the following command:

echo 'int main(){return 0;}' > test.c && gcc -v -Q $CFLAGS test.c -o test && rm test.c test

In place of $CFLAGS just substitute any option of interest. There will
be a flood of output, but just scroll back a few lines to find the "options
passed:" and "options enabled:" sections.

For example, using "-O2" for $CFLAGS indicates that "-fstrict-aliasing" is
used, but it is not used with "-O1."

It also shows that with "-O2" the option "-mno-sse4" is used, and so if
you want to use SSE4 for certain programs (e.g. video, audio) you will
need to specifically enable it.

There may be an even slicker way to reveal the flags, but this is the
only way I know.

Frank Peters
Re: GCC-4.5.2 Has Serious Problems [ In reply to ]
On 07/01/2011 04:04 AM, Frank Peters wrote:
> A few days ago I posted about a possible problem with a floating
> point test called the UCBTEST. After examining the source code
> of this test, I see violations of aliasing rules throughout.
> It's hard to efficiently manipulate variables without them.

You can alias them with a char* (a char pointer can alias everything in
a valid and defined manner). What you do is use the char* to scan over
the target type. And since a char is always guaranteed to be 8 bits,
it's very suited for doing endian conversions.
Re: Re: GCC-4.5.2 Has Serious Problems [ In reply to ]
On Fri, 01 Jul 2011 14:53:45 +0300
Nikos Chantziaras <realnc@arcor.de> wrote:

>
> You can alias them with a char* (a char pointer can alias everything in
> a valid and defined manner). What you do is use the char* to scan over
> the target type. And since a char is always guaranteed to be 8 bits,
> it's very suited for doing endian conversions.
>

Yes, that's true, but in my case another concern was having data
that is more easily human readable. A text file full of single-byte
data is harder to read than a file with full 64 or 32 bit strings.

For endian conversions, though, the char pointer is recommended.

But with the availability of the "-fno-strict-aliasing" option it
doesn't seem to matter which method is chosen.