Treating the abusive unsigned syndrome

[Sean Kelly]

Denis Koroskin wrote:
> 27.11.08 в 03:46 Sean Kelly в своём письме писал(а):
> 
>> Andrei Alexandrescu wrote:
>>> Sean Kelly wrote:
>>>> Don wrote:
>>>>>
>>>>> Although it would be nice to have a type which was range-limited, 
>>>>> 'uint' doesn't do it. Instead, it guarantees the number is between 
>>>>> 0 and int.max*2+1 inclusive. Allowing mixed operations encourages 
>>>>> programmers to focus the benefit of 'the lower bound is zero!' 
>>>>> while forgetting that there is an enormous downside ('I'm saying 
>>>>> that this could be larger than int.max!')
>>>>
>>>> This inspired me to think about where I use uint and I realized that 
>>>> I don't.  I use size_t for size/length representations (largely 
>>>> because sizes can theoretically be >2GB on a 32-bit system), and 
>>>> ubyte for bit-level stuff, but that's it.
>>>  For the record, I use unsigned types wherever there's a non-negative 
>>> number involved (e.g. a count). So I'd be helped by better unsigned 
>>> operations.
>>
>> To be fair, I generally use unsigned numbers for values that are 
>> logically always positive.  These just tend to be sizes and counts in 
>> my code.
>>
>>> I wonder how often these super-large arrays do occur on 32-bit 
>>> systems. I do have programs that try to allocate as large a 
>>> contiguous matrix as possible, but never sat down and tested whether 
>>> a >2GB chunk was allocated on the Linux cluster I work on. I'm quite 
>>> annoyed by this >2GB issue because it's a very practical and very 
>>> rare issue in a weird contrast with a very principled issue (modeling 
>>> natural numbers).
>>
>> Yeah, I have no idea how common they are, though my guess would be 
>> that they are rather uncommon.  As a library programmer, I simply must 
>> assume that they are in use, which is why I use size_t as a matter of 
>> course.
> 
> If they can be more than 2Gb, why can't they be more than 4GB? It is 
> dangerous to assume that they won't, that's why uint is dangerous. You 
> exchange one additional bit of information for safety, this is wrong.

Bigger than 4GB on a 32-bit system?  Files perhaps, but I'm talking 
about memory ranges here.

> Soon enough we won't use uints the same way we don't use ushorts (I 
> should have asked if anyone uses ushort these day first, but there is so 
> little gain to use  ushort as opposed to short or int that I consider it 
> impractical). 64bit era will give us 64bit pointers and 64 bit counters. 
> Do you think you will prefer ulong over long for an additional bit? You 
> really shoudn't.

long vs. ulong for sizes is less of an issue, because we're a long way 
away from running against the limitations of a 63-bit size value.  The 
point of size_t to me, however, is that it scales automatically, so if I 
write array operations using size_t then I can be sure they will work on 
both a 32 and 64-bit system.

I do like Don's point about unsigned really meaning "unsigned" however, 
rather than "positive."  I clearly use unsigned numbers for both, even 
if I flag the "positive" uses via type alias such as size_t.  In C/C++ I 
rely on compiler warnings to trap the sort of mistakes we're talking 
about here, but I'd love a more logically sound solution if one could be 
found.


Sean