Re: Restricted unsigned integer range would have been better?

From	"Ansel" <tinker454@trytospammenowloser.com>
Newsgroups	comp.lang.c
Subject	Re: Restricted unsigned integer range would have been better?
Date	2012-07-24 16:05 -0600
Organization	Aioe.org NNTP Server
Message-ID	<jun6d8$mt$1@speranza.aioe.org> (permalink)
References	<juiuqb$rau$1@speranza.aioe.org> <juj9b4$25k$1@dont-email.me> <juld2l$gsb$1@speranza.aioe.org> <julqqp$5qg$1@dont-email.me>

"BartC" <bc@freeuk.com> wrote in message news:julqqp$5qg$1@dont-email.me...
> "Ansel" <tinker454@trytospammenowloser.com> wrote in message
> news:juld2l$gsb$1@speranza.aioe.org...
>>
>> "BartC" <bc@freeuk.com> wrote in message
>> news:juj9b4$25k$1@dont-email.me...
>>>
>>>
>>> "Ansel" <tinker454@trytospammenowloser.com> wrote in message
>>> news:juiuqb$rau$1@speranza.aioe.org...
>>>> If C's unsigned integer types were designed so that their maximum value
>>>> was
>>>> the same as the absolute value of the same width signed integer type's
>>>> minimum value, wouldn't that automagically elimintate a bunch of
>>>> erroneous
>>>> code and simplify programming in C?
>>>
>>> Assuming an 8-bit int type,
>>
>> I was actually thinking about every width *except* 8-bits when I posted.
>
> I chose 8-bits to simplify the examples. But, what's special about 8-bits
> that they ought to be allowed a conventional unsigned range; perhaps it's
> easier to think of examples where things would stop working..?

It's hard to let go of an integer of that range. We've already established, 
though, sort of, that non-arithmetic types could still utilize the full 
range -- they'd just be called something else. IOW, the smaller range of an 
8-bit type makes is more of a rare jewel because there is a higher 
probability of needing "just a little more range than 128" than of there is 
similarly for wider types. (Or something like that, LOL).

>
>>> the normal signed/unsigned ranges might be -128
>>> to +127, and 0 to 255.
>>>
>>> You're suggesting the unsigned range ought to be 0 to 128?
>>
>> That would be the scene with *your* 8-bit int type, yes. And I wasn't
>> "suggesting", I was wondering.
>
> OK, choosing a 16-bit type, you were wondering whether the unsigned range
> ought to be 0 to 32768 instead of 0 to 65535.
>
> I think it would be simpler to restrict it to 0 to 32767, ie just the
> positive values of a signed int type.

Fine.

> (That means you can't
> represent -(-32768), but you can't do that as a signed value anyway.) Then
> you just have to mask the top bit in every operation.
>
> But then, that would be little different from not having unsigned at all,
> and and only using the top half of each signed int range.
>
>>
>>>
>>> That sounds very difficult to implement;
>>
>> It's quite simple actually.
>>
>>> what happens if  you have 128
>>> unsigned, and add one?
>>
>> That depends on the type of integer: saturating or modular or
>> except-on-overflow. Note that my OP was basically referring to a 
>> "ranged",
>> or "range-restricted", integer.
>
> There is some merit to ranged-integer types, but the range would need to 
> be
> enforced (not popular in C) and the type system becomes massively more
> complicated
"massively"? Anyway, having the flexibility* of the different types would be 
worth the bit of added complexity (now we're getting off topic) and, indeed, 
there is some standard for C to address at least saturating types as I 
recall. Why stop at just that?

> (what's the result of adding a 100..200 type to a 150..250
> type?).

It depends on the type. Don't mix different types. But when you do, let the 
compiler coerce as appropriate and safe and least unexpecting behavior or 
emit a compile-time error.

>
> Also, a range is usually a subset of the allowed int range; yours would be 
> a
> superset! Because the top value will be one more than the normal range of 
> a
> signed int.

You are picking nits -- you *know* that is not what I meant in the OP.

>
> It *might* work as a range of the full unsigned int type, but that 
> requires
> the normal, unconstrained unsigned type to be still available.
>
> Otherwise there are just two many problems, if any arbitrary value of 16, 
> 32
> or 64 bits you might encounter, can only ever be represented as signed, so
> will be negative half the time. You can't even convert -1 to unsigned, and
> back again, as C can now; you can't represent -1 as unsigned at all.
>
> -- 
> Bartc

Thread