Groups > comp.lang.c > #23604 > unrolled thread

Restricted unsigned integer range would have been better?

Started by	"Ansel" <tinker454@trytospammenowloser.com>
First post	2012-07-23 01:32 -0600
Last post	2012-08-04 22:54 -0600
Articles	20 on this page of 107 — 18 participants

Back to article view | Back to comp.lang.c

Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-23 01:32 -0600
Re: Restricted unsigned integer range would have been better? "christian.bau" <christian.bau@cbau.wanadoo.co.uk> - 2012-07-23 01:45 -0700
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-24 00:19 -0600
Re: Restricted unsigned integer range would have been better? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-24 11:25 +0100
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-24 16:22 -0600
Re: Restricted unsigned integer range would have been better? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-25 01:53 +0100
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-24 21:43 -0600
Re: Restricted unsigned integer range would have been better? "christian.bau" <christian.bau@cbau.wanadoo.co.uk> - 2012-07-24 16:29 -0700
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-24 21:53 -0600
Re: Restricted unsigned integer range would have been better? Keith Thompson <kst-u@mib.org> - 2012-07-24 23:24 -0700
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-25 01:12 -0600
Re: Restricted unsigned integer range would have been better? Nobody <nobody@nowhere.com> - 2012-07-23 10:37 +0100
Re: Restricted unsigned integer range would have been better? Andre <lodwig@pathme.de> - 2012-07-23 11:46 +0200
Re: Restricted unsigned integer range would have been better? "BartC" <bc@freeuk.com> - 2012-07-23 11:33 +0100
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-23 23:48 -0600
Re: Restricted unsigned integer range would have been better? "BartC" <bc@freeuk.com> - 2012-07-24 10:43 +0100
Re: Restricted unsigned integer range would have been better? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-24 02:58 -0700
Re: Restricted unsigned integer range would have been better? "BartC" <bc@freeuk.com> - 2012-07-24 12:04 +0100
Re: Restricted unsigned integer range would have been better? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-24 05:32 -0700
Re: Restricted unsigned integer range would have been better? "BartC" <bc@freeuk.com> - 2012-07-24 14:20 +0100
Re: Restricted unsigned integer range would have been better? "BartC" <bc@freeuk.com> - 2012-07-24 18:41 +0100
Re: Restricted unsigned integer range would have been better? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-24 12:37 -0700
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-24 16:15 -0600
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-24 16:05 -0600
Re: Restricted unsigned integer range would have been better? Keith Thompson <kst-u@mib.org> - 2012-07-24 23:28 -0700
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-25 01:13 -0600
Re: Restricted unsigned integer range would have been better? Keith Thompson <kst-u@mib.org> - 2012-07-25 01:26 -0700
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-25 05:43 -0600
Re: Restricted unsigned integer range would have been better? David Brown <david@westcontrol.removethisbit.com> - 2012-07-24 15:10 +0200
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-24 16:23 -0600
Re: Restricted unsigned integer range would have been better? Keith Thompson <kst-u@mib.org> - 2012-07-24 23:40 -0700
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-25 01:32 -0600
Re: Restricted unsigned integer range would have been better? Keith Thompson <kst-u@mib.org> - 2012-07-25 01:29 -0700
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-25 05:45 -0600
Re: Restricted unsigned integer range would have been better? Keith Thompson <kst-u@mib.org> - 2012-07-25 12:35 -0700
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-26 00:12 -0600
Re: Restricted unsigned integer range would have been better? Keith Thompson <kst-u@mib.org> - 2012-07-26 01:42 -0700
Re: Restricted unsigned integer range would have been better? David Brown <david@westcontrol.removethisbit.com> - 2012-07-25 09:31 +0200
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-25 06:28 -0600
Re: Restricted unsigned integer range would have been better? David Brown <david@westcontrol.removethisbit.com> - 2012-07-25 16:28 +0200
Re: Restricted unsigned integer range would have been better? "BartC" <bc@freeuk.com> - 2012-07-25 17:17 +0100
Re: Restricted unsigned integer range would have been better? David Brown <david@westcontrol.removethisbit.com> - 2012-07-26 12:07 +0200
Re: Restricted unsigned integer range would have been better? "BartC" <bc@freeuk.com> - 2012-07-26 14:06 +0100
Re: Restricted unsigned integer range would have been better? James Kuyper <jameskuyper@verizon.net> - 2012-07-26 09:45 -0400
Re: Restricted unsigned integer range would have been better? David Brown <david@westcontrol.removethisbit.com> - 2012-07-30 09:01 +0200
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-26 00:09 -0600
Re: Restricted unsigned integer range would have been better? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-26 00:52 -0700
Re: Restricted unsigned integer range would have been better? pete <pfiland@mindspring.com> - 2012-07-26 20:35 -0400
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-26 22:35 -0600
Re: Restricted unsigned integer range would have been better? pete <pfiland@mindspring.com> - 2012-07-27 09:19 -0400
Re: Restricted unsigned integer range would have been better? Les Cargill <lcargill99@comcast.com> - 2012-07-27 12:51 -0500
Re: Restricted unsigned integer range would have been better? Keith Thompson <kst-u@mib.org> - 2012-07-27 16:19 -0700
Re: Restricted unsigned integer range would have been better? Les Cargill <lcargill99@comcast.com> - 2012-07-27 18:47 -0500
Re: Restricted unsigned integer range would have been better? David Brown <david@westcontrol.removethisbit.com> - 2012-07-30 09:10 +0200
Re: Restricted unsigned integer range would have been better? Philip Lantz <prl@canterey.us> - 2012-07-31 17:26 -1000
Re: Restricted unsigned integer range would have been better? pete <pfiland@mindspring.com> - 2012-08-01 00:18 -0400
Re: Restricted unsigned integer range would have been better? "io_x" <a@b.c.invalid> - 2012-08-01 10:19 +0200
Re: Restricted unsigned integer range would have been better? David Brown <david@westcontrol.removethisbit.com> - 2012-08-01 10:09 +0200
Re: Restricted unsigned integer range would have been better? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-08-01 12:51 +0100
Re: Restricted unsigned integer range would have been better? pete <pfiland@mindspring.com> - 2012-08-01 08:18 -0400
Re: Restricted unsigned integer range would have been better? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-08-01 14:22 +0100
Re: Restricted unsigned integer range would have been better? pete <pfiland@mindspring.com> - 2012-08-01 09:57 -0400
Re: Restricted unsigned integer range would have been better? pete <pfiland@mindspring.com> - 2012-08-01 11:35 -0400
Re: Restricted unsigned integer range would have been better? Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 11:43 -0700
Re: Restricted unsigned integer range would have been better? pete <pfiland@mindspring.com> - 2012-09-08 10:13 -0400
Re: Restricted unsigned integer range would have been better? Philip Lantz <prl@canterey.us> - 2012-09-22 23:39 -0700
Re: Restricted unsigned integer range would have been better? Philip Lantz <prl@canterey.us> - 2012-09-22 23:45 -0700
Re: Restricted unsigned integer range would have been better? Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-17 13:52 -0800
Re: Restricted unsigned integer range would have been better? Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-17 13:45 -0800
Re: Restricted unsigned integer range would have been better? pete <pfiland@mindspring.com> - 2012-12-17 19:51 -0500
Re: Restricted unsigned integer range would have been better? Philip Lantz <prl@canterey.us> - 2012-12-28 11:11 -0800
Re: Restricted unsigned integer range would have been better? Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-29 11:31 -0800
Re: Restricted unsigned integer range would have been better? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2012-12-29 23:59 +0000
Re: Restricted unsigned integer range would have been better? Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-02 10:01 -0800
Re: Restricted unsigned integer range would have been better? Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2013-01-05 12:00 +0200
Re: Restricted unsigned integer range would have been better? Philip Lantz <prl@canterey.us> - 2013-01-02 13:07 -0800
Re: Restricted unsigned integer range would have been better? Tim Rentsch <txr@alumni.caltech.edu> - 2013-01-03 12:10 -0800
Re: Restricted unsigned integer range would have been better? James Kuyper <jameskuyper@verizon.net> - 2013-01-05 12:26 -0500
Re: Restricted unsigned integer range would have been better? Philip Lantz <prl@canterey.us> - 2012-09-22 23:35 -0700
Re: Restricted unsigned integer range would have been better? Tim Rentsch <txr@alumni.caltech.edu> - 2012-12-17 14:02 -0800
Re: Restricted unsigned integer range would have been better? David Brown <david@westcontrol.removethisbit.com> - 2012-08-01 10:06 +0200
Re: Restricted unsigned integer range would have been better? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-08-01 12:46 +0100
Re: Restricted unsigned integer range would have been better? Philip Lantz <prl@canterey.us> - 2012-08-02 08:19 -1000
Re: Restricted unsigned integer range would have been better? Philip Lantz <prl@canterey.us> - 2012-08-02 08:17 -1000
Re: Restricted unsigned integer range would have been better? David Brown <david@westcontrol.removethisbit.com> - 2012-08-03 08:04 +0200
Re: Restricted unsigned integer range would have been better? "io_x" <a@b.c.invalid> - 2012-08-03 09:40 +0200
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-27 22:27 -0600
Re: Restricted unsigned integer range would have been better? Keith Thompson <kst-u@mib.org> - 2012-07-28 01:31 -0700
Re: Restricted unsigned integer range would have been better? "BartC" <bc@freeuk.com> - 2012-07-28 10:52 +0100
Re: Restricted unsigned integer range would have been better? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-28 03:31 -0700
Re: Restricted unsigned integer range would have been better? pete <pfiland@mindspring.com> - 2012-07-28 00:05 -0400
Re: Restricted unsigned integer range would have been better? Les Cargill <lcargill99@comcast.com> - 2012-07-27 23:22 -0500
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-07-27 22:35 -0600
Re: Restricted unsigned integer range would have been better? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-08-04 08:43 -0700
Re: Restricted unsigned integer range would have been better? Keith Thompson <kst-u@mib.org> - 2012-08-04 16:40 -0700
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-04 22:58 -0600
Re: Restricted unsigned integer range would have been better? Keith Thompson <kst-u@mib.org> - 2012-08-04 23:10 -0700
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-05 01:16 -0600
Re: Restricted unsigned integer range would have been better? Keith Thompson <kst-u@mib.org> - 2012-08-05 02:25 -0700
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-05 03:35 -0600
Re: Restricted unsigned integer range would have been better? Keith Thompson <kst-u@mib.org> - 2012-08-05 12:16 -0700
Re: Restricted unsigned integer range would have been better? gazelle@shell.xmission.com (Kenny McCormack) - 2012-08-05 19:56 +0000
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-06 01:12 -0600
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-06 01:07 -0600
Re: Restricted unsigned integer range would have been better? gazelle@shell.xmission.com (Kenny McCormack) - 2012-08-05 13:33 +0000
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-06 01:13 -0600
Re: Restricted unsigned integer range would have been better? "Ansel" <tinker454@trytospammenowloser.com> - 2012-08-04 22:54 -0600

Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →

