Another Unaligned Access/Code Generation Question

[Maciej W. Rozycki]

On Thu, 22 May 2008, Jay Estabrook wrote:

> It is located in code whose name, according to GDB, is:
> 
> _ZNK14QLocalePrivate14doubleToStringEdiNS_10DoubleFormEij
> 
> And yes, that is almost certainly in C++ code... ;-}

QLocalePrivate::doubleToString(double, int, QLocalePrivate::DoubleForm, 
int, unsigned int) const

according to `c++filt'; GDB should be able to demangle it too. :-)

> I'm wondering what kind of C/C++ code could cause such to be generated?
> (I know, I know, not much to go on; I could get additional logs.)

 It usually happens when a badly aligned argument is passed down to a
function (or method) as a result of a bad cast.  Sloppy code in general.  
;-)

> In addition, it apparently is not BAD code - that is, there doesn't
> appear to be anything wrong with the results of its "fix up", meaning
> the data is probably OK too, and found where pointed at.

 If you cast a narrower (less strictly aligned) type to a wider (more
strictly aligned) one, it is always bad code.  For example you will not
get data corruption from casting char[4] to an unsigned int and in many
cases such code will work, but that's still undefined behaviour -- you are
perfectly fine to expect to get a SIGBUS rather than anything else in this
case.  Some people believe all the world is the x86 (they are wrong, of
course, because it is the VAX what all the world is) and do not even have
a slightliest clue about what data alignment is.

> I wonder if there's anything I can do about it?

 Find where the piece of unaligned data comes from and how it gets through
to doubleToString(). ;-)  A hardware watchpoint might be useful -- any of
the Alpha processors providing them?  Ones I used unfortunately did not
have them, but it was long ago and they were only EV45.  A software
watchpoint might do, but the experience will be rather painfully slow.

  Maciej