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-23 23:48 -0600
Organization	Aioe.org NNTP Server
Message-ID	<juld2l$gsb$1@speranza.aioe.org> (permalink)
References	<juiuqb$rau$1@speranza.aioe.org> <juj9b4$25k$1@dont-email.me>

"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.

> 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.

>
> 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.

> Every arithmetic operation would need extra code

Indeed it would, but it is minor and in most cases not detriental and it 
wouldn't preclude having another integer type called "fast-and-less-safe 
integer" or something. I.e., should the concept pan out to be worthwhile. 
And again, I wasn't *suggesting* with my OP, rather just throwing a thought 
on the table for discussion.

>detect the overflow, and convert numbers such as +129 to 0. With a few
> special cases such as 128+128.
>
> You would also be wasting most of the top bit (only used when representing
> 128). Then there are the illegal values 129 to 255, which uninitialised 
> data
> is likely to have.
>
> And then, with the char type, you would also be limited to a maximum of
> +128, cutting out most of the extra ANSI characters.
>
> In fact, every piece of coding relying on a byte having a range of 0 to 
> 255
> (as used in much of the internet for example), would need rewriting to use 
> a wider int to cover that range.

Noted above. For 'char' and 'byte' types allow the full unsigned range. 
Probably, for all unsigned ints that are not arithmetic types.

>
> And what happens when, for example, reading a file of 8-bit characters 
> which
> have been created when the range allowed +130 to 255 (eg. much of the
> world's stored data); you would now have a block of illegal values 
> instead.

1. My scenario was if it had been that way from the start, would we be 
better off.
2. Non-arithmetic types could use the full range that 8-bits allow.

>
> So I can see a few snags with the idea.
>

Name one. ;)

Thread