#23730

From	"BartC" <bc@freeuk.com>
Date	2012-07-25 17:17 +0100
Message-ID	<jup66u$9pl$1@dont-email.me>
In reply to	#23729

"David Brown" <david@westcontrol.removethisbit.com> wrote in message
news:fZqdnYmfzYXQmY3NnZ2dnUVZ7sGdnZ2d@lyse.net...
> On 25/07/2012 14:28, Ansel wrote:

>> [Snipped the rest of the very good answer which goes on to describe the
>> type
>> system of Ada. ;)]
>>
>
> The ideas are perhaps stolen from Ada (which in turn stole them from
> Pascal and/or Modula 2).  But Ada adds a whole lot more overhead to code -
> both source code (it is a far more verbose language) and run-time (it's
> not bad, but it is less efficient than C, and has a few more "surprises"
> such as run-time range checking code).

Half-hearted attempts at extending type systems don't really work. There
will always be something else to be added, or ambiguous aspects to be tidied
up, until you end up with something like Ada.

>  My suggested stronger types could be added to C without /any/ extra
> overhead - nothing more at run-time, and only more source code typing if
> you actually use the features.

You will need to assign an int value to your range type at some point. Then
it will need a runtime range-check. 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.

In fact there will be all sorts of issues; these things are never quite that 
simple.

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#23740

