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

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

Performance of signed vs unsigned types

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

Contents

  Performance of signed vs unsigned types Thomas Scrace <tom@scrace.org> - 2011-04-20 14:21 +0100
    Re: Performance of signed vs unsigned types James Kuyper <jameskuyper@verizon.net> - 2011-04-20 09:49 -0400
      Re: Performance of signed vs unsigned types Thomas Scrace <tom@scrace.org> - 2011-04-20 15:21 +0100
      Re: Performance of signed vs unsigned types Peter Nilsson <airia@acay.com.au> - 2011-04-20 15:34 -0700
        Re: Performance of signed vs unsigned types Thomas Scrace <tom@scrace.org> - 2011-04-21 17:57 +0100
          Re: Performance of signed vs unsigned types Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-04-21 19:26 +0100
      Re: Performance of signed vs unsigned types Michael Press <rubrum@pacbell.net> - 2011-04-20 21:45 -0700
        Re: Performance of signed vs unsigned types James Kuyper <jameskuyper@verizon.net> - 2011-04-21 06:20 -0400
          Re: Performance of signed vs unsigned types Michael Press <rubrum@pacbell.net> - 2011-04-21 13:54 -0700
            Re: Performance of signed vs unsigned types James Kuyper <jameskuyper@verizon.net> - 2011-04-21 18:50 -0400
              Re: Performance of signed vs unsigned types Michael Press <rubrum@pacbell.net> - 2011-04-21 16:16 -0700
                Re: Performance of signed vs unsigned types James Kuyper <jameskuyper@verizon.net> - 2011-04-21 19:27 -0400
                  Re: Performance of signed vs unsigned types Michael Press <rubrum@pacbell.net> - 2011-04-21 17:24 -0700
                    Re: Performance of signed vs unsigned types James Kuyper <jameskuyper@verizon.net> - 2011-04-21 21:00 -0400
                      Re: Performance of signed vs unsigned types Michael Press <rubrum@pacbell.net> - 2011-04-21 21:33 -0700
                        Re: Performance of signed vs unsigned types Thomas Scrace <tom@scrace.org> - 2011-04-22 08:22 +0100
                          Re: Performance of signed vs unsigned types Michael Press <rubrum@pacbell.net> - 2011-04-22 14:25 -0700
                        Re: Performance of signed vs unsigned types James Kuyper <jameskuyper@verizon.net> - 2011-04-22 09:21 -0400
                          Re: Performance of signed vs unsigned types Michael Press <rubrum@pacbell.net> - 2011-04-22 14:22 -0700
                            Re: Performance of signed vs unsigned types James Kuyper <jameskuyper@verizon.net> - 2011-04-22 17:58 -0400
                              Re: Performance of signed vs unsigned types Michael Press <rubrum@pacbell.net> - 2011-04-22 17:33 -0700
                                Re: Performance of signed vs unsigned types James Kuyper <jameskuyper@verizon.net> - 2011-04-23 09:01 -0400
                                  Re: Performance of signed vs unsigned types Michael Press <rubrum@pacbell.net> - 2011-04-23 14:07 -0700
                                    Re: Performance of signed vs unsigned types James Kuyper <jameskuyper@verizon.net> - 2011-04-23 18:14 -0400
                                      Re: Performance of signed vs unsigned types Michael Press <rubrum@pacbell.net> - 2011-04-25 11:42 -0700
                                        Re: Performance of signed vs unsigned types James Kuyper <jameskuyper@verizon.net> - 2011-04-25 22:34 -0400
                                        Re: Performance of signed vs unsigned types gordonb.nw63u@burditt.org (Gordon Burditt) - 2011-04-26 10:59 -0500
                        Re: Performance of signed vs unsigned types "madamemandm@yahoo.com" <madamemandm@yahoo.com> - 2011-04-22 07:55 -0700
                          Re: Performance of signed vs unsigned types Noob <root@127.0.0.1> - 2011-04-22 17:03 +0200
                            Re: Performance of signed vs unsigned types Keith Thompson <kst-u@mib.org> - 2011-04-22 08:42 -0700
                          Re: Performance of signed vs unsigned types Michael Press <rubrum@pacbell.net> - 2011-04-22 14:15 -0700
                            Re: Performance of signed vs unsigned types Keith Thompson <kst-u@mib.org> - 2011-04-22 15:23 -0700
                              Re: Performance of signed vs unsigned types Michael Press <rubrum@pacbell.net> - 2011-04-22 17:37 -0700
                                Re: Performance of signed vs unsigned types Seebs <usenet-nospam@seebs.net> - 2011-04-23 02:46 +0000
                                  Re: Performance of signed vs unsigned types Michael Press <rubrum@pacbell.net> - 2011-04-23 14:04 -0700
                                    Re: Performance of signed vs unsigned types Barry Schwarz <schwarzb@dqel.com> - 2011-04-23 14:28 -0700
                                      Re: Performance of signed vs unsigned types Michael Press <rubrum@pacbell.net> - 2011-04-25 11:43 -0700
                                    Re: Performance of signed vs unsigned types Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-04-23 23:38 +0100
                                      Re: Performance of signed vs unsigned types Michael Press <rubrum@pacbell.net> - 2011-04-25 11:46 -0700
                                        Re: Performance of signed vs unsigned types Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-04-25 22:43 +0100
                                    Re: Performance of signed vs unsigned types Seebs <usenet-nospam@seebs.net> - 2011-04-24 11:34 +0000
                                      Re: Performance of signed vs unsigned types Michael Press <rubrum@pacbell.net> - 2011-04-25 11:47 -0700
                                        Re: Performance of signed vs unsigned types Keith Thompson <kst-u@mib.org> - 2011-04-25 12:32 -0700
                                          Re: Performance of signed vs unsigned types Michael Press <rubrum@pacbell.net> - 2011-04-25 20:25 -0700
                                            Re: Performance of signed vs unsigned types Keith Thompson <kst-u@mib.org> - 2011-04-26 07:45 -0700
                                    Re: Performance of signed vs unsigned types lawrence.jones@siemens.com - 2011-04-24 23:50 -0400
                                      Re: Performance of signed vs unsigned types Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-04-25 02:13 -0700
                                        Re: Performance of signed vs unsigned types Ian Collins <ian-news@hotmail.com> - 2011-04-25 21:36 +1200
                                      Re: Performance of signed vs unsigned types Michael Press <rubrum@pacbell.net> - 2011-04-25 11:48 -0700
                                        Re: Performance of signed vs unsigned types lawrence.jones@siemens.com - 2011-04-25 16:32 -0400
                                          Re: Performance of signed vs unsigned types Keith Thompson <kst-u@mib.org> - 2011-04-25 15:22 -0700
                                            Re: Performance of signed vs unsigned types Michael Press <rubrum@pacbell.net> - 2011-04-25 20:32 -0700
                                              Re: Performance of signed vs unsigned types "io_x" <a@b.c.invalid> - 2011-04-26 09:42 +0200
                                              Re: Performance of signed vs unsigned types Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-04-26 12:04 +0100
                                              Re: Performance of signed vs unsigned types Keith Thompson <kst-u@mib.org> - 2011-04-26 08:15 -0700
                                                Re: Performance of signed vs unsigned types Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-04-26 08:35 -0700
                                                Re: Performance of signed vs unsigned types Keith Thompson <kst-u@mib.org> - 2011-04-26 08:52 -0700
                                                  Re: Performance of signed vs unsigned types Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-04-26 09:15 -0700
                                                    Re: Performance of signed vs unsigned types Keith Thompson <kst-u@mib.org> - 2011-04-26 10:22 -0700
                                                Re: Performance of signed vs unsigned types gordonb.s68qo@burditt.org (Gordon Burditt) - 2011-04-26 19:59 -0500
                                                  Re: Performance of signed vs unsigned types "madamemandm@yahoo.com" <madamemandm@yahoo.com> - 2011-04-27 14:15 -0700
                                                  Re: Performance of signed vs unsigned types "io_x" <a@b.c.invalid> - 2011-04-28 12:15 +0200
                                                  Re: Performance of signed vs unsigned types Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-04-28 03:26 -0700
                                                    Re: Performance of signed vs unsigned types Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-04-28 12:09 +0100
                                                    Re: Performance of signed vs unsigned types James Kuyper <jameskuyper@verizon.net> - 2011-04-28 08:03 -0400
                                                    Re: Performance of signed vs unsigned types Seebs <usenet-nospam@seebs.net> - 2011-04-28 16:44 +0000
                                                    Re: Performance of signed vs unsigned types Gordon Burditt <gordon@hammy.burditt.org> - 2011-04-29 05:42 -0500
                                          Re: Performance of signed vs unsigned types Michael Press <rubrum@pacbell.net> - 2011-04-25 20:27 -0700
                                            Re: Performance of signed vs unsigned types Ian Collins <ian-news@hotmail.com> - 2011-04-26 15:30 +1200
                                              Re: Performance of signed vs unsigned types Michael Press <rubrum@pacbell.net> - 2011-04-26 00:14 -0700
                                                Re: Performance of signed vs unsigned types Ian Collins <ian-news@hotmail.com> - 2011-04-26 20:23 +1200
                                                Re: Performance of signed vs unsigned types Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-04-26 04:17 -0700
                      Re: Performance of signed vs unsigned types Ike Naar <ike@sverige.freeshell.org> - 2011-04-22 06:46 +0000
                        Re: Performance of signed vs unsigned types James Kuyper <jameskuyper@verizon.net> - 2011-04-22 09:37 -0400
                        Re: Performance of signed vs unsigned types Michael Press <rubrum@pacbell.net> - 2011-04-25 11:49 -0700
                Re: Performance of signed vs unsigned types Keith Thompson <kst-u@mib.org> - 2011-04-22 09:09 -0700
                  Re: Performance of signed vs unsigned types "madamemandm@yahoo.com" <madamemandm@yahoo.com> - 2011-04-22 09:46 -0700
                  Re: Performance of signed vs unsigned types Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-04-22 20:21 +0100
    Re: Performance of signed vs unsigned types "Scott Fluhrer" <sfluhrer@ix.netcom.com> - 2011-04-20 10:06 -0400
      Re: Performance of signed vs unsigned types Thomas Scrace <tom@scrace.org> - 2011-04-20 15:28 +0100
        Re: Performance of signed vs unsigned types Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-04-20 16:11 +0100
        Re: Performance of signed vs unsigned types Malcolm McLean <malcolm.mclean5@btinternet.com> - 2011-04-20 08:14 -0700
          Re: Performance of signed vs unsigned types Thomas Scrace <tom@scrace.org> - 2011-04-20 16:24 +0100
            Re: Performance of signed vs unsigned types Thomas Scrace <tom@scrace.org> - 2011-04-20 17:09 +0100
              Re: Performance of signed vs unsigned types Thomas Scrace <tom@scrace.org> - 2011-04-20 17:19 +0100
                Re: Performance of signed vs unsigned types Keith Thompson <kst-u@mib.org> - 2011-04-20 12:09 -0700
                  Re: Performance of signed vs unsigned types Thomas Scrace <tom@scrace.org> - 2011-04-20 21:39 +0100
                    Re: Performance of signed vs unsigned types Keith Thompson <kst-u@mib.org> - 2011-04-20 15:01 -0700
                      Re: Performance of signed vs unsigned types Thomas Scrace <tom@scrace.org> - 2011-04-21 11:16 +0100
        Re: Performance of signed vs unsigned types "Scott Fluhrer" <sfluhrer@ix.netcom.com> - 2011-04-20 13:06 -0400
          Re: Performance of signed vs unsigned types Thomas Scrace <tom@scrace.org> - 2011-04-20 18:16 +0100
    Re: Performance of signed vs unsigned types gordonb.bfd7y@burditt.org (Gordon Burditt) - 2011-04-21 11:22 -0500
      Re: Performance of signed vs unsigned types Thomas Scrace <tom@scrace.org> - 2011-04-21 19:27 +0100
        Re: Performance of signed vs unsigned types Keith Thompson <kst-u@mib.org> - 2011-04-21 12:09 -0700

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

