Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

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

Unsinged types

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

Contents

  Unsinged types Jase Schick <nospam@nospam.com> - 2012-07-19 20:03 +0000
    Re: Unsinged types Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-19 21:29 +0100
      Re: Unsinged types jacob navia <jacob@spamsink.net> - 2012-07-19 23:15 +0200
    Re: Unsinged types Robert Wessel <robertwessel2@yahoo.com> - 2012-07-19 16:46 -0500
    Re: Unsinged types Ben Pfaff <blp@cs.stanford.edu> - 2012-07-19 15:47 -0700
      Re: Unsinged types Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-19 21:06 -0400
        Re: Unsinged types Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-20 02:32 +0100
          Re: Unsinged types Stephen Sprunk <stephen@sprunk.org> - 2012-07-19 21:08 -0500
            Re: Unsinged types Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-20 04:26 +0100
          Re: Unsinged types Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-19 22:56 -0400
            Re: Unsinged types Kenneth Brody <kenbrody@spamcop.net> - 2012-07-20 14:57 -0400
            Re: Unsinged types Keith Thompson <kst-u@mib.org> - 2012-07-20 12:36 -0700
        Re: Unsinged types Kenneth Brody <kenbrody@spamcop.net> - 2012-07-20 14:56 -0400
      Re: Unsinged types Seungbeom Kim <musiphil@bawi.org> - 2012-07-20 14:11 -0700
        Re: Unsinged types Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-20 17:41 -0400
          Re: Unsinged types Seungbeom Kim <musiphil@bawi.org> - 2012-07-21 14:07 -0700
            Re: Unsinged types "BartC" <bc@freeuk.com> - 2012-07-21 22:26 +0100
            Re: Unsinged types Tim Rentsch <txr@alumni.caltech.edu> - 2012-07-22 00:01 -0700
              Re: Unsinged types "BartC" <bc@freeuk.com> - 2012-07-22 10:37 +0100
                Re: Unsinged types Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 11:34 -0700
              Re: Unsinged types gwowen <gwowen@gmail.com> - 2012-07-23 00:06 -0700
                Re: Unsinged types Tim Rentsch <txr@alumni.caltech.edu> - 2012-09-07 11:30 -0700
            Re: Unsinged types Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-07-22 14:29 +0300
              Re: Unsinged types "BartC" <bc@freeuk.com> - 2012-07-22 14:43 +0100
                Re: Unsinged types Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2012-07-22 19:12 +0300
              Re: Unsinged types Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-22 12:14 -0700
          Re: Unsinged types Tim Rentsch <txr@alumni.caltech.edu> - 2012-07-21 14:57 -0700
    Re: Unsinged types Nick Keighley <nick_keighley_nospam@hotmail.com> - 2012-07-20 00:11 -0700
    Re: Unsinged types Andrew Cooper <amc96@cam.ac.uk> - 2012-07-20 10:00 +0100
      Re: Unsinged types Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-20 23:48 -0700
        Re: Unsinged types Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-21 15:24 +0100
          Re: Unsinged types Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-21 08:53 -0700
            Re: Unsinged types Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-21 17:48 +0100
              Re: Unsinged types Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-21 11:22 -0700
                Re: Unsinged types Ben Bacarisse <ben.usenet@bsb.me.uk> - 2012-07-21 22:35 +0100
                  Re: Unsinged types Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-21 14:55 -0700
            Re: Unsinged types "BartC" <bc@freeuk.com> - 2012-07-21 18:27 +0100
              Re: Unsinged types Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-21 11:37 -0700
                Re: Unsinged types Kenneth Brody <kenbrody@spamcop.net> - 2012-07-23 14:02 -0400
                  Re: Unsinged types Malcolm McLean <malcolm.mclean5@btinternet.com> - 2012-07-23 12:21 -0700
                    Re: Unsinged types pete <pfiland@mindspring.com> - 2012-07-23 23:57 -0400
    Re: Unsinged types "Bill Leary" <Bill_Leary@msn.com> - 2012-07-20 20:21 -0400
    Re: Unsinged types "io_x" <a@b.c.invalid> - 2012-07-22 10:36 +0200

Page 1 of 3  [1] 2 3  Next page →

#23402 — Unsinged types

Hi Does C still need unsigned types? My preferred language Java manages 
perfectly well without them. Do many people ever use unsigned types 
nowadays and if so why? In a 64-bit world, the extra range is rarely 
worth the hastle it seems to me.