From	David Brown <david@westcontrol.removethisbit.com>
Date	2012-07-26 12:07 +0200
Message-ID	<kuydnaVADZU_hYzNnZ2dnUVZ8tadnZ2d@lyse.net>
In reply to	#23730

On 25/07/2012 18:17, BartC wrote:
> "David Brown" <david@westcontrol.removethisbit.com> wrote in message
> news:fZqdnYmfzYXQmY3NnZ2dnUVZ7sGdnZ2d@lyse.net...
>> On 25/07/2012 14:28, Ansel wrote:
>
>>> [Snipped the rest of the very good answer which goes on to
>>> describe the type system of Ada. ;)]
>>>
>>
>> The ideas are perhaps stolen from Ada (which in turn stole them
>> from Pascal and/or Modula 2).  But Ada adds a whole lot more
>> overhead to code - both source code (it is a far more verbose
>> language) and run-time (it's not bad, but it is less efficient than
>> C, and has a few more "surprises" such as run-time range checking
>> code).
>
> Half-hearted attempts at extending type systems don't really work.
> There will always be something else to be added, or ambiguous aspects
> to be tidied up, until you end up with something like Ada.

Perhaps.  I haven't thought this through much beyond the time it took to 
write these posts - I am well aware of the possibility of other issues 
turning up if someone were to try to implement these ideas and try them 
out in real life.

>
>> My suggested stronger types could be added to C without /any/
>> extra overhead - nothing more at run-time, and only more source
>> code typing if you actually use the features.
>
> 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.

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).  And just like for "int", you 
don't need overflow checking - you just declare it as "undefined behaviour".

> In fact there will be all sorts of issues; these things are never
> quite that simple.
>

I'm sure there would be issues - just not these ones!

[toc] | [prev] | [next] | [standalone]

#23742

From	"BartC" <bc@freeuk.com>
Date	2012-07-26 14:06 +0100
Message-ID	<jurfdf$nhc$1@dont-email.me>
In reply to	#23740

"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

[toc] | [prev] | [next] | [standalone]

#23743

From	James Kuyper <jameskuyper@verizon.net>
Date	2012-07-26 09:45 -0400
Message-ID	<jurhl9$59u$1@dont-email.me>
In reply to	#23742

On 07/26/2012 09:06 AM, BartC wrote:
> "David Brown" <david@westcontrol.removethisbit.com> wrote in message
> news:kuydnaVADZU_hYzNnZ2dnUVZ8tadnZ2d@lyse.net...
...
> There is already a kind of restricted int in C, called a _Bool, which can
> only contain (I believe) 0 or 1.

It can only be assigned a value of 0 or 1. By type punning it could be
given bit patterns that represent other values; the behavior when you
attempt to read the value of the object after such type punning is
undefined, of course.

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

Good, that's precisely what's required by the standard.

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

