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-25 06:28 -0600
Organization	Aioe.org NNTP Server
Message-ID	<juooqf$c1c$1@speranza.aioe.org> (permalink)
References	(1 earlier) <juj9b4$25k$1@dont-email.me> <juld2l$gsb$1@speranza.aioe.org> <AYSdnbmo_YfvPZPNnZ2dnUVZ8lKdnZ2d@lyse.net> <jun7c0$2ua$1@speranza.aioe.org> <F_qdnf8PU5byP5LNnZ2dnUVZ8j-dnZ2d@lyse.net>

"David Brown" <david@westcontrol.removethisbit.com> wrote in message 
news:F_qdnf8PU5byP5LNnZ2dnUVZ8j-dnZ2d@lyse.net...
> On 25/07/2012 00:23, Ansel wrote:
>> "David Brown" <david@westcontrol.removethisbit.com> wrote in message
>> news:AYSdnbmo_YfvPZPNnZ2dnUVZ8lKdnZ2d@lyse.net...
>>
>>>
>>> The whole concept is unworkable, because you are missing out one of the
>>> biggest uses of C.  /You/ may be able to live without full-range 
>>> unsigned
>>> 8-bit, 16-bit and 32-bit types for /your/ programming.  But the real 
>>> world
>>> runs on embedded systems programmed in C - these far outweigh the number
>>> of PC-style systems.  And for embedded systems, unsigned data is the 
>>> norm,
>>> using exactly the number of bits provided by the hardware.
>>>
>>
>> You can still have the full-width unsigned types, they just wouldn't be
>> *arithmetic* types. I don't know if that would work out for embedded
>> systems. It should be adequate though for, say, representation of 
>> character
>> types. That noted, still "unworkable"?
>>
>
> Yes, it would be unworkable.
>
> There are many reasons why unsigned types are common in embedded systems. 
> For some small processors, they are faster (some cpu's do not have the 
> necessary condition code flags to do signed comparisons, and 
> multiplication and division of unsigneds is often faster).  You are often 
> mapping hardware registers, which rarely have any concept of sign. Most of 
> the numbers you encounter are unsigned.  They give greater range than 
> signed numbers - and in embedded systems, every bit counts. (On a 32-bit 
> system, 1 bit is only 3% of your information - with 8-bit data, it is 
> 12.5% of your information.  That's a lot to waste.)  And of course these 
> types are also related to pointers - you sometimes need to treat pointers 
> as integer types, and you wouldn't want to lose have your memory space.
>
> It doesn't really make sense to say "wouldn't be *arithmetic* types" in 
> terms of C as we know it.  All integer types are arithmetic.  And anyway, 
> you certainly need to be able to do arithmetic on these types in embedded 
> systems.
>

Well there could be an additional type like the one I pondered about for 
those domains that don't work at the bare metal level (yeah, I know, most of 
what C is used for, but one could easily extend this discussion to C++ which 
is used en masse at much higher levels). But that would be facetiously 
ignoring what has been established in the rest of the thread already, so OK: 
perhaps "unworkable" for embedded domains, but pretty much useless elsewhere 
because most unsigned things are going to be things where arithmetic ops 
should not be available on that type anyway. The rest of your post "summed 
it up" nicely: use Ada instead ;).

> Of course, the disadvantage here is that when converting between signed 
> and unsigned types, or mixing them in expressions, you must be even more 
> careful about overflows.  I usually have compiler warnings enabled to tell 
> me if I've done such mixing - then I will use explicit casts to leave no 
> doubts.
>

[Snipped the rest of the very good answer which goes on to describe the type 
system of Ada. ;)]

Thread