Re: Restricted unsigned integer range would have been better?

From	"BartC" <bc@freeuk.com>
Newsgroups	comp.lang.c
Subject	Re: Restricted unsigned integer range would have been better?
Date	2012-07-26 14:06 +0100
Organization	A noiseless patient Spider
Message-ID	<jurfdf$nhc$1@dont-email.me> (permalink)
References	(5 earlier) <F_qdnf8PU5byP5LNnZ2dnUVZ8j-dnZ2d@lyse.net> <juooqf$c1c$1@speranza.aioe.org> <fZqdnYmfzYXQmY3NnZ2dnUVZ7sGdnZ2d@lyse.net> <jup66u$9pl$1@dont-email.me> <kuydnaVADZU_hYzNnZ2dnUVZ8tadnZ2d@lyse.net>

"David Brown" <david@westcontrol.removethisbit.com> wrote in message
news:kuydnaVADZU_hYzNnZ2dnUVZ8tadnZ2d@lyse.net...
> On 25/07/2012 18:17, BartC wrote:

>> You will need to assign an int value to your range type at some
>> point. Then it will need a runtime range-check.
>
> No, it won't need a runtime range check - at least, not anything generated
> automatically by the compiler.  The compiler should be able to assume that
> the programmer knows what he is doing.
>
> So if you have a type "int_1_to_10_t", and you write:
>
> extern int foo(void);
> int_1_to_10_t x = (int_1_to_10_t) foo();
>
> then the compiler can assume that the value for x is in range.  If the
> compiler can do any compile-time checking, then it should - but when a
> programmer makes an explicit cast like this, he is also making a clear
> statement that it is a valid cast.

There is already a kind of restricted int in C, called a _Bool, which can
only contain (I believe) 0 or 1.

When you assign an int to it, a runtime conversion seems to be performed (to
convert not-zero to 1). But when I tried a (_Bool) cast in gcc just now, it
still performed this conversion! It didn't trust the programmer telling it
the int already contained 0 or 1.

But then, there is a slight ambiguity in the meaning of a cast anyway; does
it mean 'assume the value is already of the type expected, so don't
convert', or 'please convert'!

Your (int_1_to_10_t) cast can be interpreted either way.

> Note that your code might well contain explicit checks for validity - but
> you would have these anyway, even if the type did not have a range.
>
>> If you allow
>> arithmetic on your range-types (even just ++ and --), then they will
>> need overflow checking, something not necessary at the moment as any
>> result will be a legal value for that type.
>>
>
> Again, no more so than you have for existing types (after all, types like
> "int" have a limited range already).

It's not quite the same. If you do ++ on an int, you *know* (for unsigned
anyway) the result will always be a valid int, although it might wrap
eventually.

Do ++ on a 1..10 int, then it's quite likely you will get 11 at some point.
11 is an illegal value for this type. And it doesn't wrap, doesn't saturate,
and doesn't give a warning, yet you've told the compiler the value will
*never* be more than 10.

(And performing ++ on a _Bool, you will always get 1, not sometimes 2.
Create a new type 0..1, and ++ can give you 1, 2 ... or anything else
depending on how many ++s you've done! But again, C doesn't trust the
programmer to only increment a _Bool which contains 0. Admittedly this 
checking is trivial for a _Bool type.)

-- 
Bartc

Thread