A cast expression always means "unconditionally convert" - inserting
"please" implies a degree of freedom that conforming implementations
don't have. The only time a cast implies "no conversion" is when the
compiler knows that no conversion is needed (for example, when
converting to the same type, or a type with the same representation, or
a literal value known to have the same representation in both types).
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#23926

From	David Brown <david@westcontrol.removethisbit.com>
Date	2012-07-30 09:01 +0200
Message-ID	<teWdndNMqNiFrovNnZ2dnUVZ8u6dnZ2d@lyse.net>
In reply to	#23742

On 26/07/2012 15:06, BartC wrote:
> "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.
>

Yes, assigning an int to a _Bool does a !! operation.

The compiler (various gcc versions in my tests) does seem to take 
advantage of the knowledge that a _Bool is either 0 or 1, at least 
sometimes.

For casting to a _Bool, this is the behaviour you want - it is important 
that it behaves like an "if" statement.

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

True enough.  However, I think the situation is different from _Bool - a 
_Bool is not just a restricted integer range, but the cacheable result 
of a conditional.

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

But for a signed int, you /know/ that it will not always result in a 
valid int - it will be undefined when you wrap.  Thus the compiler 
/knows/ that adding 1 to a signed int will never result in a negative 
number - either it will be a positive number, or the result is undefined 
(and it can then do as it wants - including assuming it is positive).

The same would apply to a restricted-range integers.

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

Yes, and it's fine to do so.  It's just normal C "undefined behaviour". 
  It's up to the programmer to make sure it doesn't happen, or that it 
doesn't matter if it happens.

What could a compiler do here anyway, that is actually better than 
"undefined" for the programmer?  Limiting the results to 1 to 10 
wouldchange the semantics of the type - turning it into a saturating 
type.  C doesn't have exceptions to throw (not that any sane programmer 
would want an exception here).  Calling some error function or abort() 
would be a disaster.  The compiler /could/ do any of these things, since 
the behaviour is undefined.  But the most efficient code would be 
generated by simply ignoring the possibility - and that is the 
functionality a programmer would want.

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

[toc] | [prev] | [next] | [standalone]

#23736

From	"Ansel" <tinker454@trytospammenowloser.com>
Date	2012-07-26 00:09 -0600
Message-ID	<juqn0a$r3n$1@speranza.aioe.org>
In reply to	#23729

"David Brown" <david@westcontrol.removethisbit.com> wrote in message 
news:fZqdnYmfzYXQmY3NnZ2dnUVZ7sGdnZ2d@lyse.net...
> On 25/07/2012 14:28, Ansel wrote:
>> "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 ;).
>
> I still don't understand why you think arithmetic operations are not 
> useful on unsigned types, nor why you are so keen on signed types.  It is 
> /rare/ in any real-world program (embedded or otherwise) for integer data 
> to be negative - the majority of "int" variables will never be less than 
> zero.  (The exception is the somewhat artificial convention in C for error 
> codes to be negative.)  So why not use unsigned types and get a little 
> more useful range, as well as well-defined overflow and wrapping 
> semantics?
>

In an effort to simplify, if something is just a tad "useful" instead of 
necessary, maybe it would be better to go without. It's not a "keeness" on 
signed types, it's that if there can be one abstraction instead of two, then 
maybe a little bit of usefulness can be given up for greater simplicity. The 
simplification is, of course, not having to deal with mixed-type arithmetic, 
which my OP was seeking to simplify somewhat by range-restricting the 
unsigned types. I don't know exactly what my train of thought was when I 
posted, but right now I wonder why I would want to range-restrict unsigneds 
instead of just using signeds! I'm not sure -- my mind is elsewhere.

>>
>>> 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. ;)]
>>
>
> The ideas are perhaps stolen from Ada (which in turn stole them from 
> Pascal and/or Modula 2).  But Ada adds a whole lot more overhead to code - 
> both source code (it is a far more verbose language) and run-time (it's 
> not bad, but it is less efficient than C, and has a few more "surprises" 
> such as run-time range checking code).  My suggested stronger types could 
> be added to C without /any/ extra overhead - nothing more at run-time, and 
> only more source code typing if you actually use the features.  In fact, 
> range types could give the compiler scope for additional optimisations 
> since it has greater knowledge.

Well, there's a spec for saturating integers somewhere already -- that may 
be a start in the right direction. I'm all for various types of integers 
with different semantics. In your prior post, you noted the need for a 
typedef of somekind to keep it under control and I too think some kind of 
construct like that is necessary to make it work. Realize what that actually 
is though: some kind of "incompatible type" builder. After you think about 
that for awhile, you'll start to want a "compatible type" builder. Then a 
"semi-compatible type" builder. Then you realize you can have all that much 
easier and more elegantly if you switch programming languages. "The right 
tool for the job".

[toc] | [prev] | [next] | [standalone]

#23738

From	Malcolm McLean <malcolm.mclean5@btinternet.com>
Date	2012-07-26 00:52 -0700
Message-ID	<93de2216-058c-4858-b341-d84c1ad4268e@googlegroups.com>
In reply to	#23736

בתאריך יום חמישי, 26 ביולי 2012 07:09:26 UTC+1, מאת Ansel:

