[Yhc] Haskell Int{8,16,32...} types, config.h

[Thomas Shackell]

Hi All,

Sorry for the late reply, I've just moved house and no internet yet :-)

I avoided stdint.h principally because it's C99 and not ANSI C. However, 
there might well be a case for lifting that restriction now, we've 
already gots lots of other non-portable bits (libffi, libgmp etc.) and 
almost every C compiler does support C99 ...

Thus I suppose the principal reason is that it started that way and no 
one has been bothered to change it ;-)

So yes, might be worth changing in the fullness :-)


As a further note in libffi, it does seem to be causing a lot of 
problems, perhaps having it as a required dependency is not a good idea! 
It wouldn't be too hard to revert to using non libffi primitives (it 
just means regenerating the wrappers from the Haskell, which is much 
easier now they're all in one place). Perhaps we should consider this.


Cheers

Tom

Isaac wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> I decided to look in the generated "config.h" file to see what was
> there. Some of it seems like it could be improved.
> 
> /* first of all get constants for Int8, Int16, Int32, etc ... */
> #if SIZEOF_CHAR == 1
> #  define INT8_TYPE       char
> #else
> #  error "can't find type matching int8"
> #endif
> 
> #if SIZEOF_SHORT == 2
> #  define INT16_TYPE      short
> #else
> #  error "can't find type matching int16"
> #endif
> 
> and so on.
> 
> These are not as portable as they could be. A C standard defines headers
> that have int8_t, uint8_t, int16_t, uint16_t, and so on. These types are
> guaranteed by the standard, no matter what sizes "short", "int", and so
> on are. This is potentially more portable across architectures, but
> potentially less portable across compilers: C99 defines these headers
> (both <inttypes.h> and <stdint.h>, but inttypes.h is a superset
> including stuff we don't need to include). GCC has supported these
> headers since a long time, but I don't know about other compilers. Using
> these would also require getting rid of the hack of using macros and
> attaching "unsigned" to get the unsigned version -- rather, the uintN_t
> version can be used. If the headers are not available enough yet among C
> compilers, the configuration could still use them "if possible".
> 
> Furthermore, since the only use (according to grep ;-)) of testing to
> find out the size of various C types is in these #if SIZEOF_SHORT, etc.,
> all those configuration tests would not need to be done if stdint.h or
> inttypes.h was available. If we need to know the exact sizes of
> floating-point types, however, we are out of luck using this route --
> these are "int" headers only. Do we need to do anything with
> floating-point types but distinguish "float" and "double"? It seems both
> C and Haskell only offer those two named types (well, C also has "long
> double" which we already ignore), and Haskell numeric literals are
> always Integer or Rational, not fundamentally floating-point, so the
> size of the floating-point types shouldn't affect the bytecode(?) (and
> sizeof(float) and sizeof(double) can be used if the size of memory to
> allocate is needed in some place in the interpreter, and various weird
> properties of floats and doubles can be found in the C89 <float.h>, or
> perhaps other places, if needed)
> 
> Regards,
> Isaac
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.4 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFE0l87HgcxvIWYTTURAuCfAJ4gcFIHZWZWJvVs2HATQb7dNRRghACfWYi+
> cHmpGdme96q5ENSYD7zE/cE=
> =QLC+
> -----END PGP SIGNATURE-----
> _______________________________________________
> Yhc mailing list
> Yhc at haskell.org
> http://www.haskell.org/mailman/listinfo/yhc