Jase

[toc] | [next] | [standalone]

#23403

Jase Schick <nospam@nospam.com> writes:

> Hi Does C still need unsigned types?

Yes.  C needs them because of how it defines signed integer types.
Signed integer values can be represented in one of three ways, and the
language allows signed integer arithmetic to overflow in an undefined
way.  Also, some operations on signed types are undefined (some shifts
for example).  All this is to permit the very widest possible range of
implementations without the need to simulate an arithmetic type that the
hardware does not have.

There is a language not entirely unlike C which would no longer need
them, but it would have more constrained signed integer types.

> My preferred language Java manages 
> perfectly well without them. Do many people ever use unsigned types 
> nowadays and if so why? In a 64-bit world, the extra range is rarely 
> worth the hastle it seems to me.

It's very hard to avoid using them!  malloc's argument is an unsigned
integer, the result of sizeof and strlen are unsigned values, etc.

Your argument about the 64-bit world will ring hollow to people using C
in the 16- and 32-bit words!  Whilst C99 requires a 64-bit type, there
are many environments without a C99 compiler, and probably some where
64-bit arithmetic needs to be implemented in software.

-- 
Ben.

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

#23408

Le 19/07/12 22:29, Ben Bacarisse a écrit :
>
> Your argument about the 64-bit world will ring hollow to people using C
> in the 16- and 32-bit words!  Whilst C99 requires a 64-bit type, there
> are many environments without a C99 compiler, and probably some where
> 64-bit arithmetic needs to be implemented in software.
>

Those are just efficiency details unworthy of the attention of a Java 
programmer that will always use the biggest types combined with the 
slowest possible programming. Java leads to that kind of mindset.

Java is another world.

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

#23409

On Thu, 19 Jul 2012 20:03:32 +0000 (UTC), Jase Schick
<nospam@nospam.com> wrote:

>Hi Does C still need unsigned types? My preferred language Java manages 
>perfectly well without them. Do many people ever use unsigned types 
>nowadays and if so why? In a 64-bit world, the extra range is rarely 
>worth the hastle it seems to me.


Java char is unsigned.

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

#23418

Jase Schick <nospam@nospam.com> writes:

> Hi Does C still need unsigned types? My preferred language Java manages 
> perfectly well without them. Do many people ever use unsigned types 
> nowadays and if so why? In a 64-bit world, the extra range is rarely 
> worth the hastle it seems to me.

Many quantities are naturally unsigned; for example, counts and
sizes.  These quantities are most naturally modeled with unsigned
types.

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

#23419

On 7/19/2012 6:47 PM, Ben Pfaff wrote:
> Jase Schick <nospam@nospam.com> writes:
>
>> Hi Does C still need unsigned types? My preferred language Java manages
>> perfectly well without them. Do many people ever use unsigned types
>> nowadays and if so why? In a 64-bit world, the extra range is rarely
>> worth the hastle it seems to me.
>
> Many quantities are naturally unsigned; for example, counts and
> sizes.  These quantities are most naturally modeled with unsigned
> types.

     Indeed.  If you use a singed type to hold an inherently
unsinged value, you're playing with fire.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#23420

Eric Sosman <esosman@ieee-dot-org.invalid> writes:

> On 7/19/2012 6:47 PM, Ben Pfaff wrote:
>> Jase Schick <nospam@nospam.com> writes:
>>
>>> Hi Does C still need unsigned types? My preferred language Java manages
>>> perfectly well without them. Do many people ever use unsigned types
>>> nowadays and if so why? In a 64-bit world, the extra range is rarely
>>> worth the hastle it seems to me.
>>
>> Many quantities are naturally unsigned; for example, counts and
>> sizes.  These quantities are most naturally modeled with unsigned
>> types.
>
>     Indeed.  If you use a singed type to hold an inherently
> unsinged value, you're playing with fire.

I agree with the "indeed", but I am not sure I see why you added that
one would be "playing with fire".  Can you say a bit more about that?

-- 
Ben.

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

#23421

On 19-Jul-12 20:32, Ben Bacarisse wrote:
> Eric Sosman <esosman@ieee-dot-org.invalid> writes:
>> On 7/19/2012 6:47 PM, Ben Pfaff wrote:
>>> Many quantities are naturally unsigned; for example, counts and
>>> sizes.  These quantities are most naturally modeled with unsigned
>>> types.
>>
>> Indeed.  If you use a singed type to hold an inherently unsinged
>> value, you're playing with fire.
> 
> I agree with the "indeed", but I am not sure I see why you added that
> one would be "playing with fire".  Can you say a bit more about that?