#2837

On 2011-04-23, Michael Press <rubrum@pacbell.net> wrote:
> In article <slrnir4fom.1keu.usenet-nospam@guild.seebs.net>,
>  Seebs <usenet-nospam@seebs.net> wrote:
>> On 2011-04-23, Michael Press <rubrum@pacbell.net> wrote:
>> > Exactly what do an implementations do when they 
>> > do not return an int to on x + y?

>> Well, one common form would be an arithmetic trap, same kind of thing
>> as you get when dividing by zero.

> Who benefits from having such an implementation available?

People who make chips with that behavior?

There is a reason that so many processors trap on invalid operands:  It
turns out to be a desireable behavior sometimes.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

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

#2879

In article <slrnir82mf.mne.usenet-nospam@guild.seebs.net>,
 Seebs <usenet-nospam@seebs.net> wrote:

> On 2011-04-23, Michael Press <rubrum@pacbell.net> wrote:
> > In article <slrnir4fom.1keu.usenet-nospam@guild.seebs.net>,
> >  Seebs <usenet-nospam@seebs.net> wrote:
> >> On 2011-04-23, Michael Press <rubrum@pacbell.net> wrote:
> >> > Exactly what do an implementations do when they 
> >> > do not return an int to on x + y?
> 
> >> Well, one common form would be an arithmetic trap, same kind of thing
> >> as you get when dividing by zero.
> 
> > Who benefits from having such an implementation available?
> 
> People who make chips with that behavior?
> 
> There is a reason that so many processors trap on invalid operands:  It
> turns out to be a desireable behavior sometimes.

