This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: An alias bug

  In message <>you write:
  > I see this come up now and again, so I'm finally going to ask.
  > How do we tell users they can take one type, and look at "pieces" of
  > it, when they use gcc?  Or are you saying that we declare "long long"
  > as a special case in this regard?
Put them in a union and extract elements from the union.

Or use memcpy to extract the bits from one thing and put them in another
of a different type.  

Or claim one of the  things is volatile.

HJ's testcase basically as a useless cast to try and trip the "bug".
you can remove the whole ((long_long_type *)&u)->l[1] and replace it
with just (u & 0xffffffff).  Actually HJ's testcase could just as
easily fail with gcc-2.7 since the "bug" it's trying to trigger exists
there too.

  > There is a lot of legacy code out there which does this.  One example
  > is the "portable" generic IP networking checksum function provided in
  > the BSD networking sources.
There's less and less of this code IMHO -- modern compilers have been
doing this kind of alias analysis for some time and as a result folks
have been forced to fix their code.  Of course this doesn't apply to
Linux and some other free software projects since they only use gcc.

  > If we now say "such code is bogus", we better have a game plan as to
  > what we tell these people who have similar code which have worked for
  > many years yet now barfs just like hj's test case.
Point them to the C standard :-) :-)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]