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 2 of 6 — ← Prev page 1 [2] 3 4 5 6 Next page →

#23681

From	"BartC" <bc@freeuk.com>
Date	2012-07-24 18:41 +0100
Message-ID	<jummpa$huv$1@dont-email.me>
In reply to	#23675

"BartC" <bc@freeuk.com> wrote in message news:jum7f0$crk$1@dont-email.me...

> 32-bit: 2 billion to 4 billion approx
> 64-bit: 9 to 18 trillion approx

'Trillion' here has the old British meaning, 1e18. I don't know how many 
zillions that would be now.

-- 
Bartc

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

#23685

From	Malcolm McLean <malcolm.mclean5@btinternet.com>
Date	2012-07-24 12:37 -0700
Message-ID	<828b196d-a3f0-452d-8ff5-b8c84c2db837@googlegroups.com>
In reply to	#23675

בתאריך יום שלישי, 24 ביולי 2012 14:20:09 UTC+1, מאת Bart:
> Malcolm McLean malcolm.mclean5@btinternet.com&gt; wrote in message 
> 
> What you're saying is that you could live with a set of numeric types 
> where these ranges:
> 
> 16-bit: 32768 to 65535 (32769 to 65535 in OP's scheme)
> 32-bit: 2 billion to 4 billion approx
> 64-bit: 9 to 18 trillion approx
> 
> simply don't exist? 
>
Numbers which can go over 32768 but never over 65535 can't be represented efficiently. That's bearable. Normally if a number can go over 32768 you'll want a bigger safety margin than 65535. For instance carbon 14 dates can currently be pushed back to about 50,000 years ago. So you could represent them as 16 bit unsigned ints. But you'd be foolish to do so, because the software will break if there's an improvement in the technology.

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

#23695

From	"Ansel" <tinker454@trytospammenowloser.com>
Date	2012-07-24 16:15 -0600
Message-ID	<jun79l$2nd$2@speranza.aioe.org>
In reply to	#23665

"BartC" <bc@freeuk.com> wrote in message news:julvgs$ums$1@dont-email.me...
>
>
> "Malcolm McLean" <malcolm.mclean5@btinternet.com> wrote in message
> news:ca08c533-bbd7-45b4-b9c4-391770c358cd@googlegroups.com...
>> ?????? ??? ?????, 24 ????? 2012 10:43:52 UTC+1, ??? Bart:
>>>
>>> But, what's special about 8-bits
>>> that they ought to be allowed a conventional unsigned range
>
>> Also, as ranges get smaller, you're more likely to use the upper half of
>> the range.
>
>>Similarly it's unlikely that you have a need for between 32,000 and 64,000
>>glyphs.
>
> Unicode seems to think it needs that many (more in fact).
>
> But, any time you want to treat two 8-bit bytes as a single 16-bit unit, 
> or
> four as 32-bit, it would be crazy not to have a suitable type to represent 
> that, without having to treat half the possible values as negative 
> numbers.
> How would you right-shift the result for example?
>

The point is that it is more likely to be a "damn, I really needed that 
extra range" situation with 8-bits than for wider widths. Indeed, most of 
the time you'd probably choose the 32-bit or 64-bit type rather than that 
"in-betweener" 16-bit type anyway, as you either really need the space 
efficiency or you go to the "platform word" type.

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

#23694

From	"Ansel" <tinker454@trytospammenowloser.com>
Date	2012-07-24 16:05 -0600
Message-ID	<jun6d8$mt$1@speranza.aioe.org>
In reply to	#23661

"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

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

#23710

From	Keith Thompson <kst-u@mib.org>
Date	2012-07-24 23:28 -0700
Message-ID	<lnd33k8ic5.fsf@nuthaus.mib.org>
In reply to	#23694

"Ansel" <tinker454@trytospammenowloser.com> writes:
> "BartC" <bc@freeuk.com> wrote in message news:julqqp$5qg$1@dont-email.me...
[...]
>> 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.

Except that that's exactly what you said.

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

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

#23713

From	"Ansel" <tinker454@trytospammenowloser.com>
Date	2012-07-25 01:13 -0600
Message-ID	<juo6ns$vbq$2@speranza.aioe.org>
In reply to	#23710

"Keith Thompson" <kst-u@mib.org> wrote in message 
news:lnd33k8ic5.fsf@nuthaus.mib.org...
> "Ansel" <tinker454@trytospammenowloser.com> writes:
>> "BartC" <bc@freeuk.com> wrote in message 
>> news:julqqp$5qg$1@dont-email.me...
> [...]
>>> 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.
>
> Except that that's exactly what you said.

And it is still picking nits.

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

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

#23721

From	Keith Thompson <kst-u@mib.org>
Date	2012-07-25 01:26 -0700
Message-ID	<ln1uk08cw1.fsf@nuthaus.mib.org>
In reply to	#23713

"Ansel" <tinker454@trytospammenowloser.com> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message 
> news:lnd33k8ic5.fsf@nuthaus.mib.org...
>> "Ansel" <tinker454@trytospammenowloser.com> writes:
>>> "BartC" <bc@freeuk.com> wrote in message 
>>> news:julqqp$5qg$1@dont-email.me...
>> [...]
>>>> 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.
>>
>> Except that that's exactly what you said.
>
> And it is still picking nits.

How so?  We have no way of knowing what you meant other than reading
what you actually 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?

Based on your recent followup to one of my followups, I *think* you
intended signed integer types to have symmetric ranges, so a signed
integer might have a range of -32767..+32767, and the corresponding
unsigned integer would have a range of 0..+32767.  That was not at all
clear from what you originally wrote.

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

#23724

From	"Ansel" <tinker454@trytospammenowloser.com>
Date	2012-07-25 05:43 -0600
Message-ID	<juomrq$7ar$1@speranza.aioe.org>
In reply to	#23721

"Keith Thompson" <kst-u@mib.org> wrote in message 
news:ln1uk08cw1.fsf@nuthaus.mib.org...
> "Ansel" <tinker454@trytospammenowloser.com> writes:
>> "Keith Thompson" <kst-u@mib.org> wrote in message
>> news:lnd33k8ic5.fsf@nuthaus.mib.org...
>>> "Ansel" <tinker454@trytospammenowloser.com> writes:
>>>> "BartC" <bc@freeuk.com> wrote in message
>>>> news:julqqp$5qg$1@dont-email.me...
>>> [...]
>>>>> 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.
>>>
>>> Except that that's exactly what you said.
>>
>> And it is still picking nits.
>
> How so?  We have no way of knowing what you meant other than reading
> what you actually 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?
>
> Based on your recent followup to one of my followups, I *think* you
> intended signed integer types to have symmetric ranges, so a signed
> integer might have a range of -32767..+32767, and the corresponding
> unsigned integer would have a range of 0..+32767.  That was not at all
> clear from what you originally wrote.
>

Yes, I haphazardly expressed the thought originally.

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

#23674

From	David Brown <david@westcontrol.removethisbit.com>
Date	2012-07-24 15:10 +0200
Message-ID	<AYSdnbmo_YfvPZPNnZ2dnUVZ8lKdnZ2d@lyse.net>
In reply to	#23651

On 24/07/2012 07:48, Ansel wrote:
> "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. ;)
>

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.

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

#23697

From	"Ansel" <tinker454@trytospammenowloser.com>
Date	2012-07-24 16:23 -0600
Message-ID	<jun7c0$2ua$1@speranza.aioe.org>
In reply to	#23674

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

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

#23711

From	Keith Thompson <kst-u@mib.org>
Date	2012-07-24 23:40 -0700
Message-ID	<ln8ve88hsl.fsf@nuthaus.mib.org>
In reply to	#23697

"Ansel" <tinker454@trytospammenowloser.com> writes:
[...]
> 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"?

Probably.

What do you mean when you say they wouldn't be arithmetic types?  Would
it not be possible to perform arithmetic on them?

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

#23714

From	"Ansel" <tinker454@trytospammenowloser.com>
Date	2012-07-25 01:32 -0600
Message-ID	<juo7gr$1bc$1@speranza.aioe.org>
In reply to	#23711

"Keith Thompson" <kst-u@mib.org> wrote in message 
news:ln8ve88hsl.fsf@nuthaus.mib.org...
> "Ansel" <tinker454@trytospammenowloser.com> writes:
> [...]
>> 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"?
>
> Probably.
>
> What do you mean when you say they wouldn't be arithmetic types?  Would
> it not be possible to perform arithmetic on them?
>

Would it be possible to perform arithmetic on them? Answer: no. (Or 
*extremely* limited operations, say, increment and decrement).
(I didn't like the way you asked it. Too much potential for confusion).

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

#23722

From	Keith Thompson <kst-u@mib.org>
Date	2012-07-25 01:29 -0700
Message-ID	<lnwr1s6y7f.fsf@nuthaus.mib.org>
In reply to	#23714

"Ansel" <tinker454@trytospammenowloser.com> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message 
> news:ln8ve88hsl.fsf@nuthaus.mib.org...
>> "Ansel" <tinker454@trytospammenowloser.com> writes:
>> [...]
>>> 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"?
>>
>> Probably.
>>
>> What do you mean when you say they wouldn't be arithmetic types?  Would
>> it not be possible to perform arithmetic on them?
>
> Would it be possible to perform arithmetic on them? Answer: no. (Or 
> *extremely* limited operations, say, increment and decrement).
> (I didn't like the way you asked it. Too much potential for confusion). 

Then yes, that would be unworkable.  There's far too much existing
code that depends on the ability to perform arithmetic on full-width
unsigned types.

(On the other hand, C implementations are already allowed to do as you
suggest, by giving unsigned types a single padding bit.  But hardly any
implementations do so.)

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

#23725

From	"Ansel" <tinker454@trytospammenowloser.com>
Date	2012-07-25 05:45 -0600
Message-ID	<juomrr$7ar$2@speranza.aioe.org>
In reply to	#23722

"Keith Thompson" <kst-u@mib.org> wrote in message 
news:lnwr1s6y7f.fsf@nuthaus.mib.org...
> "Ansel" <tinker454@trytospammenowloser.com> writes:
>> "Keith Thompson" <kst-u@mib.org> wrote in message
>> news:ln8ve88hsl.fsf@nuthaus.mib.org...
>>> "Ansel" <tinker454@trytospammenowloser.com> writes:
>>> [...]
>>>> 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"?
>>>
>>> Probably.
>>>
>>> What do you mean when you say they wouldn't be arithmetic types?  Would
>>> it not be possible to perform arithmetic on them?
>>
>> Would it be possible to perform arithmetic on them? Answer: no. (Or
>> *extremely* limited operations, say, increment and decrement).
>> (I didn't like the way you asked it. Too much potential for confusion).
>
> Then yes, that would be unworkable.  There's far too much existing
> code that depends on the ability to perform arithmetic on full-width
> unsigned types.

But I was asking if it would have been better right from the beginning 
rather than now.

>
> (On the other hand, C implementations are already allowed to do as you
> suggest, by giving unsigned types a single padding bit.  But hardly any
> implementations do so.)
>

Good info.

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

#23733

From	Keith Thompson <kst-u@mib.org>
Date	2012-07-25 12:35 -0700
Message-ID	<lnlii77hxq.fsf@nuthaus.mib.org>
In reply to	#23725

"Ansel" <tinker454@trytospammenowloser.com> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message 
> news:lnwr1s6y7f.fsf@nuthaus.mib.org...
>> "Ansel" <tinker454@trytospammenowloser.com> writes:
>>> "Keith Thompson" <kst-u@mib.org> wrote in message
>>> news:ln8ve88hsl.fsf@nuthaus.mib.org...
>>>> "Ansel" <tinker454@trytospammenowloser.com> writes:
>>>> [...]
>>>>> 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"?
>>>>
>>>> Probably.
>>>>
>>>> What do you mean when you say they wouldn't be arithmetic types?  Would
>>>> it not be possible to perform arithmetic on them?
>>>
>>> Would it be possible to perform arithmetic on them? Answer: no. (Or
>>> *extremely* limited operations, say, increment and decrement).
>>> (I didn't like the way you asked it. Too much potential for confusion).
>>
>> Then yes, that would be unworkable.  There's far too much existing
>> code that depends on the ability to perform arithmetic on full-width
>> unsigned types.
>
> But I was asking if it would have been better right from the beginning 
> rather than now.

If you'll clearly restate your proposal in a single article, it
will be easier to judge.  Currently we have your original article
with miscellaneous clarifications scattered throughout the thread,
which has created a lot of misunderstanding.

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

#23737

From	"Ansel" <tinker454@trytospammenowloser.com>
Date	2012-07-26 00:12 -0600
Message-ID	<juqn6k$r9e$1@speranza.aioe.org>
In reply to	#23733

"Keith Thompson" <kst-u@mib.org> wrote in message 
news:lnlii77hxq.fsf@nuthaus.mib.org...
> "Ansel" <tinker454@trytospammenowloser.com> writes:
>> "Keith Thompson" <kst-u@mib.org> wrote in message
>> news:lnwr1s6y7f.fsf@nuthaus.mib.org...
>>> "Ansel" <tinker454@trytospammenowloser.com> writes:
>>>> "Keith Thompson" <kst-u@mib.org> wrote in message
>>>> news:ln8ve88hsl.fsf@nuthaus.mib.org...
>>>>> "Ansel" <tinker454@trytospammenowloser.com> writes:
>>>>> [...]
>>>>>> 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"?
>>>>>
>>>>> Probably.
>>>>>
>>>>> What do you mean when you say they wouldn't be arithmetic types? 
>>>>> Would
>>>>> it not be possible to perform arithmetic on them?
>>>>
>>>> Would it be possible to perform arithmetic on them? Answer: no. (Or
>>>> *extremely* limited operations, say, increment and decrement).
>>>> (I didn't like the way you asked it. Too much potential for confusion).
>>>
>>> Then yes, that would be unworkable.  There's far too much existing
>>> code that depends on the ability to perform arithmetic on full-width
>>> unsigned types.
>>
>> But I was asking if it would have been better right from the beginning
>> rather than now.
>
> If you'll clearly restate your proposal in a single article, it
> will be easier to judge.  Currently we have your original article
> with miscellaneous clarifications scattered throughout the thread,
> which has created a lot of misunderstanding.
>

Will you please review my latest replies to D. Brown in this thread and see 
if that answers your questions or interject there? I really don't want to 
restart from the beginning because so much has changed (perspective) since 
then.

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

#23739

From	Keith Thompson <kst-u@mib.org>
Date	2012-07-26 01:42 -0700
Message-ID	<lnehny7w2n.fsf@nuthaus.mib.org>
In reply to	#23737

"Ansel" <tinker454@trytospammenowloser.com> writes:
> "Keith Thompson" <kst-u@mib.org> wrote in message 
> news:lnlii77hxq.fsf@nuthaus.mib.org...
[...]
>> If you'll clearly restate your proposal in a single article, it
>> will be easier to judge.  Currently we have your original article
>> with miscellaneous clarifications scattered throughout the thread,
>> which has created a lot of misunderstanding.
>>
>
> Will you please review my latest replies to D. Brown in this thread and see 
> if that answers your questions or interject there? I really don't want to 
> restart from the beginning because so much has changed (perspective) since 
> then. 

Sorry, but I'm not going to take the time to reconstruct what you're
proposing by looking through multiple articles.  I *think* I found the
reply you're referring to, but it doesn't seem all that specific.

Just one point, though.

C's integer type traditionally map very closely to what's supported by
the hardware.  Your proposal would break that tradition.  For that
reason alone, I don't think it's feasible.

Something like what you're suggesting might be sensible for a new
language -- but C should still be there for programmers who want to use
the features that this new language is missing.

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

#23715

From	David Brown <david@westcontrol.removethisbit.com>
Date	2012-07-25 09:31 +0200
Message-ID	<F_qdnf8PU5byP5LNnZ2dnUVZ8j-dnZ2d@lyse.net>
In reply to	#23697

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.

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.

Someone mentioned "range types" in this thread.  I would /love/ to have 
such a system in C - as well as multiple incompatible types (meaning 
they would give compiler errors if you mix them, unless you use explicit 
casts).  The types I would like would be:

mem8_t, mem16_t, mem32_t, mem64_t (and perhaps bigger) - these would be 
for "raw" data storage, and would automatically alias any other type 
similar to the way "char" does today.

char8_t, char16_t, etc. - character types, with most arithmetic 
operations being invalid.  Without arithmetic, there is no need for this 
"signed char" and "unsigned char" idiocy.

int8_t, int16_t, uint8_t, uint16_t, etc. - arithmetic types.  There 
should be no implicit "integer promotion" - types should work exactly 
the same way on all systems, and the compiler could generate more 
efficient code for 8-bit cpus.

There should be a sort of "typedef" that produces incompatible types. 
For example, if you made a "seconds" type implemented by int16_t, and a 
"meters" type also implemented by int16_t, you could not mix them 
without explicit casts.  I don't see this as being difficult to 
implement in a compiler, and it would be zero run-time cost - while 
giving C a huge boost in the protection from simple programming errors.

"Range types" would be subtypes of other types here.  They may be 
"compatible" or "incompatible" with their "parent" types.  It is 
important the compiler would not do any sort of run-time checking of 
ranges - but it /can/ assume the range holds (and it can do compile-time 
checking, of course).  It is up to the programmer to be sure that any 
assignment is safe.

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

#23727

From	"Ansel" <tinker454@trytospammenowloser.com>
Date	2012-07-25 06:28 -0600
Message-ID	<juooqf$c1c$1@speranza.aioe.org>
In reply to	#23715

"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. ;)]

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

#23729

From	David Brown <david@westcontrol.removethisbit.com>
Date	2012-07-25 16:28 +0200
Message-ID	<fZqdnYmfzYXQmY3NnZ2dnUVZ7sGdnZ2d@lyse.net>
In reply to	#23727

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?

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

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

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

csiph-web

Restricted unsigned integer range would have been better?

Contents

#23681

#23685

#23695

#23694

#23710

#23713

#23721

#23724

#23674

#23697

#23711

#23714

#23722

#23725

#23733

#23737

#23739

#23715

#23727

#23729