Tue, 28 Mar 2000 14:52:56 +0200, Sven Panne <[EMAIL PROTECTED]>
pisze:
[...]
Strange: I agree in every point!
> 3) If ISO C has long long (don't know, my copy of Harbison/Steele doesn't
> mention it), Int64/Word64 should be made mandatory.
C99, the recently approved ISO C standard, does have long long.
It must have at least 64 bits.
> 5) Let's explicitly state that Hs{Int,Word}{8,16,32,64} and ISO C's
> {,u}int{8,16,32,64}_t are the same.
Of course it requires the compiler configuration to check what they
really are if they exist - if int and long are both 32 bits, int32_t
can be either. (Theoretically it could also be neither of standard
integer types, but perhaps we will not consider that case.)
Are {,u}int_least{8,16,32,64}_t, {,u}int_fast{8,16,32,64}_t,
{,u}intptr_t, {,u}intmax_t worth considering? I don't think they will
be often found in interfaces, but they are there...
int_least*_t and int_fast*_t are required, int*_t are optional
(but {,u}int{8,16,32,64}_t are required if types of desired sizes
exist at all) - do we care that int*_t are optional? int_least64_t
is required anyway, so the only case where an int*_t is missing is
that there is no type of exactly the specified width, there are only
longer and possibly shorter.
> Having the HsFoo names around is nevertheless handy because it
> is not clear to me what #include one can use in a portable way
> (e.g. there is no stdint.h on HP-UX 10.20).
Sure, it's convenient and easy to remember when each foreignable
Haskell type has a consistent C name.
> 6) Add HsBool with a mapping to an arbitrary integral C type, see Fergus'
> point about a Haskell API.
Probably bool from <stdbool.h> if it exists.
> (Should we guarantee that False maps to 0 and True to something
> <>0?)
I guess so. Why don't mandate True to be 1? Is any non-zero value
required to convert back to Haskell's True?
bool from <stdbool.h> has only two values, false and true (#defined
to 0 and 1 respectively), and converting any nonzero value to bool
yields true.
> * jmp_buf is almost the same story as fpos_t, with the small
> difference that always jmp_buf and not jmp_buf* is
> used. Nevertheless, on every architecture I had a look at (Linux,
> HP-UX, Solaris, OSF) it is a pointer/array.
jmp_buf is required to be an array in ISO C. Arrays have different
assignment semantics, AFAIK that's why it is stated explicitly.
I'm not sure if setjmp and longjmp can be ever used with C interfaced
to Haskell in a way that would make sense to manipulate them in
Haskell.
I've already say what I think about typed StablePtrs. I can explain
the resulting asymmetry between untyped StablePtrs and typed Addrs /
Ptrs:-)
--
__("< Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/ GCS/M d- s+:-- a23 C+++$ UL++>++++$ P+++ L++>++++$ E-
^^ W++ N+++ o? K? w(---) O? M- V? PS-- PE++ Y? PGP+ t
QRCZAK 5? X- R tv-- b+>++ DI D- G+ e>++++ h! r--%>++ y-
