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

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

Is this code considered to transgress the signed overflow purism?

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

Contents

  Is this code considered to transgress the signed overflow purism? joel.rees@gmail.com - 2017-04-27 03:13 -0700
    Re: Is this code considered to transgress the signed overflow purism? joel.rees@gmail.com - 2017-04-27 03:41 -0700
    Re: Is this code considered to transgress the signed overflow purism? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-27 11:59 +0100
      Re: Is this code considered to transgress the signed overflow purism? joel.rees@gmail.com - 2017-04-27 14:35 -0700
        Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-04-27 15:13 -0700
          Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-04-28 00:58 +0200
            Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-04-27 16:44 -0700
              Re: Is this code considered to transgress the signed overflow purism? joel.rees@gmail.com - 2017-04-27 20:04 -0700
              Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-04-28 08:53 +0200
                Re: Is this code considered to transgress the signed overflow purism? supercat@casperkitty.com - 2017-04-28 08:23 -0700
                  Re: Is this code considered to transgress the signed overflow purism? Manfred <noname@invalid.add> - 2017-04-28 18:05 +0200
                  Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-04-28 09:22 -0700
                    Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-04-28 12:24 -0700
                      Re: Is this code considered to transgress the signed overflow purism? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-29 00:03 +0100
                        Re: Is this code considered to transgress the signed overflow purism? supercat@casperkitty.com - 2017-04-28 16:37 -0700
                          Re: Is this code considered to transgress the signed overflow purism? David Kleinecke <dkleinecke@gmail.com> - 2017-04-28 17:09 -0700
                            Re: Is this code considered to transgress the signed overflow purism? supercat@casperkitty.com - 2017-04-28 17:34 -0700
                            Re: Is this code considered to transgress the signed overflow purism? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-29 01:43 +0100
                              Re: Is this code considered to transgress the signed overflow purism? David Kleinecke <dkleinecke@gmail.com> - 2017-04-28 21:21 -0700
                                Re: Is this code considered to transgress the signed overflow purism? joel.rees@gmail.com - 2017-04-29 02:04 -0700
                                  Re: Is this code considered to transgress the signed overflow purism? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-29 11:46 +0100
                                  Re: Is this code considered to transgress the signed overflow purism? Robert Wessel <robertwessel2@yahoo.com> - 2017-04-30 12:05 -0500
                                Re: Is this code considered to transgress the signed overflow purism? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-29 11:33 +0100
                                  Re: Is this code considered to transgress the signed overflow purism? David Kleinecke <dkleinecke@gmail.com> - 2017-04-29 08:26 -0700
                                    Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-04-29 17:58 +0200
                                      Re: Is this code considered to transgress the signed overflow purism? David Kleinecke <dkleinecke@gmail.com> - 2017-04-29 09:13 -0700
                                        Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-04-30 12:55 +0200
                                          Re: Is this code considered to transgress the signed overflow purism? David Kleinecke <dkleinecke@gmail.com> - 2017-04-30 09:17 -0700
                                            Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-04-30 20:35 +0200
                                              Re: Is this code considered to transgress the signed overflow purism? David Kleinecke <dkleinecke@gmail.com> - 2017-04-30 15:39 -0700
                                                Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-05-01 16:21 +0200
                                          Re: Is this code considered to transgress the signed overflow purism? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-02 06:35 -0700
                                            Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-05-02 16:29 +0200
                                    Re: Is this code considered to transgress the signed overflow purism? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-29 20:58 +0100
                  Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-04-28 18:43 +0200
              Re: Is this code considered to transgress the signed overflow purism? bartc <bc@freeuk.com> - 2017-04-28 14:09 +0100
                Re: Is this code considered to transgress the signed overflow purism? scott@slp53.sl.home (Scott Lurndal) - 2017-04-28 14:23 +0000
                  Re: Is this code considered to transgress the signed overflow purism? bartc <bc@freeuk.com> - 2017-04-28 16:17 +0100
                    Re: Is this code considered to transgress the signed overflow purism? scott@slp53.sl.home (Scott Lurndal) - 2017-04-28 15:55 +0000
                    Re: Is this code considered to transgress the signed overflow purism? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-04-28 19:11 -0700
                      Re: Is this code considered to transgress the signed overflow purism? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-29 11:23 +0100
                      Re: Is this code considered to transgress the signed overflow purism? bartc <bc@freeuk.com> - 2017-04-29 11:31 +0100
                        Re: Is this code considered to transgress the signed overflow purism? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-29 12:01 +0100
                          Re: Is this code considered to transgress the signed overflow purism? bartc <bc@freeuk.com> - 2017-04-29 12:47 +0100
                            Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-04-29 15:20 +0200
                              Re: Is this code considered to transgress the signed overflow purism? bartc <bc@freeuk.com> - 2017-04-29 15:22 +0100
                                Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-04-29 16:52 +0200
                            Re: Is this code considered to transgress the signed overflow purism? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-29 15:18 +0100
                          Re: Is this code considered to transgress the signed overflow purism? Jean-Marc Bourguet <jm@bourguet.org> - 2017-04-29 14:25 +0200
                      Re: Is this code considered to transgress the signed overflow purism? Jerry Stuckle <jstucklex@attglobal.net> - 2017-04-29 08:05 -0400
                        Re: Is this code considered to transgress the signed overflow purism? Gareth Owen <gwowen@gmail.com> - 2017-04-29 13:34 +0100
                        Re: Is this code considered to transgress the signed overflow purism? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-04-29 05:55 -0700
                          Re: Is this code considered to transgress the signed overflow purism? GOTHIER Nathan <nathan.gothier@gmail.com> - 2017-04-29 15:11 +0200
                          Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-04-29 15:24 +0200
                          Re: Is this code considered to transgress the signed overflow purism? Gareth Owen <gwowen@gmail.com> - 2017-04-29 14:57 +0100
                          Re: Is this code considered to transgress the signed overflow purism? asetofsymbols@gmail.com - 2017-05-03 12:17 -0700
                            Re: Is this code considered to transgress the signed overflow purism? supercat@casperkitty.com - 2017-05-03 16:36 -0700
                        Re: Is this code considered to transgress the signed overflow purism? asetofsymbols@gmail.com - 2017-05-03 11:26 -0700
                          Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-05-03 21:40 +0200
                            Re: Is this code considered to transgress the signed overflow purism? asetofsymbols@gmail.com - 2017-05-03 23:46 -0700
                Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-04-28 08:55 -0700
          Re: Is this code considered to transgress the signed overflow purism? joel.rees@gmail.com - 2017-04-27 20:20 -0700
            Re: Is this code considered to transgress the signed overflow purism? joel.rees@gmail.com - 2017-04-27 20:26 -0700
            Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-04-28 10:19 +0200
              Re: Is this code considered to transgress the signed overflow purism? James Kuyper <jameskuyper@verizon.net> - 2017-04-28 09:57 -0400
                Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-04-28 17:06 +0200
              Re: Is this code considered to transgress the signed overflow purism? supercat@casperkitty.com - 2017-04-28 08:38 -0700
                Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-04-28 18:51 +0200
              Re: Is this code considered to transgress the signed overflow purism? supercat@casperkitty.com - 2017-04-29 12:43 -0700
                Re: Is this code considered to transgress the signed overflow purism? Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-30 14:02 -0700
                  Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-04-30 14:25 -0700
                    Re: Is this code considered to transgress the signed overflow purism? Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-30 15:01 -0700
            Re: Is this code considered to transgress the signed overflow purism? James Kuyper <jameskuyper@verizon.net> - 2017-04-28 09:48 -0400
            Re: Is this code considered to transgress the signed overflow purism? supercat@casperkitty.com - 2017-04-28 08:07 -0700
              Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-04-28 18:56 +0200
                Re: Is this code considered to transgress the signed overflow purism? supercat@casperkitty.com - 2017-04-28 11:30 -0700
            Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-04-28 08:35 -0700
        Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-04-28 00:54 +0200
          Re: Is this code considered to transgress the signed overflow purism? joel.rees@gmail.com - 2017-04-27 21:05 -0700
            Re: Is this code considered to transgress the signed overflow purism? David Brown <david.brown@hesbynett.no> - 2017-04-28 10:58 +0200
              Re: Is this code considered to transgress the signed overflow purism? bartc <bc@freeuk.com> - 2017-04-28 10:50 +0100
            Re: Is this code considered to transgress the signed overflow purism? James Kuyper <jameskuyper@verizon.net> - 2017-04-28 10:01 -0400
              Re: Is this code considered to transgress the signed overflow purism? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-02 05:06 -0700
        Re: Is this code considered to transgress the signed overflow purism? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-04-28 23:57 +0100
        Re: Is this code considered to transgress the signed overflow purism? Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-30 12:28 -0700
          Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-04-30 12:41 -0700
            Re: Is this code considered to transgress the signed overflow purism? bartc <bc@freeuk.com> - 2017-04-30 21:46 +0100
              Re: Is this code considered to transgress the signed overflow purism? Thiago Adams <thiago.adams@gmail.com> - 2017-05-01 05:41 -0700
                Re: Is this code considered to transgress the signed overflow purism? bartc <bc@freeuk.com> - 2017-05-01 13:57 +0100
              Re: Is this code considered to transgress the signed overflow purism? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-02 05:30 -0700
                Re: Is this code considered to transgress the signed overflow purism? bartc <bc@freeuk.com> - 2017-05-02 16:13 +0100
                  Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-05-02 09:12 -0700
                    Re: Is this code considered to transgress the signed overflow purism? bartc <bc@freeuk.com> - 2017-05-02 18:15 +0100
                      Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-05-02 11:26 -0700
                        Re: Is this code considered to transgress the signed overflow purism? bartc <bc@freeuk.com> - 2017-05-02 21:39 +0100
                          Re: Is this code considered to transgress the signed overflow purism? supercat@casperkitty.com - 2017-05-02 13:53 -0700
                          Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-05-02 14:10 -0700
                            Re: Is this code considered to transgress the signed overflow purism? bartc <bc@freeuk.com> - 2017-05-02 22:36 +0100
                              Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-05-02 15:27 -0700
                              Re: Is this code considered to transgress the signed overflow purism? Robert Wessel <robertwessel2@yahoo.com> - 2017-05-03 00:45 -0500
                                Re: Is this code considered to transgress the signed overflow purism? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-05-03 11:57 +0100
                                  Re: Is this code considered to transgress the signed overflow purism? Robert Wessel <robertwessel2@yahoo.com> - 2017-05-03 13:34 -0500
                                    Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-05-03 12:05 -0700
                                      Re: Is this code considered to transgress the signed overflow purism? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-05 02:58 -0700
                              Re: Is this code considered to transgress the signed overflow purism? Thiago Adams <thiago.adams@gmail.com> - 2017-05-03 05:26 -0700
                                Re: Is this code considered to transgress the signed overflow purism? Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2017-05-03 05:54 -0700
                                  Re: Is this code considered to transgress the signed overflow purism? Thiago Adams <thiago.adams@gmail.com> - 2017-05-03 06:49 -0700
                                    Re: Is this code considered to transgress the signed overflow purism? Thiago Adams <thiago.adams@gmail.com> - 2017-05-03 06:51 -0700
                              Re: Is this code considered to transgress the signed overflow purism? jadill33@gmail.com - 2017-05-03 09:03 -0700
                            Re: Is this code considered to transgress the signed overflow purism? supercat@casperkitty.com - 2017-05-02 14:47 -0700
                      Re: Is this code considered to transgress the signed overflow purism? joel.rees@gmail.com - 2017-05-03 17:45 -0700
            Re: Is this code considered to transgress the signed overflow purism? Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-30 14:42 -0700
          Re: Is this code considered to transgress the signed overflow purism? joel.rees@gmail.com - 2017-04-30 23:57 -0700
            Re: Is this code considered to transgress the signed overflow purism? Tim Rentsch <txr@alumni.caltech.edu> - 2017-05-02 04:32 -0700
              Re: Is this code considered to transgress the signed overflow purism? joel.rees@gmail.com - 2017-05-03 18:20 -0700
            Re: Is this code considered to transgress the signed overflow purism? luser droog <luser.droog@gmail.com> - 2017-05-08 23:12 -0700
              Re: Is this code considered to transgress the signed overflow purism? joel.rees@gmail.com - 2017-05-09 19:54 -0700
                Re: Is this code considered to transgress the signed overflow purism? luser droog <luser.droog@gmail.com> - 2017-05-09 21:21 -0700
    Re: Is this code considered to transgress the signed overflow purism? James Kuyper <jameskuyper@verizon.net> - 2017-04-27 10:46 -0400
      Re: Is this code considered to transgress the signed overflow purism? supercat@casperkitty.com - 2017-04-27 08:37 -0700
        Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-04-27 09:38 -0700
          Re: Is this code considered to transgress the signed overflow purism? supercat@casperkitty.com - 2017-04-27 10:17 -0700
            Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-04-27 12:10 -0700
          Re: Is this code considered to transgress the signed overflow purism? Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-30 13:50 -0700
            Re: Is this code considered to transgress the signed overflow purism? Keith Thompson <kst-u@mib.org> - 2017-04-30 14:11 -0700
              Re: Is this code considered to transgress the signed overflow purism? Tim Rentsch <txr@alumni.caltech.edu> - 2017-04-30 14:44 -0700
              Re: Is this code considered to transgress the signed overflow purism? joel.rees@gmail.com - 2017-04-30 22:05 -0700

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

