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
and , 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
, 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@haskell.org http://www.haskell.org/mailman/listinfo/yhc