--Signature_Mon__30_May_2005_16_21_45_-0400_K5=zzA26XHZdjtob
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Hello,

>    Ok, I meant 64bit alignment constraint violations - SPARCs require
>    natural alignment for all memory accesses, so the popular game of
>    passing an int* for a size_t* is pretty likely to blow up with a
>    bus error on sparc64, but these won't bite you ;)
>=20
> worse - you'll get the wrong data even if the int* was aligned for
> size_t* access, due to the BE pointer pointing to the final byte of
> the data not the first....

True, not to talk about overwriting whatever is behind the int.=20
( and in this case I really prefer the bus error... )

>    I don't think there are many endianness bugs left in gecko - it
>    runs fine on MacOS X for ages, same goes for Solaris. The
>    PowerPC-specific code seems to blow up on macppc ( /weird/
>    rendering errors but no more crashes than on MacOS X ), on sparc64
>    I don't see any of these rendering problems.=20
>=20
> what about on _64 bit_ big endian, where int* & size_t*/long*/etc
> are not interchangeable as they are on 32 bit systems.  that is
> the cause of many weird bugs in my experience.

Indeed. If I'd get a buck for each 'please make that int a size_t' mail
I've sent in the last few months I'd have... well, enough for a few
beers ;)

have fun
Michael

--Signature_Mon__30_May_2005_16_21_45_-0400_K5=zzA26XHZdjtob
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (NetBSD)

iQEVAwUBQpt12cpnzkX8Yg2nAQJPegf8DcCE+JXadUHEtOzSvfcSRPa9RBb37Fk/
qJw02tNiEWFAsHOH4CfwhbId6ZRwcLaVNMBfOVYGLE0pg1Ues697NnIZIZr345LA
BNJcn1JI9Pdt8q/rXd93dkIIy8IVegPOp2Wk8QPPyABdpfGiOmrMBEAOZjNOJz1G
tNsCsxZGtC/rbzVOnVZD8YwWtaY9yKfQ5S0sWhmFk8hobDGRVN2m6O+6r5VrBrGu
8JgtU/h++kblYE17qvfAgex1Jor98Pip4lABPkGiBGf3cdqDdDluNr4vMlxLJsDl
D6Opz/ZtNfY+8EvpvPXgKFJjMH/7dmtkyMlazK+qCLcCyZ/4GmLEHQ==
=TFci
-----END PGP SIGNATURE-----

--Signature_Mon__30_May_2005_16_21_45_-0400_K5=zzA26XHZdjtob--