#108715

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> On Friday, April 28, 2017 at 4:16:51 PM UTC+1, Bart wrote:
>>
>> What are you saying, that ANY multiply of signed int is undefined?
>> 
> Let's say we're load an image. width and height are 32 bit quantities. 
> We multiply them together and call malloc to create pixel buffer, then
> loop over height and width to populate it from the file.
> If int is 32 bits, some malicious person can contrive a file such that
> the multiplication overflows, our buffer is too small, and we have a
> security leak. Unless we have an environment where an overflow leads
> to termination of the program with an error message.

I'm not sure what your point is.  It is always the responsibility of the
programmer to ensure the his or her code is correct.  Are you just
saying that C does not help as much with that task as some higher-level
languages do?

-- 
Ben.

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

#108717

On 29/04/2017 03:11, Malcolm McLean wrote:
> On Friday, April 28, 2017 at 4:16:51 PM UTC+1, Bart wrote:
>>
>> What are you saying, that ANY multiply of signed int is undefined?
>>
> Let's say we're load an image. width and height are 32 bit quantities.
> We multiply them together and call malloc to create pixel buffer, then
> loop over height and width to populate it from the file.
> If int is 32 bits, some malicious person can contrive a file such that
> the multiplication overflows, our buffer is too small, and we have a
> security leak. Unless we have an environment where an overflow leads
> to termination of the program with an error message.

