svn commit: r300332 - in head/sys: amd64/amd64 i386/i386

Conrad Meyer cem at FreeBSD.org
Sat May 21 22:08:47 UTC 2016


On Fri, May 20, 2016 at 9:13 PM, Bruce Evans <brde at optusnet.com.au> wrote:
> On Fri, 20 May 2016, Conrad Meyer wrote:
>
>> On Fri, May 20, 2016 at 6:10 PM, Bruce Evans <brde at optusnet.com.au> wrote:
>>>
>>>
>>> Signed integers are easier to understand provided calculations with them
>>> don't overflow.
>>
>>
>> How?
>
>
> For the same reasons as in applying mathematics.  Applying mathematics
> was harder before negative numbers were invented.  Negative numbers
> are actually not easy to understand at the technical level (the usual
> representation of them is equivalence classes of pairs of non-negative
> numbers), but their properties are easy to understand and work with
> once you are familiar with them and don't think about their
> implementation details too much.
>
> Ordinary (real) numbers (including negative ones) also have good ordering
> properties for all operations.
>
> Computer arithmetic can't represent all ordinary numbers, but gets closest
> by representing ordinary integers as C signed integers perfectly when no
> overflow occurs.
>
> By using C unsigned integers unnecessarily, you throw out invention of
> negative numbers and might have to work with the unfamiliar and badly
> behaved ordering on them.  C programmers have some experience with this
> ordering, but apparently not enough to usually avoid bugs.
>
>> The rest of the argument seems to be, using u_int is bad because more
>> unsigned is always bad.  But I haven't seen a good reason to believe
>> that is so.
>
>
> Not always bad.  Sometimes you must use C unsigned integers to get a full
> representation without wasting many bits, or actually want the ordering
> of unsigned integers.  The main case is representing other C things like
> pointers.  Differences of pointers are still hard to handle.
>
> Bruce


Thanks for explaining.

Can you explain a little bit about the badly behaved ordering of
unsigned integers?  I am not familiar with that.

Best,
Conrad


More information about the svn-src-all mailing list