> signed types, it's that if there can be one abstraction instead of two, then 
> maybe a little bit of usefulness can be given up for greater simplicity. The 
> simplification is, of course, not having to deal with mixed-type arithmetic, 
> which my OP was seeking to simplify somewhat by range-restricting the 
> unsigned types. I don&#39;t know exactly what my train of thought was when I 
> posted, but right now I wonder why I would want to range-restrict unsigneds 
> instead of just using signeds! I'm not sure -- my mind is elsewhere.
> 
Conisder this. It's a real problem in my current program.

I've got a buffer z, with length N. I'm passed in an index and a window length. I want to take a window of the buffer.

Now of course this is trivial to code, because ints are 32 bits and the buffer's never going to go above a few hundred samples. Just don't use unsigned arithmetic and the code is clean and simple. If anyone does pass in a maliciously large buffer and window, you hope that the system will detect it and stop the program due to arithmetical overflow.
But imagine we're using unsigned because N and the window centre, ci, are naturally unsigned, and buffer _ window length is likely to be over the range of an unsigned. Now we've got real problems. Do you or do you not alleviate the coding difficulties by saying that unsigned cannot go beyond the range of a signed?

We don't need to change any compilers. Just insert a line into the standard saying that "the result of assigning a value greater than INT_MAX to an unsigned int is undefined".

[toc] | [prev] | [next] | [standalone]

#23774

From	pete <pfiland@mindspring.com>
Date	2012-07-26 20:35 -0400
Message-ID	<5011E247.1F7B@mindspring.com>
In reply to	#23604

Ansel wrote:

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

I have always found 
programming with unsigned integers 
to be simple and easy,
so your point of view 
is difficult for me to understand.

-- 
pete

[toc] | [prev] | [next] | [standalone]

#23785

From	"Ansel" <tinker454@trytospammenowloser.com>
Date	2012-07-26 22:35 -0600
Message-ID	<jut5td$fei$1@speranza.aioe.org>
In reply to	#23774

"pete" <pfiland@mindspring.com> wrote in message 
news:5011E247.1F7B@mindspring.com...
> Ansel wrote:
>
>> 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?
>
> I have always found
> programming with unsigned integers
> to be simple and easy,
> so your point of view
> is difficult for me to understand.
>

Mixed-type operations (signed, unsigned) perhaps more complex than 
necessary.

[toc] | [prev] | [next] | [standalone]

#23794

From	pete <pfiland@mindspring.com>
Date	2012-07-27 09:19 -0400
Message-ID	<5012954D.20C@mindspring.com>
In reply to	#23785

Ansel wrote:
> 
> "pete" <pfiland@mindspring.com> wrote in message
> news:5011E247.1F7B@mindspring.com...
> > Ansel wrote:
> >
> >> 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?
> >
> > I have always found
> > programming with unsigned integers
> > to be simple and easy,
> > so your point of view
> > is difficult for me to understand.
> >
> 
> Mixed-type operations (signed, unsigned) perhaps more complex than
> necessary.

I think I see what you mean.
C is a primative tool.
As is typical of primative tools,
study and practice goes a long way towards efficacy.
Prgrammers who like C, 
tend to like the primitiveness of it.

Mixed type comparisons, is bad C coding style.

In the case of the absence of a reason to use a signed type,
my default choice for an integer type to use, 
is an unsigned integer type.

I only once recall encountering a mixed type comparison 
in code which I was maintaining.
The mixed type comparison which I encountered,
resulted from the wrong choice being made to use type (int),
where an unsigned type should have been.
The contract that I was working under,
required that the code compile without any warnings
and the compiler that we were using, 
emitted a warning for the mixed type comparison,
so I changed the (int) type object to an unsigned type.

-- 
pete

[toc] | [prev] | [next] | [standalone]

#23800

From	Les Cargill <lcargill99@comcast.com>
Date	2012-07-27 12:51 -0500
Message-ID	<juuk6k$fal$1@dont-email.me>
In reply to	#23794

pete wrote:
> Ansel wrote:
>>
>> "pete" <pfiland@mindspring.com> wrote in message
>> news:5011E247.1F7B@mindspring.com...
>>> Ansel wrote:
>>>
>>>> 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?
>>>
>>> I have always found
>>> programming with unsigned integers
>>> to be simple and easy,
>>> so your point of view
>>> is difficult for me to understand.
>>>
>>
>> Mixed-type operations (signed, unsigned) perhaps more complex than
>> necessary.
>
> I think I see what you mean.
> C is a primative tool.
> As is typical of primative tools,
> study and practice goes a long way towards efficacy.
> Prgrammers who like C,
> tend to like the primitiveness of it.
>

This is modestly silly :) C is still a *high level language*,
and there's very little you cannot do with it.

I have personally replaced a really large pile 'o Java
with a relatively small 'C' program. That wasn't
Java's fault.

Don't say "Buh GUI programming..." I'll agree there;
don't use C for that. Or just don't write GUIs.

> Mixed type comparisons, is bad C coding style.
>

Type conversions must be made explicit.

> In the case of the absence of a reason to use a signed type,
> my default choice for an integer type to use,
> is an unsigned integer type.
>