And sometimes not. Offer a compiler flag that
makes arithmetic on integer types closed.

-- 
Michael Press

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

#2884

Michael Press <rubrum@pacbell.net> writes:
> In article <slrnir82mf.mne.usenet-nospam@guild.seebs.net>,
>  Seebs <usenet-nospam@seebs.net> wrote:
>> On 2011-04-23, Michael Press <rubrum@pacbell.net> wrote:
>> > In article <slrnir4fom.1keu.usenet-nospam@guild.seebs.net>,
>> >  Seebs <usenet-nospam@seebs.net> wrote:
>> >> On 2011-04-23, Michael Press <rubrum@pacbell.net> wrote:
>> >> > Exactly what do an implementations do when they 
>> >> > do not return an int to on x + y?
>> 
>> >> Well, one common form would be an arithmetic trap, same kind of thing
>> >> as you get when dividing by zero.
>> 
>> > Who benefits from having such an implementation available?
>> 
>> People who make chips with that behavior?
>> 
>> There is a reason that so many processors trap on invalid operands:  It
>> turns out to be a desireable behavior sometimes.
>
> And sometimes not. Offer a compiler flag that
> makes arithmetic on integer types closed.

It would be perfectly reasonable for a compiler to offer such a flag.

The point is that a conforming compiler needn't do so, and even
if it does, it can still be a conforming compiler when that flag
is disabled.