That would apply also when these 32 bit quantities are unsigned. As 
could well be the case with things such as height and width.

It doesn't appear to have anything to do with the undefined behaviour 
associated with the use of signed integers that everyone seems to be 
obsessed with.

That fact that that only arises when they are used on ones complement 
and signed magnitude systems (which seem to be imaginary systems that no 
one ever uses) doesn't help. But *because* C has stipulated that such 
operations are undefined behaviour, it means that can affect even code 
that runs on the vast majority of system that are twos complement, 
because compilers can take 'advantage' of that.

The problem is that people go to the trouble of avoiding UB with signed 
operations, then get lulled into a false sense of security when they use 
unsigned.

So (32-bit) unsigned A and B are both 1000000, A*B is 3,567,587,328 
rather than 1,000,000,000,000, but no problem because it's modular 
arithmetic, and its behaviour is well defined. Wrong, but at least it's 
not UB. It will be predictably wrong on all systems.

-- 
Bartc

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

#108720

bartc <bc@freeuk.com> writes:
<snip>
> So (32-bit) unsigned A and B are both 1000000, A*B is 3,567,587,328
> rather than 1,000,000,000,000, but no problem because it's modular
> arithmetic, and its behaviour is well defined. Wrong, but at least
> it's not UB. It will be predictably wrong on all systems.

