Use stdint types to define SIZEOF and ALIGNMENT of INTx/WORDx

Authored by wereHamster on Apr 10 2016, 6:58 AM.



Saves us a CPP #if in MachDeps.h since we now can always rely on a
64-bit type being available.

Diff Detail

rGHC Glasgow Haskell Compiler
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.
wereHamster updated this revision to Diff 7227.Apr 10 2016, 6:58 AM
wereHamster retitled this revision from to Use stdint types to define SIZEOF and ALIGNMENT of INTx/WORDx.
wereHamster updated this object.
wereHamster edited the test plan for this revision. (Show Details)
bgamari added inline comments.Apr 18 2016, 2:50 AM

Perhaps we want to keep these checks but instead test SIZEOF_INT*_T? I must say, I wouldn't necessary expect things to work as expected if int8_t isn't 1 byte; as far as I know these types are supposed to be fixed-width.

bgamari requested changes to this revision.Apr 18 2016, 2:50 AM
bgamari edited edge metadata.

This looks good but perhaps let's not drop the sanity check.

This revision now requires changes to proceed.Apr 18 2016, 2:50 AM
wereHamster added inline comments.Apr 18 2016, 2:16 PM

int8_t is defined as exactly 8 bits / 1 byte. I don't think checking the size of those is necessary. If you feel we should do that then I suggest checking that in the configure script, where we check the presence of those types (like an additional sanity check to see if the platform really conforms to the C99 standard).

The only reason for keeping this code around that I can see: if other files in GHC depend on char/short/int being 1/2/4 bytes wide. Such code really should use int8/16/32_t instead (or StgInt/Word8/16/32). Do you think it's worth keeping these checks around for those cases?

bgamari accepted this revision.Apr 18 2016, 3:07 PM
bgamari edited edge metadata.
bgamari added inline comments.

After the Apple nm debacle I was thinking that one can never be too certain when it comes to standards compliance. That being said, sizeof(uint8_t) != 1 is indeed diabolical. You are problem right, no one is that insane.

This revision is now accepted and ready to land.Apr 18 2016, 3:07 PM
This revision was automatically updated to reflect the committed changes.
hvr awarded a token.Apr 19 2016, 2:15 AM