A program that depends on integer types being closed under various
arithmetic operations *can* work correctly, if it's running under an
implementation that satisfies that dependency, whether by default or
in whatever configuration you choose to use.  But it can't be 100%
portable, because not all implementations are required implement
closed arithmetic.

If you want most compilers to implement closed arithmetic, then
you already have your wish.

If you want the standard to require all compilers to do so, then
I don't think that's going to happen; trapping on overflow is too
useful (at least in some contexts) for the standard to forbid it.
(And the standard, at least currently, has nothing to say about
compiler flags; as far as the standard is concerned, for example,
"gcc -unsigned-char" and "gcc -fsigned-char" are two distinct
implementations.)

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

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

#2898

In article <lnvcy2yvn2.fsf@nuthaus.mib.org>,
 Keith Thompson <kst-u@mib.org> wrote:

> Michael Press <rubrum@pacbell.net> writes:
> > In article <slrnir82mf.mne.usenet-nospam@guild.seebs.net>,
> >  Seebs <usenet-nospam@seebs.net> wrote:
> >> On 2011-04-23, Michael Press <rubrum@pacbell.net> wrote:
> >> > In article <slrnir4fom.1keu.usenet-nospam@guild.seebs.net>,
> >> >  Seebs <usenet-nospam@seebs.net> wrote:
> >> >> On 2011-04-23, Michael Press <rubrum@pacbell.net> wrote:
> >> >> > Exactly what do an implementations do when they 
> >> >> > do not return an int to on x + y?
> >> 
> >> >> Well, one common form would be an arithmetic trap, same kind of thing
> >> >> as you get when dividing by zero.
> >> 
> >> > Who benefits from having such an implementation available?
> >> 
> >> People who make chips with that behavior?
> >> 
> >> There is a reason that so many processors trap on invalid operands:  It
> >> turns out to be a desireable behavior sometimes.
> >
> > And sometimes not. Offer a compiler flag that
> > makes arithmetic on integer types closed.
> 
> It would be perfectly reasonable for a compiler to offer such a flag.
> 
> The point is that a conforming compiler needn't do so, and even
> if it does, it can still be a conforming compiler when that flag
> is disabled.
> 
> A program that depends on integer types being closed under various
> arithmetic operations *can* work correctly, if it's running under an
> implementation that satisfies that dependency, whether by default or
> in whatever configuration you choose to use.  But it can't be 100%
> portable, because not all implementations are required implement
> closed arithmetic.
> 
> If you want most compilers to implement closed arithmetic, then
> you already have your wish.
> 
> If you want the standard to require all compilers to do so, then
> I don't think that's going to happen; trapping on overflow is too
> useful (at least in some contexts) for the standard to forbid it.
> (And the standard, at least currently, has nothing to say about
> compiler flags; as far as the standard is concerned, for example,
> "gcc -unsigned-char" and "gcc -fsigned-char" are two distinct
> implementations.)

The standard could demand that an option for closed arithmetic
be available, or if overflow must be trapped, the programmer can
provide his own trap code, as with signal handlers.

-- 
Michael Press

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

#2923

