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