It's a clever reference to "singed" types.  Note the spelling.

I was trying to work up something similar, but he beat me to it.

S

-- 
Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

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

#23423

Stephen Sprunk <stephen@sprunk.org> writes:

> On 19-Jul-12 20:32, Ben Bacarisse wrote:
>> Eric Sosman <esosman@ieee-dot-org.invalid> writes:
>>> On 7/19/2012 6:47 PM, Ben Pfaff wrote:
>>>> Many quantities are naturally unsigned; for example, counts and
>>>> sizes.  These quantities are most naturally modeled with unsigned
>>>> types.
>>>
>>> Indeed.  If you use a singed type to hold an inherently unsinged
>>> value, you're playing with fire.
>> 
>> I agree with the "indeed", but I am not sure I see why you added that
>> one would be "playing with fire".  Can you say a bit more about that?
>
> It's a clever reference to "singed" types.  Note the spelling.
>
> I was trying to work up something similar, but he beat me to it.

Well, I'm dyslexic so that's just made my day!

-- 
Ben.

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

#23422

On 7/19/2012 9:32 PM, Ben Bacarisse wrote:
> Eric Sosman <esosman@ieee-dot-org.invalid> writes:
>
>> On 7/19/2012 6:47 PM, Ben Pfaff wrote:
>>> Jase Schick <nospam@nospam.com> writes:
>>>
>>>> Hi Does C still need unsigned types? My preferred language Java manages
>>>> perfectly well without them. Do many people ever use unsigned types
>>>> nowadays and if so why? In a 64-bit world, the extra range is rarely
>>>> worth the hastle it seems to me.
>>>
>>> Many quantities are naturally unsigned; for example, counts and
>>> sizes.  These quantities are most naturally modeled with unsigned
>>> types.
>>
>>      Indeed.  If you use a singed type to hold an inherently
>> unsinged value, you're playing with fire.
>
> I agree with the "indeed", but I am not sure I see why you added that
> one would be "playing with fire".  Can you say a bit more about that?

     It's a pnu.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#23455

On 7/19/2012 10:56 PM, Eric Sosman wrote:
[...]
>>>      Indeed.  If you use a singed type to hold an inherently
>>> unsinged value, you're playing with fire.
[...]
>      It's a pnu.

I didn't even realize the original typo was in the subject line until now, 
as the body was correct.

-- 
Kenneth Brody

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

#23458

Eric Sosman <esosman@ieee-dot-org.invalid> writes:
> On 7/19/2012 9:32 PM, Ben Bacarisse wrote:
>> Eric Sosman <esosman@ieee-dot-org.invalid> writes:
[...]
>>>      Indeed.  If you use a singed type to hold an inherently
>>> unsinged value, you're playing with fire.
>>
>> I agree with the "indeed", but I am not sure I see why you added that
>> one would be "playing with fire".  Can you say a bit more about that?
>
>      It's a pnu.

So 24-bit systems are also subject to endianness issues.  Good to know.

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

#23454

On 7/19/2012 9:06 PM, Eric Sosman wrote:
> On 7/19/2012 6:47 PM, Ben Pfaff wrote:
>> Jase Schick <nospam@nospam.com> writes:
>>
>>> Hi Does C still need unsigned types? My preferred language Java manages
>>> perfectly well without them. Do many people ever use unsigned types
>>> nowadays and if so why? In a 64-bit world, the extra range is rarely
>>> worth the hastle it seems to me.
>>
>> Many quantities are naturally unsigned; for example, counts and
>> sizes.  These quantities are most naturally modeled with unsigned
>> types.
>
>      Indeed.  If you use a singed type to hold an inherently
> unsinged value, you're playing with fire.

Typo/pun intended, or happy coincidence?

-- 
Kenneth Brody

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

#23459

On 2012-07-19 15:47, Ben Pfaff wrote:
> 
> Many quantities are naturally unsigned; for example, counts and
> sizes.  These quantities are most naturally modeled with unsigned
> types.

Things that you assume should be non-negative often turn out to be
not always so. For example, though no one thinks of a negative day
of the month, the tm_* members of struct tm are signed, because you
sometimes need to be able to represent out-of-range values.