Michael Press <rubrum@pacbell.net> writes:
> In article <lnvcy2yvn2.fsf@nuthaus.mib.org>,
>  Keith Thompson <kst-u@mib.org> wrote:
[...]
>> If you want most compilers to implement closed arithmetic, then
>> you already have your wish.
>> 
>> If you want the standard to require all compilers to do so, then
>> I don't think that's going to happen; trapping on overflow is too
>> useful (at least in some contexts) for the standard to forbid it.
>> (And the standard, at least currently, has nothing to say about
>> compiler flags; as far as the standard is concerned, for example,
>> "gcc -unsigned-char" and "gcc -fsigned-char" are two distinct
>> implementations.)
>
> The standard could demand that an option for closed arithmetic
> be available, or if overflow must be trapped, the programmer can
> provide his own trap code, as with signal handlers.

Yes, it could.  Feel free to advocate it, but IMHO it's not going to
happen.

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

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

#2851

Michael Press <rubrum@pacbell.net> wrote:
> In article <slrnir4fom.1keu.usenet-nospam@guild.seebs.net>,
>  Seebs <usenet-nospam@seebs.net> wrote:
> 
> > On 2011-04-23, Michael Press <rubrum@pacbell.net> wrote:
> > > Exactly what do an implementations do when they 
> > > do not return an int to on x + y?
> > 
> > Well, one common form would be an arithmetic trap, same kind of thing
> > as you get when dividing by zero.
> 
> Who benefits from having such an implementation available?

People writing safety-critical code usually prefer a trap (which can be
caught and handled) to quietly getting the wrong answer (which is harder
to detect and could have serious consequences).
-- 
Larry Jones

Fortunately, that was our plan from the start. -- Calvin

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

#2860

On Apr 25, 6:50 am, lawrence.jo...@siemens.com wrote:
>
> People writing safety-critical code usually prefer a trap (which can be
> caught and handled) to quietly getting the wrong answer (which is harder
> to detect and could have serious consequences).
>
Yes, video games are about the only application area where wrong
results are preferable to no results.

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

#2861

On 04/25/11 09:13 PM, Malcolm McLean wrote:
> On Apr 25, 6:50 am, lawrence.jo...@siemens.com wrote:
>>
>> People writing safety-critical code usually prefer a trap (which can be
>> caught and handled) to quietly getting the wrong answer (which is harder
>> to detect and could have serious consequences).
>>
> Yes, video games are about the only application area where wrong
> results are preferable to no results.

Video games and investment banking :)

-- 
Ian Collins

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

#2880

In article <cl7f88-h4a.ln1@jones.homeip.net>,
 lawrence.jones@siemens.com wrote:

> Michael Press <rubrum@pacbell.net> wrote:
> > In article <slrnir4fom.1keu.usenet-nospam@guild.seebs.net>,
> >  Seebs <usenet-nospam@seebs.net> wrote:
> > 
> > > On 2011-04-23, Michael Press <rubrum@pacbell.net> wrote:
> > > > Exactly what do an implementations do when they 
> > > > do not return an int to on x + y?
> > > 
> > > Well, one common form would be an arithmetic trap, same kind of thing
> > > as you get when dividing by zero.
> > 
> > Who benefits from having such an implementation available?
> 
> People writing safety-critical code usually prefer a trap (which can be
> caught and handled) to quietly getting the wrong answer (which is harder
> to detect and could have serious consequences).

People writing safety-critical code do not 
range check arguments, and examine return values?

-- 
Michael Press

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

#2888

Michael Press <rubrum@pacbell.net> wrote:
> 
> People writing safety-critical code do not 
> range check arguments, and examine return values?

Of course they do, but that isn't sufficient to prevent overflow.
-- 
Larry Jones

Mr. Subtlety drives home another point. -- Calvin

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

#2890

lawrence.jones@siemens.com writes:
> Michael Press <rubrum@pacbell.net> wrote:
>> People writing safety-critical code do not 
>> range check arguments, and examine return values?
>
> Of course they do, but that isn't sufficient to prevent overflow.

Well, carefully range-checking each operand of each arithmetic operator
(assuming that "arguments" includes operands) should be sufficient to
prevent overflow.  But it's hardly practical if the compiler doesn't
generate the checking code for you.

    int x = rand();
    int y = rand();
    /* checking here */
    int z = x * y;

Checking whether x * y will overflow without actually performing
the multiplication is certainly possible, but (a) it's tedious, and
(b) the check is likely to be more expensive than the multiplication.

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

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

#2901

In article <lnr58qyns1.fsf@nuthaus.mib.org>,
 Keith Thompson <kst-u@mib.org> wrote:

> lawrence.jones@siemens.com writes:
> > Michael Press <rubrum@pacbell.net> wrote:
> >> People writing safety-critical code do not 
> >> range check arguments, and examine return values?
> >
> > Of course they do, but that isn't sufficient to prevent overflow.
> 
> Well, carefully range-checking each operand of each arithmetic operator
> (assuming that "arguments" includes operands) should be sufficient to
> prevent overflow.  But it's hardly practical if the compiler doesn't
> generate the checking code for you.
> 
>     int x = rand();
>     int y = rand();
>     /* checking here */
>     int z = x * y;