That's a way. I do it the other way 'round, but
that's fine. Having the "unsigned" keyword be the exception
adds more information to the source code and otherwise constraining*
signed ints is better than simply declaring everything unsigned.

*as in range checks..

> I only once recall encountering a mixed type comparison
> in code which I was maintaining.
> The mixed type comparison which I encountered,
> resulted from the wrong choice being made to use type (int),
> where an unsigned type should have been.
> The contract that I was working under,
> required that the code compile without any warnings
> and the compiler that we were using,
> emitted a warning for the mixed type comparison,
> so I changed the (int) type object to an unsigned type.
>


Well, there ya go.

--
Les Cargill

[toc] | [prev] | [next] | [standalone]

#23829

From	Keith Thompson <kst-u@mib.org>
Date	2012-07-27 16:19 -0700
Message-ID	<lnpq7g6bco.fsf@nuthaus.mib.org>
In reply to	#23800

Les Cargill <lcargill99@comcast.com> writes:
> pete wrote:
[...]
>> I think I see what you mean.
>> C is a primative tool.
>> As is typical of primative tools,
>> study and practice goes a long way towards efficacy.
>> Prgrammers who like C,
>> tend to like the primitiveness of it.
>
> This is modestly silly :) C is still a *high level language*,
> and there's very little you cannot do with it.

I wouldn't call C a high level language, but that depends entirely
on how you define the phrase "high level".

It's high level in the sense that C programs specify behavior,
not CPU instructions.  Of the languages that are "high level" in
that sense, I'd say that C is just about the lowest-level language
in common use.

[...]

>> Mixed type comparisons, is bad C coding style.
>
> Type conversions must be made explicit.

I presume that's meant as advice, not a language rule.

[...]

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
    Will write code for food.
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#23831

From	Les Cargill <lcargill99@comcast.com>
Date	2012-07-27 18:47 -0500
Message-ID	<juv92v$i0n$1@dont-email.me>
In reply to	#23829

Keith Thompson wrote:
> Les Cargill <lcargill99@comcast.com> writes:
>> pete wrote:
> [...]
>>> I think I see what you mean.
>>> C is a primative tool.
>>> As is typical of primative tools,
>>> study and practice goes a long way towards efficacy.
>>> Prgrammers who like C,
>>> tend to like the primitiveness of it.
>>
>> This is modestly silly :) C is still a *high level language*,
>> and there's very little you cannot do with it.
>
> I wouldn't call C a high level language, but that depends entirely
> on how you define the phrase "high level".
>

I really think of what Hosfstadter said in "Godel, Escher, Bach" -
that there is BLOOP ( bounded loops, aka Fortran ) and FLOOP (
free loops, Algol and descendents ) and that there can be proven
to be no higher level language than FLOOP.

Perhaps that's out of context; I dunno. It just stuck with me.

Most "higher level languages" aren't about the languages but
the furniture that comes (free) with the language. granted
some of the furniture is really important...

But that's probably maximally pedantic, and I stopped
really worrying about that sort of thing long ago. For a
given app, a certain language system will be the best choice,
and it's best to go that way.

> It's high level in the sense that C programs specify behavior,
> not CPU instructions.  Of the languages that are "high level" in
> that sense, I'd say that C is just about the lowest-level language
> in common use.
>
> [...]
>
>>> Mixed type comparisons, is bad C coding style.
>>
>> Type conversions must be made explicit.
>
> I presume that's meant as advice, not a language rule.
>

Sorry - yes, it's advice.

> [...]
>

--
Les Cargill

[toc] | [prev] | [next] | [standalone]

#23927

From	David Brown <david@westcontrol.removethisbit.com>
Date	2012-07-30 09:10 +0200
Message-ID	<te-dnWYbGZ2hqIvNnZ2dnUVZ8sCdnZ2d@lyse.net>
In reply to	#23831

On 28/07/2012 01:47, Les Cargill wrote:
> Keith Thompson wrote:
>> Les Cargill <lcargill99@comcast.com> writes:

>>
>>>> Mixed type comparisons, is bad C coding style.
>>>
>>> Type conversions must be made explicit.
>>
>> I presume that's meant as advice, not a language rule.
>>
>
> Sorry - yes, it's advice.
>

Good advice.

For my work, it is more than advice - it is a style rule, and I enforce 
it with compiler warnings (-Wconversion -Wsign-conversion in gcc).

But of course, opinions and requirements vary on this sort of thing.

[toc] | [prev] | [next] | [standalone]

#24037

From	Philip Lantz <prl@canterey.us>
Date	2012-07-31 17:26 -1000
Message-ID	<MPG.2a8225bcdb731a4798968a@news.eternal-september.org>
In reply to	#23927

David Brown wrote:
> Les Cargill wrote:
> > Keith Thompson wrote:
> >> Les Cargill writes:
> >>> Type conversions must be made explicit.
> >>
> >> I presume that's meant as advice, not a language rule.
> >
> > Sorry - yes, it's advice.
> 
> Good advice.
> 
> For my work, it is more than advice - it is a style rule, and I enforce 
> it with compiler warnings (-Wconversion -Wsign-conversion in gcc).

