bearophile can say "i told you so" (re uint->int implicit conv)

[Jonathan M Davis]

On Thursday, April 04, 2013 21:39:35 Kagamin wrote:
> BTW don't we already have a hungry application *with* unsigned
> integers?
> http://d.puremagic.com/issues/show_bug.cgi?id=4236
> http://d.puremagic.com/issues/show_bug.cgi?id=6498
> http://d.puremagic.com/issues/show_bug.cgi?id=3719
> 
> http://d.puremagic.com/issues/show_bug.cgi?id=4984 - and who
> reported this?

I wasn't arguing otherwise. Some applications need 64-bits to do what they do. 
My point was that with 32-bit programs, using unsigned integers gives you 
lengths twice as long, so it's quite possible for a 32-bit program to work 
with size_t being unsigned but not work if it were signed. But regardless of 
whether size_t is signed or unsigned, there's a limit to how much memory you 
can deal with in a 32-bit program, and some programs will need to go to 64-
bit. It's just that if size_t is unsigned, the limit is higher.

But I would point out that the bugs that you listed are not at really related 
to this discussion. They're about dmd running out of memory when compiling, 
and it's running out of memory not because it needs 64-bit to have enough 
memory or because size_t is signed (because it is) but because it doesn't 
reuse memory like it's supposed to. It generally just eats more without 
releasing it properly. It should be perfectly possible for a 32-bit dmd to 
compile those programs without running out of memory. And if that issue has 
anything to do with this discussion, it would be to point out that dmd's 
problems would be made worse by making size_t signed, which would just 
underline the fact that making size_t signed on 32-bit systems would make 
things worse (though dmd is currently written in C++, so whether size_t is 
signed or unsigned in D doesn't really matter for it at the moment).

- Jonathan M Davis