No, no, no, no, no.
Reduce x and y to < sqrt(maximum rand()) so that overflow does not occur.
Range check input arguments so the computation does not overflow.

> Checking whether x * y will overflow without actually performing
> the multiplication is certainly possible, but (a) it's tedious, and
> (b) the check is likely to be more expensive than the multiplication.

-- 
Michael Press

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

#2906

"Michael Press" <rubrum@pacbell.net> ha scritto nel messaggio
news:rubrum-F140C5.20322925042011@news.albasani.net...
> In article <lnr58qyns1.fsf@nuthaus.mib.org>,
> Keith Thompson <kst-u@mib.org> wrote:
>
>> lawrence.jones@siemens.com writes:
>> > Michael Press <rubrum@pacbell.net> wrote:
>> >> People writing safety-critical code do not
>> >> range check arguments, and examine return values?
>> >
>> > Of course they do, but that isn't sufficient to prevent overflow.
>>
>> Well, carefully range-checking each operand of each arithmetic operator
>> (assuming that "arguments" includes operands) should be sufficient to
>> prevent overflow.  But it's hardly practical if the compiler doesn't
>> generate the checking code for you.
>>
>>     int x = rand();
>>     int y = rand();
>>     /* checking here */
>>     int z = x * y;
>
> No, no, no, no, no.
> Reduce x and y to < sqrt(maximum rand()) so that overflow does not occur.
> Range check input arguments so the computation does not overflow.

for me above can overflow well without to signal the error
where is the error?

the problem is the overflow of  the "x * sizeof(int)" in

unsigned   x, *y;
x=....;
y=malloc( x * sizeof(int));

or the overflow in "z=x*y" if the user want the correct result

unsigned  x, y, z, r;
r=input(&x, "Insert x: ", stdin); if(r!=0) {goto error;}
r=input(&y, "Insert y: ", stdin); if(r!=0) {goto error;}
z=x*y;

>> Checking whether x * y will overflow without actually performing
>> the multiplication is certainly possible, but (a) it's tedious, and
>> (b) the check is likely to be more expensive than the multiplication.

(c) can be not what the programmer want

> -- 
> Michael Press

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

#2916

Michael Press <rubrum@pacbell.net> writes:

> In article <lnr58qyns1.fsf@nuthaus.mib.org>,
>  Keith Thompson <kst-u@mib.org> wrote:
>
>> lawrence.jones@siemens.com writes:
>> > Michael Press <rubrum@pacbell.net> wrote:
>> >> People writing safety-critical code do not 
>> >> range check arguments, and examine return values?
>> >
>> > Of course they do, but that isn't sufficient to prevent overflow.
>> 
>> Well, carefully range-checking each operand of each arithmetic operator
>> (assuming that "arguments" includes operands) should be sufficient to
>> prevent overflow.  But it's hardly practical if the compiler doesn't
>> generate the checking code for you.
>> 
>>     int x = rand();
>>     int y = rand();
>>     /* checking here */
>>     int z = x * y;
>
> No, no, no, no, no.
> Reduce x and y to < sqrt(maximum rand()) so that overflow does not occur.
> Range check input arguments so the computation does not overflow.

But that changes the computation.  If a multiplication might overflow,
you can't simply decide to alter the operands so that is does not.

>> Checking whether x * y will overflow without actually performing
>> the multiplication is certainly possible, but (a) it's tedious, and
>> (b) the check is likely to be more expensive than the multiplication.

Since I am posting, I'll make a remark that I decided was not worth a
post of its own...  This example is not ideal because x, y and the
correct value of z are all positive, so the programmer could use
unsigned arithmetic making the test for "overflow" simpler, in part
because it can then be done after the multiplication.  Maybe input or a
conversion from argv[x] is a better way to suggest arbitrary int values.

-- 
Ben.

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

#2924

Michael Press <rubrum@pacbell.net> writes:
> In article <lnr58qyns1.fsf@nuthaus.mib.org>,
>  Keith Thompson <kst-u@mib.org> wrote:
>> lawrence.jones@siemens.com writes:
>> > Michael Press <rubrum@pacbell.net> wrote:
>> >> People writing safety-critical code do not 
>> >> range check arguments, and examine return values?
>> >
>> > Of course they do, but that isn't sufficient to prevent overflow.
>> 
>> Well, carefully range-checking each operand of each arithmetic operator
>> (assuming that "arguments" includes operands) should be sufficient to
>> prevent overflow.  But it's hardly practical if the compiler doesn't
>> generate the checking code for you.
>> 
>>     int x = rand();
>>     int y = rand();
>>     /* checking here */
>>     int z = x * y;
>
> No, no, no, no, no.