Why is it wrong?  I like languages like Haskell where 10^6 * 10^6 ==
10^12 but that comes at a price I doubt you'd consider acceptable for
C.  Slightly cheaper (though still unacceptable to most C programmers)
would be to insist that all such operations raise an exception.
The cheapest would be to have made unsigned overflow undefined too, but,
again, I doubt you'd want *more* UB in C.  The current definition of
unsigned arithmetic is cheap to implement, easy to understand and very
useful.  That's not what I'd call "wrong".

-- 
Ben.

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

#108721

On 29/04/2017 12:01, Ben Bacarisse wrote:
> bartc <bc@freeuk.com> writes:
> <snip>
>> So (32-bit) unsigned A and B are both 1000000, A*B is 3,567,587,328
>> rather than 1,000,000,000,000, but no problem because it's modular
>> arithmetic, and its behaviour is well defined. Wrong, but at least
>> it's not UB. It will be predictably wrong on all systems.
>
> Why is it wrong?  I like languages like Haskell where 10^6 * 10^6 ==
> 10^12 but that comes at a price I doubt you'd consider acceptable for
> C.  Slightly cheaper (though still unacceptable to most C programmers)
> would be to insist that all such operations raise an exception.
> The cheapest would be to have made unsigned overflow undefined too, but,
> again, I doubt you'd want *more* UB in C.  The current definition of
> unsigned arithmetic is cheap to implement, easy to understand and very
> useful.  That's not what I'd call "wrong".
>

