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-head
mailing list