Yes, yes, yes, yes, yes.

> Reduce x and y to < sqrt(maximum rand()) so that overflow does not occur.
> Range check input arguments so the computation does not overflow.

In other words, if the result you want to compute will cause an
overflow, compute a different result?  Sorry, you don't get to do that.

The relevant bound is sqrt(INT_MAX), not sqrt(RAND_MAX).  But even then,
restricting the ranges of both operands that way rejects many cases that
would not overflow.  For example, if x==1, any value of y is ok.  If x
== 7, and INT_MAX == 2**31-1, any value of y up to 306783378 is ok.  And
so forth.  And as Ben points out, my use of rand() obscures the case
where x and/or y can be negative.

>> Checking whether x * y will overflow without actually performing
>> the multiplication is certainly possible, but (a) it's tedious, and
>> (b) the check is likely to be more expensive than the multiplication.

Suppose you're asked to write a program with the following
specification:

The program takes exactly two command-line arguments, both of which
are string representations of int values.  If it doesn't receive
exactly two arguments, it terminates with an error message and
returns a failure indication to the environment; otherwise it may
assume that both arguments are valid int values.  If the product of
the two arguments is in the range INT_MIN..INT_MAX, the product is
printed to stdout followed by a new-line.  Otherwise, the program
aborts with an error message and returns a failure indication to
the environment.

You don't get to change the requirements to avoid overflow.  You don't
get to print an error message for any arguments that would not overflow.
You must print an error message for any arguments that would overflow.

Here's a partial solution:

#include <stdio.h>
#include <stdlib.h>

int multiplication_would_overflow(int x, int y)
{
    /*
     * TODO: Implement this.
     */
    return 0;
}

int main(int argc, char **argv)
{
    if (argc != 3) {
        fprintf(stderr, "Usage: %s num num\n", argv[0]);
        exit(EXIT_FAILURE);
    }
    /*
     * Note: atoi() does not perform error checking.
     */
    const int x = atoi(argv[1]);
    const int y = atoi(argv[2]);

    if (multiplication_would_overflow(x, y)) {
        fprintf(stderr, "%d * %d would overflow\n", x, y);
        exit(EXIT_FAILURE);
    }
    else {
        printf("%d\n", x * y);
    }
    exit(EXIT_SUCCESS);
}

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

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

#2925

On Apr 26, 6:15 pm, Keith Thompson <ks...@mib.org> wrote:
>
> #include <stdio.h>
> #include <stdlib.h>
>
> int multiplication_would_overflow(int x, int y)
> {
>     /*
>      * TODO: Implement this.
>      */
{ asm;
     mul x, y
     returnregister = highvalue
}

>     return ;
>
> }
>
It's easy in most assemblers, because usually there's an instruction
which gives a double width result. It's hard in C, but that's just a
quirk of the language.
However most people don't check for overflow, otherwise
multiplication_would_overflow() would be in the standard library.

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

#2927

Keith Thompson <kst-u@mib.org> writes:
[...]
> int multiplication_would_overflow(int x, int y)
> {
>     /*
>      * TODO: Implement this.
>      */
>     return 0;
> }
[...]