Do you really? Would you use casts in situations like these?
  1. char c = 'x';
  2. int *p = malloc(N * sizeof *p);
  3. free(p);
  4. printf("%c\n", c);
  5. while (*s != '\0')
         n = n * 10 + (*s - '0');

I would find them to be undesirable clutter.

[toc] | [prev] | [next] | [standalone]

#24038

From	pete <pfiland@mindspring.com>
Date	2012-08-01 00:18 -0400
Message-ID	<5018AE22.152C@mindspring.com>
In reply to	#24037

Philip Lantz wrote:
> 
> David Brown wrote:
> > Les Cargill wrote:
> > > Keith Thompson wrote:
> > >> Les Cargill writes:
> > >>> Type conversions must be made explicit.
> > >>
> > >> I presume that's meant as advice, not a language rule.
> > >
> > > Sorry - yes, it's advice.
> >
> > Good advice.
> >
> > For my work, it is more than advice - it is a style rule,
> > and I enforce
> > it with compiler warnings (-Wconversion -Wsign-conversion in gcc).
> 
> Do you really? Would you use casts in situations like these?
>   1. char c = 'x';
>   2. int *p = malloc(N * sizeof *p);
>   3. free(p);
>   4. printf("%c\n", c);
>   5. while (*s != '\0')
>          n = n * 10 + (*s - '0');
> 
> I would find them to be undesirable clutter.

I was thinking the same thing.

And I think you meant to imply 
that (*s) is an expression of type char.

If n is of type int and also not negative,
then you could write without having to use parentheses
    n = n * 10 - '0' + *s;
with no possibility of overflow.

-- 
pete

[toc] | [prev] | [next] | [standalone]

#24040

From	"io_x" <a@b.c.invalid>
Date	2012-08-01 10:19 +0200
Message-ID	<5018e50a$0$17955$4fafbaef@reader1.news.tin.it>
In reply to	#24038

"pete" <pfiland@mindspring.com> ha scritto nel messaggio
news:5018AE22.152C@mindspring.com...
> Philip Lantz wrote:
>>
>> David Brown wrote:
>> > Les Cargill wrote:
>> > > Keith Thompson wrote:
>> > >> Les Cargill writes:
>> > >>> Type conversions must be made explicit.
>> > >>
>> > >> I presume that's meant as advice, not a language rule.
>> > >
>> > > Sorry - yes, it's advice.
>> >
>> > Good advice.
>> >
>> > For my work, it is more than advice - it is a style rule,
>> > and I enforce
>> > it with compiler warnings (-Wconversion -Wsign-conversion in gcc).
>>
>> Do you really? Would you use casts in situations like these?
>>   1. char c = 'x';
>>   2. int *p = malloc(N * sizeof *p);
>>   3. free(p);
>>   4. printf("%c\n", c);
>>   5. while (*s != '\0')
>>          n = n * 10 + (*s - '0');
>>
>> I would find them to be undesirable clutter.
>
> I was thinking the same thing.
>
> And I think you meant to imply
> that (*s) is an expression of type char.
>
> If n is of type int and also not negative,
> then you could write without having to use parentheses
>    n = n * 10 - '0' + *s;
> with no possibility of overflow.

this is one algo, one has to write in asm
not in C...; one operation to one operation
see if some generate overflow and other code
for return error

the above expression has
a possible overflow when s point to
a string of many char digit 0-9
as example
s="1111111111111111111111111111111111111111"
when n is a 32 bit unsigned [possible
64 bit unsigned too but i not sure of that]

[toc] | [prev] | [next] | [standalone]

#24042

From	David Brown <david@westcontrol.removethisbit.com>
Date	2012-08-01 10:09 +0200
Message-ID	<P4Odncjoya6Oe4XNnZ2dnUVZ8iSdnZ2d@lyse.net>
In reply to	#24038

On 01/08/2012 06:18, pete wrote:
> Philip Lantz wrote:
>>
>> David Brown wrote:
>>> Les Cargill wrote:
>>>> Keith Thompson wrote:
>>>>> Les Cargill writes:
>>>>>> Type conversions must be made explicit.
>>>>>
>>>>> I presume that's meant as advice, not a language rule.
>>>>
>>>> Sorry - yes, it's advice.
>>>
>>> Good advice.
>>>
>>> For my work, it is more than advice - it is a style rule,
>>> and I enforce
>>> it with compiler warnings (-Wconversion -Wsign-conversion in gcc).
>>
>> Do you really? Would you use casts in situations like these?
>>    1. char c = 'x';
>>    2. int *p = malloc(N * sizeof *p);
>>    3. free(p);
>>    4. printf("%c\n", c);
>>    5. while (*s != '\0')
>>           n = n * 10 + (*s - '0');
>>
>> I would find them to be undesirable clutter.
>
> I was thinking the same thing.
>
> And I think you meant to imply
> that (*s) is an expression of type char.
>
> If n is of type int and also not negative,
> then you could write without having to use parentheses
>      n = n * 10 - '0' + *s;
> with no possibility of overflow.
>

