On 01/05/2012 17:03, Gabriel Dos Reis wrote:
On Tue, May 1, 2012 at 10:29 AM, Simon Marlow<[email protected]> wrote:
On 01/05/2012 16:05, Gabriel Dos Reis wrote:
On Tue, May 1, 2012 at 5:11 AM, Simon Marlow<[email protected]> wrote:
On 01/05/2012 10:58, Gabriel Dos Reis wrote:
On Tue, May 1, 2012 at 3:24 AM, Simon Marlow<[email protected]>
wrote:
On 27/04/2012 17:46, Ian Lynagh wrote:
On Fri, Apr 27, 2012 at 04:58:14PM +0100, Simon Marlow wrote:
Hmm, I indended lnat to be shorthand for "unsigned long". I'd much
rather we used size_t when we mean that, and keep lnat as meaning
"unsigned long".
I'm certainly happy with using size_t instead of lnat.
When should lnat be used, though? When would you want a 32-bit value
on
Windows/x86_64, but a 64-bit value on Linux/x86_64?
That's a good point. I'd be ok with lnat being 64 bits on Windows/x64.
'long', 'int', size_t, carry uncertainty about their precisions. Any
reason not to use
the sized integer types (where available, but these days they are on all
platforms that GHC cares about.)
In general, I would use 'int', 'long', etc. only when mandated by the
host system APIs.
Everywhere else I would be explicit about the integer type precision
-- unless it really does
not matter.
Sometimes we want to use either 32 bits or 64 bits depending on the
machine
word size, e.g. when the value represents the size of a memory object.
Perhaps in those cases we should be using size_t (I'm a bit hazy on what
the exact meaning of size_t is though, so I generally prefer to define
these
things myself).
I guess a question is what it meant by "word"? The width of
the CPU general purpose register? The width of a data pointer?
Even in 64-bit mode, some ABIs use ILP32 (e.g. the case of the x32 ABI
or the MIPS N32 ABI). I know of only one case of LLP64 ABI
where size_t is still 32-bit, but I am not sure GHC runs there.
I'm using "word" in the GHC sense:
http://hackage.haskell.org/trac/ghc/wiki/Commentary/Rts/Word
ie. it's the width of a pointer.
Aha, thanks! In that case, I would use uintptr_t in place
of size_t just to make it plain clear (from documentation perspective)
and to follow C standard semantics and idiomatic practice -- even if
size_t and uintptr_t are likely to have the same width on "sane" platforms.
Right, we should probably be using uintptr_t in some places. The reason
things are the way they are is that much of the RTS was written before
many platforms supported C99, when <inttypes.h> and <stdint.h> did not
exist. StgWord is our version of uintptr_t, and they should be
identical (also StgWord is idiomatic GHC RTS, if not idiomatic C).
I don't tend to use size_t, it was Ian who claimed that we should be
using it, and made lnat == size_t. Maybe what we've arrived at is that
we should have lnat == uintptr_t == StgWord instead.
For the corresponding printf-style format specifier, I would
macro-test for PRIuPTR from<inttypes.h> and use it. It should
be available on any modern computing system that GHC cares
about. These types and macros have been there for nearly 15 years.
Aha, so I didn't even know about PRIuPTR (shame on me!). Thanks for that.
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