I forgot to mention that, of course, it's entirely possible
to implement the multiplication_would_overflow() function in
portable C.  I think I've seen versions posted here (I'm just too
lazy to track them down or recreate them).  The point is that it's
very difficult to get it right (for example, INT_MIN * -1 overflows
on 2's-complement systems but not on others), and computationally
expensive, far more expensive than the multiplication itself.

On most CPUs, there's a way (which varies from one CPU to another)
to compute x * y safely and determine after the fact whether there
was an overflow, but C doesn't expose that.  There typically isn't
even a non-portable way to do overflow checking in C, unless you
resort to inline assembly.

Note that I'm talking about the way C is currently defined, not
arguing that it *should* be defined that way.  Personally, I'd like
to see something similar to C#'s "checked" keyword, which requires
overflow checking for an expression; the problem is that it depends
on C#'s exception mechanism, and adding exceptions to C seems to
be more than the committee is willing to do.

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

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

#2929

On Apr 26, 6:52 pm, Keith Thompson <ks...@mib.org> wrote:
>
> Note that I'm talking about the way C is currently defined, not
> arguing that it *should* be defined that way.  Personally, I'd like
> to see something similar to C#'s "checked" keyword, which requires
> overflow checking for an expression; the problem is that it depends
> on C#'s exception mechanism, and adding exceptions to C seems to
> be more than the committee is willing to do.
>
What you could do is add limits

int x = 100 <between 0 and INT_MAX>;

exceeding the limits is undefined behaviour, so cheapo compilers can
add the functionality trivially. A decent compiler, however, will
crash out with an error message.

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

#2930

Malcolm McLean <malcolm.mclean5@btinternet.com> writes:
> On Apr 26, 6:52 pm, Keith Thompson <ks...@mib.org> wrote:
>> Note that I'm talking about the way C is currently defined, not
>> arguing that it *should* be defined that way.  Personally, I'd like
>> to see something similar to C#'s "checked" keyword, which requires
>> overflow checking for an expression; the problem is that it depends
>> on C#'s exception mechanism, and adding exceptions to C seems to
>> be more than the committee is willing to do.
>>
> What you could do is add limits
>
> int x = 100 <between 0 and INT_MAX>;
>
> exceeding the limits is undefined behaviour, so cheapo compilers can
> add the functionality trivially. A decent compiler, however, will
> crash out with an error message.

That's what we have now, but with the added capability of specifying
a narrower range than INT_MIN .. INT_MAX.  And it needs a much
more precise specification.  Does the "between" clause apply to an
object?  An expression?  A type?

What I'm talking about is a way to guarantee that a given expression
will *either* yield a mathematically correct result *or* indicate, in
some way that I can handle in my program, that it's unable to do so.

Second-best would be a guarantee that in this code fragment:

    int x = INT_MAX + 1;
    puts("OOPS!");

the string "OOPS!" will not be printed.

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

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

#2946

I once wrote a whole series of overflow-resistant routines of the
form XXtypeXX_XXopXX_will_overflow(a, b, &c), where XXtypeXX is
some C signed or unsigned integer type, XXopXX is some binary math
operation (add, subtract, multiply, divide, mod).  This was for a
probability calculation where overflowing the number of combinations
is really easy.

If a op b would not overflow, the effect would be that of 
	*c = a op b  
and the function returns 0.  If a op b would overflow (or have other
problems like division by zero), *c is left unchanged, and the
function returns 1.  (*c could be set to some "default" value ahead
of time to substitute in case of math error).  You may also pass
in the third argument (pointer) as NULL if you don't want the result.

The functions for unsigned types catch unsigned wraparound, even
though C doesn't call that "overflow" or consider it an error.

Further, it's supposed to do this without causing any C undefined
behavior.  So instead of writing:
	c = a + b;
you can write:
	if (sl_mul_will_overflow(a, b, &c)) { ... oops, trouble ... }

The code I'm including here is for signed multiplication only.
Someone might find it useful.  Ok, try to break it.  I'm not sure
I have properly accounted for all the possible wierdities on a
non-2's-complement machine, and I don't have one to test on.

The main source file is pretty simple, for making the code type-generic:
______________________________________________________
#include <limits.h>

#define VALUE_T			signed long
#define VALUE_MIN		LONG_MIN
#define VALUE_MAX		LONG_MAX

#define mul_will_overflow	sl_mul_will_overflow

#include "smul.inc"
______________________________________________________

and it included the appropriate code, here for signed multiply:

______________________________________________________
#include "libovflo.h"	/* contains function prototypes for the library */

int
mul_will_overflow(VALUE_T a, VALUE_T b, VALUE_T * c)
{
    if (a == 0 || a == 1 || b == 0 || b == 1)
    {
	/* cannot overflow */
    }
    else
    {
	if (VALUE_MAX - 1 < -1 - VALUE_MIN)
	{
	    /* -VALUE_MIN overflows */
	    if (a == VALUE_MIN || b == VALUE_MIN)
	    {
		/* -1 * VALUE_MIN overflows */
		/* 0 * VALUE_MIN and 1 * VALUE_MIN handled above */
		/* anything else overflows */
		return 1;
	    }
	}
	if (a > 0)
	{
	    if (b > 0)
	    {
		/* a, b positive */
		if (VALUE_MAX / b < a)
		{
		    return 1;
		}
	    }
	    else
	    {
		/* a positive, b negative */
		if ((((-b) - VALUE_MIN) / (-b)) - 1 < a)
		{
		    return 1;
		}
	    }
	}
	else
	{
	    if (b > 0)
	    {
		/* a negative, b positive */
		if (((b - VALUE_MIN) / b) - 1 < (-a))
		{
		    return 1;
		}
	    }
	    else
	    {
		/* a, b negative */
		if (VALUE_MAX / (-b) < (-a))
		{
		    return 1;
		}
	    }
	}
    }
    if (c)
    {
	*c = a * b;
    }

    return 0;
}
______________________________________________________

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

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

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

csiph-web