In addition, "unsigned" in C does not only mean non-negativity,
but also implies modulo arithmetic; you can't even get the difference
between two unsigned values in the most natural way (a - b). And the
unsignedness is contagious, so (unsigned_value > -1) may not be true
and ((unsigned)negative_value > 100) may be true to your surprise.

For these reasons, I had the feeling that unsigned was dangerous and
should be limited to values which bitwise operations were intended for
(e.g. bitmasks) or values on nominal/ordinal scales (e.g. character
codes, TCP port numbers).

The reality is, however, that everyone thinks differently, similar
debates are endless, and that unsigned is widely used for other things
(e.g. counts and sizes) even in the standard library, so you have to
live with unsigned being everywhere, and learn to be careful when
mixing signed and unsigned.

-- 
Seungbeom Kim

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

#23461

On 7/20/2012 5:11 PM, Seungbeom Kim wrote:
> On 2012-07-19 15:47, Ben Pfaff wrote:
>>
>> Many quantities are naturally unsigned; for example, counts and
>> sizes.  These quantities are most naturally modeled with unsigned
>> types.
>
> Things that you assume should be non-negative often turn out to be
> not always so. For example, though no one thinks of a negative day
> of the month, the tm_* members of struct tm are signed, because you
> sometimes need to be able to represent out-of-range values.

     It's also a way to help with some calculations.  For example,
you can start from a given date, subtract fourteen from tm_mday,
re-normalize, and easily find out "What date was a fortnight
before January 5?"

> In addition, "unsigned" in C does not only mean non-negativity,
> but also implies modulo arithmetic; you can't even get the difference
> between two unsigned values in the most natural way (a - b).

     You can't do that with signed integers, either.  And in the