It's wrong because it gives the wrong answer, and is likely an error in 
the program if it was intended to be mathematically correct.

My point is that the emphasis seems to be on avoiding undefined 
behaviour rather than getting correct behaviour.

I would call that erroneous result above 'overflow', but C suggests that 
that is not possible. The answer is still wrong however if A and B 
represent, say, width and height of some rectangle, and you want to work 
out its area.

(Solutions needn't be expensive when a wider type is available, eg. 64 
bits when A and B are 32.)

-- 
bartc

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

#108730

On 29/04/17 13:47, bartc wrote:
> On 29/04/2017 12:01, Ben Bacarisse wrote:
>> bartc <bc@freeuk.com> writes:
>> <snip>
>>> So (32-bit) unsigned A and B are both 1000000, A*B is 3,567,587,328
>>> rather than 1,000,000,000,000, but no problem because it's modular
>>> arithmetic, and its behaviour is well defined. Wrong, but at least
>>> it's not UB. It will be predictably wrong on all systems.
>>
>> Why is it wrong?  I like languages like Haskell where 10^6 * 10^6 ==
>> 10^12 but that comes at a price I doubt you'd consider acceptable for
>> C.  Slightly cheaper (though still unacceptable to most C programmers)
>> would be to insist that all such operations raise an exception.
>> The cheapest would be to have made unsigned overflow undefined too, but,
>> again, I doubt you'd want *more* UB in C.  The current definition of
>> unsigned arithmetic is cheap to implement, easy to understand and very
>> useful.  That's not what I'd call "wrong".
>>
>
> It's wrong because it gives the wrong answer, and is likely an error in
> the program if it was intended to be mathematically correct.

What would, in your opinion, be the "right" answer - given the 
constraint that the value has to be stored in a 32-bit integer (signed 
or unsigned - you pick) ?

Overflows are always going to be "wrong" in some way for some uses - 
there is no possibility of making them entirely correct.  You cannot 
store 10^12 in a 32-bit value.  So if you, like in Haskell or Python, 
extend the value to hold 10^12 for correct mathematics, you are now 
"wrong" regarding the size of the object and its efficiency in coding.

If you are designing a programming language, you make decisions about 
how these are handled - and different languages take different approaches.

In C, unsigned arithmetic is done as modulo - so the result of 
multiplying two 32-bit unsigned values 1000000 /is/ 3,567,587,328.  It 
is not wrong, it is correct - mathematically correct.  It is just a 
different mathematical operation that you might first expect.

For signed arithmetic, C takes the stance that the many different ways 
of handling it are wrong in too many cases, and inefficient to implement 
in at least some target architectures - so it makes it undefined behaviour.

>
> My point is that the emphasis seems to be on avoiding undefined
> behaviour rather than getting correct behaviour.
>
> I would call that erroneous result above 'overflow', but C suggests that
> that is not possible. The answer is still wrong however if A and B
> represent, say, width and height of some rectangle, and you want to work
> out its area.
>
> (Solutions needn't be expensive when a wider type is available, eg. 64
> bits when A and B are 32.)
>

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

#108737

On 29/04/2017 14:20, David Brown wrote:
> On 29/04/17 13:47, bartc wrote:

>> It's wrong because it gives the wrong answer, and is likely an error in
>> the program if it was intended to be mathematically correct.
>
> What would, in your opinion, be the "right" answer - given the
> constraint that the value has to be stored in a 32-bit integer (signed
> or unsigned - you pick) ?