You could also write it as "n = ((n << 2) + n) << 1 - '0' + *s", and a 
dozen other ways that give the same result.  But why would you do so? 
The parenthesis in the original version are there to make the purpose of 
the expression clear - obfuscating it to avoid a couple of parenthesis 
is just silly.

[toc] | [prev] | [next] | [standalone]

#24047

From	Ben Bacarisse <ben.usenet@bsb.me.uk>
Date	2012-08-01 12:51 +0100
Message-ID	<0.41a5266becbe1d48f128.20120801125152BST.87r4rq4yp3.fsf@bsb.me.uk>
In reply to	#24042

David Brown <david@westcontrol.removethisbit.com> writes:

> On 01/08/2012 06:18, pete wrote:
>> Philip Lantz wrote:
>>>
>>> David Brown wrote:
>>>> Les Cargill wrote:
>>>>> Keith Thompson wrote:
>>>>>> Les Cargill writes:
>>>>>>> Type conversions must be made explicit.
>>>>>>
>>>>>> I presume that's meant as advice, not a language rule.
>>>>>
>>>>> Sorry - yes, it's advice.
>>>>
>>>> Good advice.
>>>>
>>>> For my work, it is more than advice - it is a style rule,
>>>> and I enforce
>>>> it with compiler warnings (-Wconversion -Wsign-conversion in gcc).
>>>
>>> Do you really? Would you use casts in situations like these?
>>>    1. char c = 'x';
>>>    2. int *p = malloc(N * sizeof *p);
>>>    3. free(p);
>>>    4. printf("%c\n", c);
>>>    5. while (*s != '\0')
>>>           n = n * 10 + (*s - '0');
>>>
>>> I would find them to be undesirable clutter.
>>
>> I was thinking the same thing.
>>
>> And I think you meant to imply
>> that (*s) is an expression of type char.
>>
>> If n is of type int and also not negative,
>> then you could write without having to use parentheses
>>      n = n * 10 - '0' + *s;
>> with no possibility of overflow.

I don't understand that.  Did you mean "and also unsigned" rather than
"and also not negative"?

> You could also write it as "n = ((n << 2) + n) << 1 - '0' + *s", and a
> dozen other ways that give the same result.

  n = (((n << 2) + n) << 1) - '0' + *s"

>  But why would you do so?
> The parenthesis in the original version are there to make the purpose
> of the expression clear - obfuscating it to avoid a couple of
> parenthesis is just silly.

It's inevitable: any post about how important parentheses are will be
missing parentheses!

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#24048

From	pete <pfiland@mindspring.com>
Date	2012-08-01 08:18 -0400
Message-ID	<50191E78.CDB@mindspring.com>
In reply to	#24047

Ben Bacarisse wrote:
> 
> David Brown <david@westcontrol.removethisbit.com> writes:
> 
> > On 01/08/2012 06:18, pete wrote:
> >> Philip Lantz wrote:
> >>>
> >>> David Brown wrote:
> >>>> Les Cargill wrote:
> >>>>> Keith Thompson wrote:
> >>>>>> Les Cargill writes:
> >>>>>>> Type conversions must be made explicit.
> >>>>>>
> >>>>>> I presume that's meant as advice, not a language rule.
> >>>>>
> >>>>> Sorry - yes, it's advice.
> >>>>
> >>>> Good advice.
> >>>>
> >>>> For my work, it is more than advice - it is a style rule,
> >>>> and I enforce
> >>>> it with compiler warnings (-Wconversion -Wsign-conversion in gcc).
> >>>
> >>> Do you really? Would you use casts in situations like these?
> >>>    1. char c = 'x';
> >>>    2. int *p = malloc(N * sizeof *p);
> >>>    3. free(p);
> >>>    4. printf("%c\n", c);
> >>>    5. while (*s != '\0')
> >>>           n = n * 10 + (*s - '0');
> >>>
> >>> I would find them to be undesirable clutter.
> >>
> >> I was thinking the same thing.
> >>
> >> And I think you meant to imply
> >> that (*s) is an expression of type char.
> >>
> >> If n is of type int and also not negative,
> >> then you could write without having to use parentheses
> >>      n = n * 10 - '0' + *s;
> >> with no possibility of overflow.
> 
> I don't understand that.  Did you mean "and also unsigned" rather than
> "and also not negative"?

No. 
It reminded me of a line from a toy atoi 
that I once wrote as an exercise.



int 
a_toi(const char *nptr)
{
    int n;

    n = 0;
    while (isspace(*nptr)) {
        ++nptr;
    }
    if (*nptr != '-') {
        if (*nptr == '+') {
            ++nptr;
        }
        while (isdigit(*nptr)) {
            n = 10 * n - '0' + *nptr++;
        }
    } else {
        ++nptr;
        while (isdigit(*nptr)) {
            n = 10 * n + '0' - *nptr++;
        } 
    }
    return n;
}

-- 
pete

[toc] | [prev] | [next] | [standalone]

Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →

csiph-web

Restricted unsigned integer range would have been better?

Contents

#23730

#23740

#23742

#23743

#23926

#23736

#23738

#23774

#23785

#23794

#23800

#23829

#23831

#23927

#24037

#24038

#24040

#24042

#24047

#24048