cases where naive subtraction doesn't work, you don't just get a
possibly surprising but predictable outcome: You get undefined
behavior.  (Ever seen someone write a qsort() comparator that just
subtracts two `int' keys and returns the difference?  Ever seen
the chaos that can result?)

> And the
> unsignedness is contagious, so (unsigned_value > -1) may not be true
> and ((unsigned)negative_value > 100) may be true to your surprise.

     Oh, come on!  You might just as well complain about double-ness
being "contagious."

     Besides, why blame the surprises on the unsigned operand?  They
don't arise from either one of the operands in isolation, but from
the combination of the two -- so the signed operand is every bit as
much to blame as the unsigned.  If you blame one, you should blame
the other equally.[*]

     [*] Okay, that doesn't always happen in real life: Doheny was
acquitted of offering the bribe that Fall was convicted of taking.
But Roaring Twenties jurisprudence is a poor model for programming!

> For these reasons, I had the feeling that unsigned was dangerous and
> should be limited to values which bitwise operations were intended for
> (e.g. bitmasks) or values on nominal/ordinal scales (e.g. character
> codes, TCP port numbers).
>
> The reality is, however, that everyone thinks differently, similar
> debates are endless, and that unsigned is widely used for other things
> (e.g. counts and sizes) even in the standard library, so you have to
> live with unsigned being everywhere, and learn to be careful when
> mixing signed and unsigned.

     ... or when mixing signed integer with long double complex, or
when mixing unsigned long with pointer-to-pointer-to-T, or ...  In
fact, your recommendation to "be careful when..." can be improved
by deleting "when" and everything after it.  Just be careful, okay?

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

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

#23514

On 2012-07-20 14:41, Eric Sosman wrote:
> On 7/20/2012 5:11 PM, Seungbeom Kim wrote:
>>
>> Things that you assume should be non-negative often turn out to be
>> not always so. For example, though no one thinks of a negative day
>> of the month, the tm_* members of struct tm are signed, because you
>> sometimes need to be able to represent out-of-range values.
> 
>     It's also a way to help with some calculations.  For example,
> you can start from a given date, subtract fourteen from tm_mday,
> re-normalize, and easily find out "What date was a fortnight
> before January 5?"

Exactly.

>> In addition, "unsigned" in C does not only mean non-negativity,
>> but also implies modulo arithmetic; you can't even get the difference
>> between two unsigned values in the most natural way (a - b).
> 
>     You can't do that with signed integers, either.

Of course, signed integers are not without their limits (and the design
limits should lie safely within the environmental limits).

However, *most* of the values we deal with are in small ranges that are
not too far from zero; ranges near INT_MAX, for example, but far from
zero are uncommon, if any, and they may need an upgrade to a larger
integer type anyway.

Given that, getting around in signed is usually safe, as you're near
the center, far from the edges, of the field. Doing that in unsigned,
however, is like playing near the edge and risks falling off.


                                  ,- usually here
                                *****
    signed      [-------+-------+-------+-------]XXXX DANGER
                |               |               |
            -INT_MAX            0            INT_MAX        UINT_MAX
                                |               |               |
  unsigned           DANGER XXXX[-------+-------+-------+-------]


> And in the cases where naive subtraction doesn't work, you don't
> just get a possibly surprising but predictable outcome: You get
> undefined behavior.

True. But (2U - 5U) yielding 4294967293U is not very useful, no matter
how predictable it is, and failing to take that into account is a bug,
just as getting undefined behavior from signed arithmetic overflow is.

>> And the
>> unsignedness is contagious, so (unsigned_value > -1) may not be true
>> and ((unsigned)negative_value > 100) may be true to your surprise.
> 
>     Oh, come on!  You might just as well complain about double-ness
> being "contagious."

Their "contagiousnesses" per se may be similar, but their effects are
different; conversion from integer to double doesn't (usually) change
the value being converted, or the result of the comparison at least,
but conversion from signed to unsigned often does, often in a very
surprising way, which is exactly my point in the paragraph above.

>     Besides, why blame the surprises on the unsigned operand?  They
> don't arise from either one of the operands in isolation, but from
> the combination of the two -- so the signed operand is every bit as
> much to blame as the unsigned.  If you blame one, you should blame
> the other equally.[*]
> 
>     [*] Okay, that doesn't always happen in real life: Doheny was
> acquitted of offering the bribe that Fall was convicted of taking.
> But Roaring Twenties jurisprudence is a poor model for programming!

Sorry, I don't understand the footnote.

Anyway, you're right that the surprises arise from the combination.
If your values are usually closer to the upper limit of signed (say,
INT_MAX) than to zero, then signed gets in the way more often and may
deserve more "blame." If, on the other hand, they are usually closer
to the lower limit of unsigned, i.e. zero, then unsigned more often
gets in the way. If both cases happen equally, you may want to blame
them equally. In most of the cases I encounter, they don't.
Your mileage may vary, though.

>> The reality is, however, that everyone thinks differently, similar
>> debates are endless, and that unsigned is widely used for other things
>> (e.g. counts and sizes) even in the standard library, so you have to
>> live with unsigned being everywhere, and learn to be careful when
>> mixing signed and unsigned.
> 
>     ... or when mixing signed integer with long double complex, or
> when mixing unsigned long with pointer-to-pointer-to-T, or ...  In
> fact, your recommendation to "be careful when..." can be improved
> by deleting "when" and everything after it.  Just be careful, okay?

It's not a unanimous improvement, as it makes my statement more general
and more "vacuously true." Maybe I should have said "be *more* careful"
to be clearer, but I won't delete the when-clause. I don't object to
your being careful in everything, though.

-- 
Seungbeom Kim

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

#23516

"Seungbeom Kim" <musiphil@bawi.org> wrote in message 
news:juf5mm$mr$1@usenet.stanford.edu...
> On 2012-07-20 14:41, Eric Sosman wrote:
>> On 7/20/2012 5:11 PM, Seungbeom Kim wrote:

>>> In addition, "unsigned" in C does not only mean non-negativity,
>>> but also implies modulo arithmetic; you can't even get the difference
>>> between two unsigned values in the most natural way (a - b).
>>
>>     You can't do that with signed integers, either.
>
> Of course, signed integers are not without their limits (and the design
> limits should lie safely within the environmental limits).
>
> However, *most* of the values we deal with are in small ranges that are
> not too far from zero; ranges near INT_MAX, for example, but far from
> zero are uncommon, if any, and they may need an upgrade to a larger
> integer type anyway.
>
> Given that, getting around in signed is usually safe, as you're near
> the center, far from the edges, of the field. Doing that in unsigned,
> however, is like playing near the edge and risks falling off.
>
>
>                                  ,- usually here
>                                *****
>    signed      [-------+-------+-------+-------]XXXX DANGER
>                |               |               |
>            -INT_MAX            0            INT_MAX        UINT_MAX
>                                |               |               |
>  unsigned           DANGER XXXX[-------+-------+-------+-------]
>
>
>> And in the cases where naive subtraction doesn't work, you don't
>> just get a possibly surprising but predictable outcome: You get
>> undefined behavior.
>
> True. But (2U - 5U) yielding 4294967293U is not very useful, no matter
> how predictable it is

You've put the point across much better than I've ever been able to, in many 
more posts (-1<5 is true, -1<5u is false, etc.)

But, the language is apparently always right. Even if it's due to 'existing 
practice'.

-- 
bartc 

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

#23553

Seungbeom Kim <musiphil@bawi.org> writes:

> On 2012-07-20 14:41, Eric Sosman wrote:
[snip]
>> And in the cases where naive subtraction doesn't work, you don't
>> just get a possibly surprising but predictable outcome: You get
>> undefined behavior.
>
> True. But (2U - 5U) yielding 4294967293U is not very useful, no matter
> how predictable it is, [snip]

That's an overstatement.  It may not be useful in ways that
you would like it to be, or in all the cases you would like
it to be, but there still are lots of cases where it is
useful.  To give one example, if we want to test if
variable 'i' is in the range [20 .. 30), with signed
arithmetic that takes two comparisons, but with unsigned
arithmetic this can be done with one comparison:

    if(  (i-20u) < 10  ) ...

Unsigned arithmetic doesn't behave in a way that most
people are used to, but the behavior it has still is
quite useful, in lots of different ways.

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

#23560

"Tim Rentsch" <txr@alumni.caltech.edu> wrote in message 
news:kfnfw8k1dpf.fsf@x-alumni2.alumni.caltech.edu...
> Seungbeom Kim <musiphil@bawi.org> writes:
>
>> On 2012-07-20 14:41, Eric Sosman wrote:
> [snip]
>>> And in the cases where naive subtraction doesn't work, you don't
>>> just get a possibly surprising but predictable outcome: You get
>>> undefined behavior.
>>
>> True. But (2U - 5U) yielding 4294967293U is not very useful, no matter
>> how predictable it is, [snip]
>
> That's an overstatement.  It may not be useful in ways that
> you would like it to be, or in all the cases you would like
> it to be, but there still are lots of cases where it is
> useful.  To give one example, if we want to test if
> variable 'i' is in the range [20 .. 30), with signed
> arithmetic that takes two comparisons, but with unsigned
> arithmetic this can be done with one comparison:
>
>    if(  (i-20u) < 10  ) ...

You're replacing two comparisons, with a comparison and a subtraction, and 
now have code that will cause people to scratch their heads (with the 
mysterious introduction of '10' and '20u') instead of just writing:

   if (i>=20 && i<30)

and leaving it to the compiler to sort out, as we're constantly told to do. 
It's possible also that i will be <20, so only one comparison gets done 
anyway.

(I do  sometimes use the idiom, in assembly, but when i needs to be offset 
to start at zero anyway.)

> Unsigned arithmetic doesn't behave in a way that most
> people are used to

'Unintuitive'

-- 
Bartc 

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

#26073

"BartC" <bc@freeuk.com> writes:

> "Tim Rentsch" <txr@alumni.caltech.edu> wrote in message
> news:kfnfw8k1dpf.fsf@x-alumni2.alumni.caltech.edu...
>> Seungbeom Kim <musiphil@bawi.org> writes:
>>
>>> On 2012-07-20 14:41, Eric Sosman wrote:
>> [snip]
>>>> And in the cases where naive subtraction doesn't work, you don't
>>>> just get a possibly surprising but predictable outcome: You get
>>>> undefined behavior.
>>>
>>> True. But (2U - 5U) yielding 4294967293U is not very useful, no matter
>>> how predictable it is, [snip]
>>
>> That's an overstatement.  It may not be useful in ways that
>> you would like it to be, or in all the cases you would like
>> it to be, but there still are lots of cases where it is
>> useful.  To give one example, if we want to test if
>> variable 'i' is in the range [20 .. 30), with signed
>> arithmetic that takes two comparisons, but with unsigned
>> arithmetic this can be done with one comparison:
>>
>>    if(  (i-20u) < 10  ) ...
>
> You [snip] now have code that will cause people to scratch their heads
> [snip]

Perhaps so, but the point was to illustrate the property,
not to illustrate code that might take advantage of it.
In this case, for example, people who aren't used to this
idiom could bundle it up inside a macro definition.

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

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web