There is no right answer. But that's the same whether signed or 
unsigned. It might go wrong less often with unsigned because it has one 
bit of extra range. But that might be the only reason why something is 
unsigned, because it can represent bigger values. Nothing to do with 
avoiding UB with signed or wanting modular arithmetic with unsigned.

It's a pure numeric problem that ought to be the same with any language 
(one that doesn't auto-scale to arbitrary precision):

You have a numeric type that has a range of roughly 0..N or -N/2..N/2, 
and have to consider what might happen if an operation on A and B, both 
within such a range, has a mathematical result (ie. what you'd get doing 
the same op on a Casio) outside the range.

-- 
bartc

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

#108738

On 29/04/17 16:22, bartc wrote:
> On 29/04/2017 14:20, David Brown wrote:
>> On 29/04/17 13:47, bartc wrote:
>
>>> It's wrong because it gives the wrong answer, and is likely an error in
>>> the program if it was intended to be mathematically correct.
>>
>> What would, in your opinion, be the "right" answer - given the
>> constraint that the value has to be stored in a 32-bit integer (signed
>> or unsigned - you pick) ?
>
> There is no right answer. But that's the same whether signed or
> unsigned. It might go wrong less often with unsigned because it has one
> bit of extra range. But that might be the only reason why something is
> unsigned, because it can represent bigger values. Nothing to do with
> avoiding UB with signed or wanting modular arithmetic with unsigned.
>
> It's a pure numeric problem that ought to be the same with any language
> (one that doesn't auto-scale to arbitrary precision):
>
> You have a numeric type that has a range of roughly 0..N or -N/2..N/2,
> and have to consider what might happen if an operation on A and B, both
> within such a range, has a mathematical result (ie. what you'd get doing
> the same op on a Casio) outside the range.
>

Why should it be the same in any language?  It is /not/ a "purely 
numeric problem" - precisely because there is no "purely numeric" 
correct answer.

For some languages, the style and philosophy of the language means that 
any such overflows should result in an exception or other run-time error 
handling.  For some languages, the style and philosophy of the language 
means that the arithmetic should be handled as quickly and efficiently 
as possible, with the issues surrounding overflow being ignored.  And 
for some languages, auto-scaling (or perhaps just using a fixed size but 
very large integer type) is the only suitable choice.

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

#108736

bartc <bc@freeuk.com> writes:

> On 29/04/2017 12:01, Ben Bacarisse wrote:
>> bartc <bc@freeuk.com> writes:
>> <snip>
>>> So (32-bit) unsigned A and B are both 1000000, A*B is 3,567,587,328
>>> rather than 1,000,000,000,000, but no problem because it's modular
>>> arithmetic, and its behaviour is well defined. Wrong, but at least
>>> it's not UB. It will be predictably wrong on all systems.
>>
>> Why is it wrong?  I like languages like Haskell where 10^6 * 10^6 ==
>> 10^12 but that comes at a price I doubt you'd consider acceptable for
>> C.  Slightly cheaper (though still unacceptable to most C programmers)
>> would be to insist that all such operations raise an exception.
>> The cheapest would be to have made unsigned overflow undefined too, but,
>> again, I doubt you'd want *more* UB in C.  The current definition of
>> unsigned arithmetic is cheap to implement, easy to understand and very
>> useful.  That's not what I'd call "wrong".
>
> It's wrong because it gives the wrong answer, and is likely an error
> in the program if it was intended to be mathematically correct.

That's not an interesting kind of wrong -- it depends on what the intent
was (you didn't say) and on a bunch of definitions.  The interesting
meaning (which was the point I thought you were making) is that some of
C's arithmetic choices were the wrong ones.

> My point is that the emphasis seems to be on avoiding undefined
> behaviour rather than getting correct behaviour.
>
> I would call that erroneous result above 'overflow', but C suggests
> that that is not possible. The answer is still wrong however if A and
> B represent, say, width and height of some rectangle, and you want to
> work out its area.
>
> (Solutions needn't be expensive when a wider type is available, eg. 64
> bits when A and B are 32.)

But that was not available when C was being defined, and by the time 64
bit types where mandated, too much code was written with the old
semantics.  And, of course, that does not solve the problem but simply
pushes it to another type.  Provided you mean "it's not what I want
nowadays" then I accept that C's choices are "wrong".  But if you mean
more that that, what should the rules have been (around 1980) to avoid
people on Usenet declaring it wrong 35 years later?

-- 
Ben.

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

#108724

Ben Bacarisse <ben.usenet@bsb.me.uk> writes:

> The cheapest would be to have made unsigned overflow undefined too

IIRC DMR papers on C history, unsigned was introduced to get the wrap
around behavior (which was available on pointers; pointers behaved at that
time of C evolution as a mix of pointers and unsigned now).

Yours,

-- 
Jean-Marc

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

#108723

On 4/28/2017 10:11 PM, Malcolm McLean wrote:
> On Friday, April 28, 2017 at 4:16:51 PM UTC+1, Bart wrote:
>>
>> What are you saying, that ANY multiply of signed int is undefined?
>>
> Let's say we're load an image. width and height are 32 bit quantities. 
> We multiply them together and call malloc to create pixel buffer, then
> loop over height and width to populate it from the file.
> If int is 32 bits, some malicious person can contrive a file such that
> the multiplication overflows, our buffer is too small, and we have a
> security leak. Unless we have an environment where an overflow leads
> to termination of the program with an error message.
>    
> 

If you properly verify the size is within the appropriate limits, and
reject images which are too large, this can't happen.

This is exactly why there are so many successful hacks.  Too many
programmers don't validate input.  NEVER trust input from a user.
Verify EVERYTHING.

-- 
==================
Remove the "x" from my email address
Jerry Stuckle
jstucklex@attglobal.net
==================

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

#108725

Jerry Stuckle <jstucklex@attglobal.net> writes:

> Too many programmers don't validate input.  NEVER trust input from a
> user.  Verify EVERYTHING.

This should be printed in Bold Capitals in the frontspiece of every
introductory programming book (and most advanced ones too).

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

#108727

On Saturday, April 29, 2017 at 1:05:27 PM UTC+1, Jerry Stuckle wrote:
> On 4/28/2017 10:11 PM, Malcolm McLean wrote:
> > On Friday, April 28, 2017 at 4:16:51 PM UTC+1, Bart wrote:
> >>
> >> What are you saying, that ANY multiply of signed int is undefined?
> >>
> > Let's say we're load an image. width and height are 32 bit quantities. 
> > We multiply them together and call malloc to create pixel buffer, then
> > loop over height and width to populate it from the file.
> > If int is 32 bits, some malicious person can contrive a file such that
> > the multiplication overflows, our buffer is too small, and we have a
> > security leak. Unless we have an environment where an overflow leads
> > to termination of the program with an error message.
> >    
> > 
> 
> If you properly verify the size is within the appropriate limits, and
> reject images which are too large, this can't happen.
> 
> This is exactly why there are so many successful hacks.  Too many
> programmers don't validate input.  NEVER trust input from a user.
> Verify EVERYTHING.
> 
It's a bit harder than it looks.

int width = get32(file);
int height = get32(file);
int buffsize = width * height; // uh oh. UB here, can't do that

if( (double) width * (double) height < sanity) // this is a way, but it's
fiddly and what is "sanity for an image? Not all images are intended for human viewing on a monitor screen.

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

#108728

On Sat, 29 Apr 2017 05:55:19 -0700 (PDT)
Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote:

> It's a bit harder than it looks.
> 
> int width = get32(file);
> int height = get32(file);
> int buffsize = width * height; // uh oh. UB here, can't do that
> 
> if( (double) width * (double) height < sanity) // this is a way, but it's
> fiddly and what is "sanity for an image? Not all images are intended for human
viewing on a monitor screen.

sanity should be less or equal to INT_MAX / (sizeof (pixel_t)). 

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

#108731

On 29/04/17 14:55, Malcolm McLean wrote:
> On Saturday, April 29, 2017 at 1:05:27 PM UTC+1, Jerry Stuckle wrote:
>> On 4/28/2017 10:11 PM, Malcolm McLean wrote:
>>> On Friday, April 28, 2017 at 4:16:51 PM UTC+1, Bart wrote:
>>>>
>>>> What are you saying, that ANY multiply of signed int is undefined?
>>>>
>>> Let's say we're load an image. width and height are 32 bit quantities.
>>> We multiply them together and call malloc to create pixel buffer, then
>>> loop over height and width to populate it from the file.
>>> If int is 32 bits, some malicious person can contrive a file such that
>>> the multiplication overflows, our buffer is too small, and we have a
>>> security leak. Unless we have an environment where an overflow leads
>>> to termination of the program with an error message.
>>>
>>>
>>
>> If you properly verify the size is within the appropriate limits, and
>> reject images which are too large, this can't happen.
>>
>> This is exactly why there are so many successful hacks.  Too many
>> programmers don't validate input.  NEVER trust input from a user.
>> Verify EVERYTHING.
>>
> It's a bit harder than it looks.
>
> int width = get32(file);
> int height = get32(file);
> int buffsize = width * height; // uh oh. UB here, can't do that
>
> if( (double) width * (double) height < sanity) // this is a way, but it's
> fiddly and what is "sanity for an image? Not all images are intended for human viewing on a monitor screen.
>

1. It is /not/ hard - it is very simple, and C provides a number of 
different methods for doing this safely.  Use long longs - problem solved.

2. It is also simple to use application-specific limitations.  You can 
quite reasonably say that the application can't handle widths or heights 
greater than 32767 - problem solved.  (Certainly that would be fine on 
any platform that does not have 64-bit types.)

3. If you really find a situation where validating the input is hard, 
then you do the hard work and write the code anyway.  "Hard" is not an 
excuse for being lazy or wrong.

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

#108733

Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:

> int buffsize = width * height; // uh oh. UB here, can't do that

If only * had some sort of inverse operation we could use to check
whether width*height > INT_MAX

Lets pretend theres an operator called \ that does
inverse-multiplication. Then we could write

if(width <= INT_MAX \ height) {
    // No UB!!
}

But without that operator, we're definitely stuck with casting
everything to doubles.

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

#109128

Malcom wrote:
int width = get32(file); 
int height = get32(file); 
int buffsize = width * height; // uh oh. UB here, can't do that
-------
I can see that in this way:
u32 width = get32(file); 
u32 height = get32(file); 
u64 buffsize = width * height;

Or
u16 width = get16(file); 
u16 height = get16(file); 
u32 buffsize = width * height;

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

#109146

On Wednesday, May 3, 2017 at 2:17:45 PM UTC-5, asetof...@gmail.com wrote:
> Malcom wrote:
> int width = get32(file); 
> int height = get32(file); 
> int buffsize = width * height; // uh oh. UB here, can't do that
> -------
> I can see that in this way:
> u32 width = get32(file); 
> u32 height = get32(file); 
> u64 buffsize = width * height;
> 
> Or
> u16 width = get16(file); 
> u16 height = get16(file); 
> u32 buffsize = width * height;

The former version could invoke Undefined Behavior for some inputs on
systems where "int" has between 32 and 63 value bits, and the latter
version could cause Undefined Behavior on systems where it has between
16 and 31 value bits.  In addition, it's unlikely that either version
would behave in the intended defined fashion for all inputs except when
the size of "int" exceeds the range that could cause UB.

If one wants to check values for validity on a system where long long
multiplies are expensive, and the maximum valid size is below UINT_MAX/2,
one may start by identifying which value is larger, and then require all
of the following:

  smaller < 46341
  ((((1u*larger)>>16)*smaller)<<16) <= max_size
  1u*larger*smaller <= max_size

If the first expression is true, the second cannot cause wraparound, and if
both the first and second are true and max size is less than UINT_MAX/2,
the third can't cause wraparound either.

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

#109120

I agree; limits exist 

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

#109131

On 03/05/17 20:26, asetofsymbols@gmail.com wrote:
> I agree; limits exist
>

Please use a newsreader and a proper newsserver.  If you must use Google 
Groups, learn to use it properly.  Include proper context and 
attribution.  Posts like this one are completely meaningless.

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

#109174

Brown wrote:
On 03/05/17 20:26, asetof...@gmail.com wrote: 
> I agree; limits exist 
> 

Please use a newsreader and a proper newsserver.  If you must use Google 
Groups, learn to use it properly.  Include proper context and 
attribution.  Posts like this one are completely meaningless.
------
I have to redefine it...
Limits exist and one has to find these
on input check the function argument 
or obj integrity (no error obj as argument) or in the computation check the carry flag if some language as it

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

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

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

csiph-web