mail archive GHC/CVS discussion and fptools/ghc CVS commit messages
cvs-ghc.haskell.org
(List home) (Recent threads) (40 other Haskell lists)
Subscription Options
- RSS or Atom: Read-only subscription using a browser or aggregator. This is the recommended way if you don't need to send messages to the list. You can learn more about feed syndication and clients here.
- Conventional: All messages are delivered to your mail address, and you can reply. To subscribe, send an email to the list's subscribe address with "subscribe" in the subject line, or visit the list's homepage here.
- This list contains about 75,974 messages, beginning Apr 2000
- This list doesn't seem to be active
Report the Spam
This button sends a spam report to the moderator. Please use it sparingly. For other removal requests, read this.
Are you sure? yes no
master: Fix warnings on Win64 (1dbe6d5)
Ad
Repository : ssh://darcs.haskell.org//srv/darcs/ghc On branch : master http://hackage.haskell.org/trac/ghc/changeset... >--------------------------------------------------------------- commit 1dbe6d59b621ab9bd836241d633b3a8d99812cb3 Author: Ian Lynagh Date: Thu Apr 26 16:52:44 2012 +0100 Fix warnings on Win64 Mostly this meant getting pointer<->int conversions to use the right sizes. lnat is now size_t, rather than unsigned long, as that seems a better match for how it's used. includes/Rts.h | 15 ++++++++++++--- includes/mkDerivedConstants.c | 2 +- includes/rts/Hooks.h | 6 +++--- includes/rts/Types.h | 4 ++-- rts/Capability.c | 4 ++-- rts/Disassembler.c | 18 +++++++++--------- rts/Linker.c | 32 ++++++++++++++++++++++++-------- rts/Printer.c | 24 ++++++++++++------------ rts/ProfHeap.c | 2 +- rts/RtsFlags.c | 2 +- rts/Stats.c | 19 ++++++++++--------- rts/Stats.h | 2 +- rts/Task.c | 4 ++-- rts/Ticky.c | 26 +++++++++++++------------- rts/Trace.c | 26 +++++++++++++------------- rts/hooks/MallocFail.c | 2 +- rts/hooks/OutOfHeap.c | 2 +- rts/hooks/StackOverflow.c | 2 +- rts/sm/Sanity.c | 18 +++++++++--------- rts/sm/Scav.c | 4 ++-- rts/win32/IOManager.c | 2 +- rts/win32/OSMem.c | 4 ++-- 22 files changed, 123 insertions(+), 97 deletions(-) Diff suppressed because of size. To see it, use: git show 1dbe6d59b621ab9bd836241d633b3a8d99812cb3
On 27/04/2012 15:22, Ian Lynagh wrote:
> Repository : ssh://darcs.haskell.org//srv/darcs/ghc
>
> On branch : master
>
> http://hackage.haskell.org/trac/ghc/changeset...
>
>> ---------------------------------------------------------------
>
> commit 1dbe6d59b621ab9bd836241d633b3a8d99812cb3
> Author: Ian Lynagh<
> Date: Thu Apr 26 16:52:44 2012 +0100
>
> Fix warnings on Win64
>
> Mostly this meant getting pointer<->int conversions to use the right
> sizes. lnat is now size_t, rather than unsigned long, as that seems a
> better match for how it's used.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".
Cheers,
Simon
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?
Thanks
Ian
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.
Cheers,
Simon
On Tue, May 1, 2012 at 3:24 AM, Simon Marlow 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.
-- Gaby
On 01/05/2012 10:58, Gabriel Dos Reis wrote:
> On Tue, May 1, 2012 at 3:24 AM, Simon Marlow< 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 agree that it's usually bad to use these uncertain types. It would be
nice to do a proper cleanup someday and purge them from the RTS.
Cheers,
Simon
On Tue, May 1, 2012 at 5:11 AM, Simon Marlow wrote: > On 01/05/2012 10:58, Gabriel Dos Reis wrote: >> >> On Tue, May 1, 2012 at 3:24 AM, Simon Marlow< 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 agree that it's usually bad to use these uncertain types. It would be > nice to do a proper cleanup someday and purge them from the RTS. > > Cheers, > Simon
On 01/05/2012 16:05, Gabriel Dos Reis wrote: > On Tue, May 1, 2012 at 5:11 AM, Simon Marlow< wrote: >> On 01/05/2012 10:58, Gabriel Dos Reis wrote: >>> >>> On Tue, May 1, 2012 at 3:24 AM, Simon Marlow< 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/Comm... ie. it's the width of a pointer. Cheers, Simon> >> >> I agree that it's usually bad to use these uncertain types. It would be >> nice to do a proper cleanup someday and purge them from the RTS. >> >> Cheers, >> Simon
On Tue, May 1, 2012 at 10:29 AM, Simon Marlow wrote:
> On 01/05/2012 16:05, Gabriel Dos Reis wrote:
>>
>> On Tue, May 1, 2012 at 5:11 AM, Simon Marlow< wrote:
>>>
>>> On 01/05/2012 10:58, Gabriel Dos Reis wrote:
>>>>
>>>>
>>>> On Tue, May 1, 2012 at 3:24 AM, Simon Marlow<
>>>> 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/Comm...
>
> 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.
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.
-- Gaby
On 01/05/2012 17:03, Gabriel Dos Reis wrote: > On Tue, May 1, 2012 at 10:29 AM, Simon Marlow< wrote: >> On 01/05/2012 16:05, Gabriel Dos Reis wrote: >>> >>> On Tue, May 1, 2012 at 5:11 AM, Simon Marlow< wrote: >>>> >>>> On 01/05/2012 10:58, Gabriel Dos Reis wrote: >>>>> >>>>> >>>>> On Tue, May 1, 2012 at 3:24 AM, Simon Marlow< >>>>> 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/Comm... >> >> 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