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

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

Mars lander crash

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

Contents

  Mars lander crash jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-09 13:26 +0100
    Re: Mars lander crash Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 12:44 +0000
      Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-09 14:53 +0100
        Re: Mars lander crash already5chosen@yahoo.com - 2016-12-09 05:58 -0800
          Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-09 15:11 +0100
          Re: Mars lander crash jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-09 16:56 +0100
            Re: Mars lander crash supercat@casperkitty.com - 2016-12-09 08:51 -0800
            Re: Mars lander crash already5chosen@yahoo.com - 2016-12-11 02:23 -0800
              Re: Mars lander crash Gareth Owen <gwowen@gmail.com> - 2016-12-11 10:57 +0000
            Re: Mars lander crash "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-11 12:34 -0500
              Re: Mars lander crash Robert Wessel <robertwessel2@yahoo.com> - 2016-12-11 23:33 -0600
        Re: Mars lander crash Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 14:22 +0000
          Re: Mars lander crash asetofsymbols@gmail.com - 2016-12-09 06:30 -0800
            Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-09 15:48 +0100
          Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-09 15:46 +0100
            Re: Mars lander crash Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 14:55 +0000
              Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-09 16:08 +0100
                Re: Mars lander crash Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 15:52 +0000
            Re: Mars lander crash jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-09 17:35 +0100
              Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-09 18:35 +0100
                Re: Mars lander crash jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-09 19:10 +0100
                  Re: Mars lander crash "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-09 19:18 -0500
                  Re: Mars lander crash Keith Thompson <kst-u@mib.org> - 2016-12-09 16:49 -0800
                    Re: Mars lander crash "J. Clarke" <j.clarke.873638@gmail.com> - 2016-12-20 20:03 -0500
                  Re: Mars lander crash <william@wilbur.25thandClement.com> - 2016-12-09 22:04 -0800
                    Re: Mars lander crash supercat@casperkitty.com - 2016-12-10 10:59 -0800
                  Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-11 13:22 +0100
                    Re: Mars lander crash jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-11 14:18 +0100
                      Re: Mars lander crash already5chosen@yahoo.com - 2016-12-11 06:03 -0800
                        Re: Mars lander crash jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-11 15:08 +0100
                          Re: Mars lander crash already5chosen@yahoo.com - 2016-12-11 06:20 -0800
                            Re: Mars lander crash luser droog <luser.droog@gmail.com> - 2016-12-11 07:08 -0800
                            Re: Mars lander crash Keith Thompson <kst-u@mib.org> - 2016-12-11 11:56 -0800
                              Re: Mars lander crash jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-11 21:05 +0100
                                Re: Mars lander crash jameskuyper@verizon.net - 2016-12-11 12:57 -0800
                                Re: Mars lander crash Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 21:26 +0000
                        Re: Mars lander crash supercat@casperkitty.com - 2016-12-11 09:23 -0800
                    Re: Mars lander crash Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 14:01 +0000
                      Re: Mars lander crash jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-11 15:11 +0100
                      Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-11 18:57 +0100
                        Re: Mars lander crash jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-11 19:23 +0100
                          Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-11 19:55 +0100
                            Re: Mars lander crash jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-11 20:52 +0100
                              Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-11 23:37 +0100
                                Re: Mars lander crash supercat@casperkitty.com - 2016-12-11 16:10 -0800
                                  Re: Mars lander crash BartC <bc@freeuk.com> - 2016-12-12 01:13 +0000
                                    Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-12 09:53 +0100
                                      Re: Mars lander crash supercat@casperkitty.com - 2016-12-12 08:30 -0800
                                  Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-12 09:25 +0100
                        Re: Mars lander crash supercat@casperkitty.com - 2016-12-11 10:36 -0800
                        Re: Mars lander crash Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-11 18:46 +0000
                    Re: Mars lander crash supercat@casperkitty.com - 2016-12-11 09:12 -0800
                      Re: Mars lander crash jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-11 18:53 +0100
                        Re: Mars lander crash Keith Thompson <kst-u@mib.org> - 2016-12-11 12:09 -0800
                          Re: Mars lander crash Jean-Marc Bourguet <jm@bourguet.org> - 2016-12-11 21:30 +0100
                          Re: Mars lander crash Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-11 15:50 -0500
                          Re: Mars lander crash jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-11 23:02 +0100
                            Re: Mars lander crash Keith Thompson <kst-u@mib.org> - 2016-12-11 18:29 -0800
                      Re: Mars lander crash Keith Thompson <kst-u@mib.org> - 2016-12-11 12:03 -0800
                    Re: Mars lander crash Keith Thompson <kst-u@mib.org> - 2016-12-11 11:55 -0800
                      Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-11 23:42 +0100
                        Re: Mars lander crash Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-11 14:53 -0800
                          Re: Mars lander crash Ian Collins <ian-news@hotmail.com> - 2016-12-12 17:09 +1300
                          Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-12 10:00 +0100
                            Re: Mars lander crash Ian Collins <ian-news@hotmail.com> - 2016-12-12 22:20 +1300
                              Re: Mars lander crash Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-12 01:28 -0800
                                Re: Mars lander crash Ian Collins <ian-news@hotmail.com> - 2016-12-12 22:38 +1300
                                  Re: Mars lander crash Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-12 02:43 -0800
                                    Re: Mars lander crash Ian Collins <ian-news@hotmail.com> - 2016-12-13 08:20 +1300
                                      Re: Mars lander crash Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-12 12:57 -0800
                                        Re: Mars lander crash Ian Collins <ian-news@hotmail.com> - 2016-12-13 14:14 +1300
                                          Re: Mars lander crash Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-13 01:19 -0800
                                            Re: Mars lander crash Ian Collins <ian-news@hotmail.com> - 2016-12-13 22:56 +1300
                                              Re: Mars lander crash Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-13 05:16 -0800
                                                Re: Mars lander crash Ian Collins <ian-news@hotmail.com> - 2016-12-14 18:05 +1300
                                            Re: Mars lander crash Keith Thompson <kst-u@mib.org> - 2016-12-13 08:19 -0800
                                              Re: Mars lander crash Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-13 17:01 +0000
                                                Re: Mars lander crash Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-13 10:48 -0800
                                                  Re: Mars lander crash Geoff <geoff@invalid.invalid> - 2016-12-13 11:56 -0800
                                                    Re: Mars lander crash Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-13 13:37 -0800
                                                      Re: Mars lander crash Geoff <geoff@invalid.invalid> - 2016-12-13 19:11 -0800
                                                Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-13 20:13 +0100
                                                  Re: Mars lander crash supercat@casperkitty.com - 2016-12-13 11:45 -0800
                                                  Re: Mars lander crash Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-13 23:10 +0000
                                                    Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-14 10:18 +0100
                                                      Re: Mars lander crash Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-14 12:37 +0000
                                                        Re: Mars lander crash Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-14 21:31 -0800
                                                          Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-15 13:26 +0100
                    Re: Mars lander crash Ian Collins <ian-news@hotmail.com> - 2016-12-12 22:40 +1300
                      Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-12 13:22 +0100
                        Re: Mars lander crash supercat@casperkitty.com - 2016-12-12 08:35 -0800
          Re: Mars lander crash supercat@casperkitty.com - 2016-12-09 08:43 -0800
        Re: Mars lander crash Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 09:47 -0500
          Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-09 16:11 +0100
            Re: Mars lander crash Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:49 -0500
    Re: Mars lander crash already5chosen@yahoo.com - 2016-12-09 05:53 -0800
      Re: Mars lander crash asetofsymbols@gmail.com - 2016-12-09 06:04 -0800
        Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-09 15:09 +0100
          Re: Mars lander crash Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:06 -0500
            Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-09 16:32 +0100
      Re: Mars lander crash jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-09 17:30 +0100
        Re: Mars lander crash BartC <bc@freeuk.com> - 2016-12-09 16:42 +0000
        Re: Mars lander crash Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2016-12-09 11:43 -0500
        Re: Mars lander crash Keith Thompson <kst-u@mib.org> - 2016-12-09 08:59 -0800
        Re: Mars lander crash "J. Clarke" <j.clarke.873638@gmail.com> - 2016-12-20 19:36 -0500
    Re: Mars lander crash "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2016-12-09 06:46 -0800
      Re: Mars lander crash Richard Heathfield <rjh@cpax.org.uk> - 2016-12-09 14:57 +0000
        Re: Mars lander crash Noob <root@127.0.0.1> - 2016-12-09 16:07 +0100
      Re: Mars lander crash David Brown <david.brown@hesbynett.no> - 2016-12-09 16:03 +0100
        Re: Mars lander crash "James R. Kuyper" <jameskuyper@verizon.net> - 2016-12-09 12:41 -0500
      Re: Mars lander crash Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 10:52 -0500
        Re: Mars lander crash jameskuyper@verizon.net - 2016-12-09 12:13 -0800
          Re: Mars lander crash jacobnavia <jacob@jacob.remcomp.fr> - 2016-12-09 21:56 +0100
            Re: Mars lander crash jameskuyper@verizon.net - 2016-12-09 14:11 -0800
          Re: Mars lander crash Jerry Stuckle <jstucklex@attglobal.net> - 2016-12-09 22:46 -0500
            Re: Mars lander crash <william@wilbur.25thandClement.com> - 2016-12-09 22:34 -0800
            Re: Mars lander crash James Kuyper <jameskuyper@verizon.net> - 2016-12-10 18:38 -0500
        Re: Mars lander crash Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-11 06:06 -0800
    Re: Mars lander crash "Mr. Man-wai Chang" <toylet.toylet@gmail.com> - 2016-12-10 01:17 +0800
    Re: Mars lander crash Ken Brody <kenbrody@spamcop.net> - 2016-12-13 14:28 -0500
    Re: Mars lander crash Ken Brody <kenbrody@spamcop.net> - 2016-12-13 14:30 -0500

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

#98855

Le 11/12/2016 à 18:57, David Brown a écrit :
> One is that people want wildly different things for overflow detection.
> Many are perfectly happy with today's behaviour - signed integer
> overflow is undefined behaviour.  Others might want saturation, or
> wrapping, or a signal, or a sentinel value (like NaN), or a testable
> flag, or setting errno, or adding exceptions to C.

You do not read the answers I give damm!

The signal mechanism can cater for ALL of those!

And besides (as I stated in a different message) the C standard ALREADY 
prescribes the signal mechanism for this.

Integer overflow should raise the SIGFPE!

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

#98862

On 11/12/16 19:23, jacobnavia wrote:
> Le 11/12/2016 à 18:57, David Brown a écrit :
>> One is that people want wildly different things for overflow detection.
>> Many are perfectly happy with today's behaviour - signed integer
>> overflow is undefined behaviour.  Others might want saturation, or
>> wrapping, or a signal, or a sentinel value (like NaN), or a testable
>> flag, or setting errno, or adding exceptions to C.
>
> You do not read the answers I give damm!
>
> The signal mechanism can cater for ALL of those!
>
> And besides (as I stated in a different message) the C standard ALREADY
> prescribes the signal mechanism for this.
>
> Integer overflow should raise the SIGFPE!

The signal mechanism is okay for a "integer overflow causes crash" 
mechanism during testing.  But it is no use for a "overflow causes 
saturation", or "overflow causes predictable wraparound", or "overflow 
detectable by the programmer at runtime", or "overflow checked in 
advance" solution.  And for processors that don't have a suitable 
trapping mechanism such as an "add and trap on overflow" instruction or 
at least a "trap if overflow flag set" instruction, it would be 
hopelessly inefficient.

And like all overflow detection mechanisms, you either wave goodbye to 
all sorts of optimisations based on the associativity and commutativity 
of integer arithmetic, or your results and possible overflows are 
totally dependent on the arrangement of code by the optimiser.

So again, this is /one/ possible type of overflow detection that may be 
of use to some people during testing and debugging.  This might be 
enough to make it worth the effort implementing it - but it is very far 
from being a universal, useful, efficient and helpful method that could 
sensibly be standardised in C.

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

#98870

Le 11/12/2016 à 19:55, David Brown a écrit :

> The signal mechanism is okay for a "integer overflow causes crash"
> mechanism during testing.

OK. But you go on...

> But it is no use for a "overflow causes
> saturation",

No, since you can act on the info and return a result if you wish.
The compiler can generate tables of associations between operations and 
program counter values, so, the handler can just unwind the interrupt 
call and go on with a result in the right register if the compiler 
generates those tables and the runtime knows about it.

You can return a default result for the operation.

  or "overflow causes predictable wraparound",

I do not have any idea what a predictable wraparound could be.

> or "overflow
> detectable by the programmer at runtime",

A signal always should generate an action, but some people here insist 
that this is too much for them since they are using old machines. They 
think that it would be impossible to tell the compiler that in this 
function you want overflow check or not, and they bring all kinds of 
contrieved examples to prove that this is not good for the general case.


> or "overflow checked in
> advance" solution.

This doesn't look like a good idea for me, after the crash of that lander.

Maybe it wasn't overflow, but a saturation (whatever that means besides 
overflow) of the system with the noisy input data from sensors means 
that data was not laundered properly somehow isn't it?

How comes that the system thought that it was underground with a 
negative height that has been mentioned in several reports? We will know 
for sure when ESA reports exactly what happened but it looks like an 
overflow, a negative height.

In general, an overflow is an interesting condition where it should not 
happen. It means wrong input. Reacting to wrong inputs depends on the 
application, and surely some stuff is more sensitive than others...

What is interesting is the total absence of interest for treating the 
typical case, and that spotlight focus in old machines and obsolete 
stuff when we speak about C, even if machines have evolved immensely 
since only 10 years.

You have a sentimental link with that old MIPS processor? OK. Do not use 
this in that processor. But why all the other people that use better 
machines than that one should be put on hold?

> And for processors that don't have a suitable
> trapping mechanism such as an "add and trap on overflow" instruction or
> at least a "trap if overflow flag set" instruction, it would be
> hopelessly inefficient.
>

Yes, poor guys. They will not be able to do any overflow processing.

And so what?

Implicitely is the idea that C is for old machines only, and some better 
language for new software isn't it Mr Brown?

> And like all overflow detection mechanisms, you either wave goodbye to
> all sorts of optimisations based on the associativity and commutativity
> of integer arithmetic, or your results and possible overflows are
> totally dependent on the arrangement of code by the optimiser.
>

That is a quality of implementation issue. If your code analysis is 
unable to move several instructions as a block you should upgrade to a 
better one, what do you want me to do. I did not write you optimizer but 
shouldn't we check for overflow Mr Brown? I mean, OK, that mips machine 
and your strange optimizer can't cope. But that means that all people 
doing C in a modern environment should be hold down waiting that those 
situations improve?

> So again, this is /one/ possible type of overflow detection that may be
> of use to some people during testing and debugging.  This might be
> enough to make it worth the effort implementing it - but it is very far
> from being a universal, useful, efficient and helpful method that could
> sensibly be standardised in C.
>

The situation is already solved anyway. The C standard specifically 
prescribes SIGFPE for overflow. So actually it is that none of the C 
compilers implement this. I think this is totally wrong. It should be 
stressed to the main compiler people that the user has the right to 
receive SIGFPE when an overflow occurs as specified in
7.14 when defining the signals available:
<quote>
SIGFPE an erroneous arithmetic operation, such as zero divide or an 
operation resulting in overflow
<end quote>

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

#98925

On 11/12/16 20:52, jacobnavia wrote:
> Le 11/12/2016 à 19:55, David Brown a écrit :
>
>> The signal mechanism is okay for a "integer overflow causes crash"
>> mechanism during testing.
>
> OK. But you go on...
>
>> But it is no use for a "overflow causes
>> saturation",
>
> No, since you can act on the info and return a result if you wish.
> The compiler can generate tables of associations between operations and
> program counter values, so, the handler can just unwind the interrupt
> call and go on with a result in the right register if the compiler
> generates those tables and the runtime knows about it.
>
> You can return a default result for the operation.

Fair enough - I can accept this would be possible.  It would take a 
great deal of effort, or severely restrict the compiler's code 
generator.  You'd need tables to keep track of which register the 
results were in, and how they should be modified by the signal handler, 
and how the handler should return to the main code.  It strikes me as an 
extraordinary effort for something that I can't see being useful in 
practice, but I do accept that it is possible.

>
>  or "overflow causes predictable wraparound",
>
> I do not have any idea what a predictable wraparound could be.

I was thinking of simple two's complement wraparound.  It is what you 
typically get with signed integer overflow on most machines, except that 
now the compiler /knows/ you might get this and takes that into account 
in optimising.  With standard C, overflow is undefined behaviour, and 
therefore unpredictable, even though for simple cases you usually have 
two's complement wrapping.

>
>> or "overflow
>> detectable by the programmer at runtime",
>
> A signal always should generate an action, but some people here insist
> that this is too much for them since they are using old machines. They
> think that it would be impossible to tell the compiler that in this
> function you want overflow check or not, and they bring all kinds of
> contrieved examples to prove that this is not good for the general case.
>
>
>> or "overflow checked in
>> advance" solution.
>
> This doesn't look like a good idea for me, after the crash of that lander.

The lander crash was not caused by an overflow (or a saturation), but by 
a mistake in the algorithm.

By "overflow checked in advance", I mean:

	if (will_overflow_add(x, y)) {
		z = maxValue;	// or defaultValue, or whatever
	} else {
		z = x + y;
	}

rather than:

	z = x + y;
	if (did_overflow()) {
		z = maxValue;	// or defaultValue, or whatever
	}



>
> Maybe it wasn't overflow, but a saturation (whatever that means besides
> overflow) of the system with the noisy input data from sensors means
> that data was not laundered properly somehow isn't it?

Saturation means that when the results of an operation are too big for 
the return value, you return the maximum valid value.  So with 8-bit 
signed integers (to keep the numbers easy), 100 + 100 returns 127 with 
saturation.

Saturation is commonly used in DSP algorithms, amongst other things, and 
some processors (such as many ARM devices) have dedicated saturated 
arithmetic instructions.

>
> How comes that the system thought that it was underground with a
> negative height that has been mentioned in several reports? We will know
> for sure when ESA reports exactly what happened but it looks like an
> overflow, a negative height.

It could be any one of a great number of things.  Signed integer 
overflow sounds very unlikely - if they were using Kalman filters, then 
it is quite likely that they used floating point.  Failing that, they 
probably used scaled integer libraries with saturation.

As Bart said previously, you can get a negative value without overflow, 
such as 3 - 5.  All you need is incorrect data and/or an incorrect 
algorithm and/or an incorrect implementation of the algorithm.

>
> In general, an overflow is an interesting condition where it should not
> happen. It means wrong input. Reacting to wrong inputs depends on the
> application, and surely some stuff is more sensitive than others...
>
> What is interesting is the total absence of interest for treating the
> typical case, and that spotlight focus in old machines and obsolete
> stuff when we speak about C, even if machines have evolved immensely
> since only 10 years.

I am happy with the idea of trying to think of common causes of 
problems, and finding ways to help programmers deal with them.

But personally, I just do not believe that signed integer overflow /is/ 
a "typical case".  I don't see it as a big problem.  And I certainly 
don't see it as a likely problem in a situation like this one.  Adding 
to that, I don't see any kind of automatic handling of overflow (beyond 
"crash to the debugger to help testing and development") as being of any 
benefit if an overflow /does/ occur.

However, as I have said before, these is /my/ thoughts on the matter. 
If you think differently, then that's fine.  I have tried to give you 
the best advice and ideas I can.  You can use them or ignore them.

>
> You have a sentimental link with that old MIPS processor? OK. Do not use
> this in that processor. But why all the other people that use better
> machines than that one should be put on hold?
>
>> And for processors that don't have a suitable
>> trapping mechanism such as an "add and trap on overflow" instruction or
>> at least a "trap if overflow flag set" instruction, it would be
>> hopelessly inefficient.
>>
>
> Yes, poor guys. They will not be able to do any overflow processing.
>
> And so what?
>
> Implicitely is the idea that C is for old machines only, and some better
> language for new software isn't it Mr Brown?

No.  The idea is that if something is to be /standard/ C, then it should 
work well on a wide range of devices - from very small to very big, new 
and old, simple and complex, fast and slow, weird and "normal".  That is 
one of the key features of C.  If a new feature would not work well on 
this wide range of systems - /including/ new, fast and powerful cpus - 
it is not suitable for /standard/.

It might be fine as an extension for a particular implementation of C - 
but that is a different matter.

(Again, I will use gcc as an example because I am familiar with it, and 
you can easily check the details of what I write.)

Thus gcc has an /option/ "-ftrapv" to use trap-on-overflow on systems 
that support it, though it is not recommended as it is not accurate due 
to optimisations.  It also has /extensions/ of builtin functions for 
overflow handling.  And it has a /debugging option/ for "sanitizing" 
integer overflow.

Those are all fine tools (though "-ftrapv" is now considered outdated), 
and I applaud any efforts you might make to put similar tools in your 
own compiler.  I am not convinced that it is the best use of your 
development time, but you must be the judge of that, not me.

>
>> And like all overflow detection mechanisms, you either wave goodbye to
>> all sorts of optimisations based on the associativity and commutativity
>> of integer arithmetic, or your results and possible overflows are
>> totally dependent on the arrangement of code by the optimiser.
>>
>
> That is a quality of implementation issue. If your code analysis is
> unable to move several instructions as a block you should upgrade to a
> better one, what do you want me to do. I did not write you optimizer but
> shouldn't we check for overflow Mr Brown? I mean, OK, that mips machine
> and your strange optimizer can't cope. But that means that all people
> doing C in a modern environment should be hold down waiting that those
> situations improve?
>
>> So again, this is /one/ possible type of overflow detection that may be
>> of use to some people during testing and debugging.  This might be
>> enough to make it worth the effort implementing it - but it is very far
>> from being a universal, useful, efficient and helpful method that could
>> sensibly be standardised in C.
>>
>
> The situation is already solved anyway. The C standard specifically
> prescribes SIGFPE for overflow. So actually it is that none of the C
> compilers implement this. I think this is totally wrong. It should be
> stressed to the main compiler people that the user has the right to
> receive SIGFPE when an overflow occurs as specified in
> 7.14 when defining the signals available:
> <quote>
> SIGFPE an erroneous arithmetic operation, such as zero divide or an
> operation resulting in overflow
> <end quote>

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

#98951

On Sunday, December 11, 2016 at 4:37:50 PM UTC-6, David Brown wrote:
> On 11/12/16 20:52, jacobnavia wrote:
> > I do not have any idea what a predictable wraparound could be.
> 
> I was thinking of simple two's complement wraparound.  It is what you 
> typically get with signed integer overflow on most machines, except that 
> now the compiler /knows/ you might get this and takes that into account 
> in optimising.  With standard C, overflow is undefined behaviour, and 
> therefore unpredictable, even though for simple cases you usually have 
> two's complement wrapping.

I find it interesting that some people seem absolutely astonished by the idea
that overflow could have predictable consequences, notwithstanding the fact
that on *most* platforms a compiler would have to go out of its way to make
it do anything other than yielding some number which is congruent to the
arithmetically-correct value, mod the integer range (if "int" is 16 bits,
the easiest way to perform a computation like "long x = int1*1000;" might
yield -1000000 if int1 happens to equal -1000; that value wouldn't be wrapped
to -16960, but would be congruent to -16960 mod 65536).

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

#98963

On 12/12/2016 00:10, supercat@casperkitty.com wrote:
> On Sunday, December 11, 2016 at 4:37:50 PM UTC-6, David Brown wrote:
>> On 11/12/16 20:52, jacobnavia wrote:
>>> I do not have any idea what a predictable wraparound could be.
>>
>> I was thinking of simple two's complement wraparound.  It is what you
>> typically get with signed integer overflow on most machines, except that
>> now the compiler /knows/ you might get this and takes that into account
>> in optimising.  With standard C, overflow is undefined behaviour, and
>> therefore unpredictable, even though for simple cases you usually have
>> two's complement wrapping.
>
> I find it interesting that some people seem absolutely astonished by the idea
> that overflow could have predictable consequences, notwithstanding the fact
> that on *most* platforms a compiler would have to go out of its way to make
> it do anything other than yielding some number which is congruent to the
> arithmetically-correct value, mod the integer range (if "int" is 16 bits,
> the easiest way to perform a computation like "long x = int1*1000;" might
> yield -1000000 if int1 happens to equal -1000; that value wouldn't be wrapped
> to -16960, but would be congruent to -16960 mod 65536).
>

Yes; take adding two 32-bit values on x86.

On that processor the same ADD instruction does both signed and unsigned 
addition.

It would be odd if a result is defined if considered as unsigned, and 
undefined otherwise. It's the same bit pattern resulting from A+B => C 
in both cases. Signed will predictably overflow and wrap around just 
like unsigned.

-- 
Bartc

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

#99009

On 12/12/16 02:13, BartC wrote:
> On 12/12/2016 00:10, supercat@casperkitty.com wrote:
>> On Sunday, December 11, 2016 at 4:37:50 PM UTC-6, David Brown wrote:
>>> On 11/12/16 20:52, jacobnavia wrote:
>>>> I do not have any idea what a predictable wraparound could be.
>>>
>>> I was thinking of simple two's complement wraparound.  It is what you
>>> typically get with signed integer overflow on most machines, except that
>>> now the compiler /knows/ you might get this and takes that into account
>>> in optimising.  With standard C, overflow is undefined behaviour, and
>>> therefore unpredictable, even though for simple cases you usually have
>>> two's complement wrapping.
>>
>> I find it interesting that some people seem absolutely astonished by
>> the idea
>> that overflow could have predictable consequences, notwithstanding the
>> fact
>> that on *most* platforms a compiler would have to go out of its way to
>> make
>> it do anything other than yielding some number which is congruent to the
>> arithmetically-correct value, mod the integer range (if "int" is 16 bits,
>> the easiest way to perform a computation like "long x = int1*1000;" might
>> yield -1000000 if int1 happens to equal -1000; that value wouldn't be
>> wrapped
>> to -16960, but would be congruent to -16960 mod 65536).
>>
> 
> Yes; take adding two 32-bit values on x86.
> 
> On that processor the same ADD instruction does both signed and unsigned
> addition.
> 
> It would be odd if a result is defined if considered as unsigned, and
> undefined otherwise. It's the same bit pattern resulting from A+B => C
> in both cases. Signed will predictably overflow and wrap around just
> like unsigned.
> 

That's true.  But if your code is like this:

	int sqrDist(int x, int y) {
		int x2 = x * x;
		int y2 = y * y;
		int z = x2 + y2;
		if (z < 0) z = INT_MAX;
		return z;
	}

If you think signed integer overflow is predictable, you might think
that this handles overflow on the addition (lets ignore overflow on the
multiplication now for simplicity).  Almost certainly, z will be
calculated by a simple ADD instruction.  If the addition overflows, the
result of the ADD will be the predictable two's complement wrap of true
sum, and will represent a negative signed integer, stored in a cpu
register.  It would be a simple matter to test this against zero (the
cpu flags will already be set on an x86) and saturate z.

But C is not a "high level assembler".  It does /not/ evaluate based on
the cpu it runs on.  C has its rules for evaluation, and those rules are
designed to work well with a range of processors - but not to be an
exact fit for any of them.

And the rules of C say that signed integer overflow is undefined
behaviour.  In the absence of implementation-specific documentation or
flags saying otherwise, it is fair for the compiler to assume that
signed integer overflow simply does not happen.  And since overflow does
not happen, there is no need to test for "z < 0" - it is created as the
sum of two non-negative numbers.  Thus the entire line with the test can
be omitted.

Alternatively, the compiler /could/ keep the test in and check for overflow.

Thus despite the simple "ADD" instruction being used for addition, the
results on overflow are unpredictable - the compiler might generate code
that returns a negative number, or it might return code that returns
INT_MAX.  (In theory, the code does not even have to be consistent on
this - but it would take a much more complicated example to find a
realistic case for that.)

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

#99073

On Monday, December 12, 2016 at 2:53:14 AM UTC-6, David Brown wrote:
> But C is not a "high level assembler".  It does /not/ evaluate based on
> the cpu it runs on.  C has its rules for evaluation, and those rules are
> designed to work well with a range of processors - but not to be an
> exact fit for any of them.

While C does not require that implementations process a form of "semi-
portable assembly language", it became popular in an era when many
implementations did precisely that, and I would suggest that at least
in certain fields that was one of the reasons for its popularity.  In
most cases, someone with a platform specification would be able to
identify behavioral guarantees the platform could uphold cheaply and
those it could not, and then identify potentially-useful guarantees
that it would make sense to have an implementation honor always, those
that should be configurable, and those which it shouldn't bother trying
to uphold.  Consider, for example, three ways relational operators between
unrelated objects might work on segmented-model 8086:

   1. Totally unpredictable behavior--anything can happen.

   2. No relational comparison between pointers which compiles will ever
      do anything other than yield a 0 or 1, but if pointers are unrelated
      the comparisons need not behave in a fashion consistent with equality
      tests [e.g. it would be possible for x>=y, x<=y, and x!=y, to all be
      true simultaneously].

   3. Relational operators will always yield a consistent ranking which is
      fully consistent with the equality operator and recognizes all objects
      as disjoint.

The cost difference between #3 and #2 would be significant, but the cost
difference between #2 and #1 would be negligible.  On the other hand, for
some kinds of code the stronger guarantees of #3 could be useful.  It would
thus make sense for an 8086 compiler to offer a choice between #2 and #3;
programmers should be prepared for either possibility, and while it may be
reasonable to have a program target only compilers that can be configured
for #3, any such program should make clear in its documentation the need for
such configuration.

I do not think it is helpful to say that even programmers targeting
platforms where upholding the guarantees of #2 would seldom cost *anything*
should write code that will work with #1.  

> And the rules of C say that signed integer overflow is undefined
> behaviour.  In the absence of implementation-specific documentation or
> flags saying otherwise, it is fair for the compiler to assume that
> signed integer overflow simply does not happen.  And since overflow does
> not happen, there is no need to test for "z < 0" - it is created as the
> sum of two non-negative numbers.  Thus the entire line with the test can
> be omitted.

Back in the days when C was becoming popular, certain architectural
quirks were widely recognized as obsolescent, but the authors of the
C Standard wanted to allow machines with such quirks to be capable of
supporting C implementations which could run programs where those quirks
wouldn't cause trouble.  I've seen no indication that they intended that
such allowances cause programmers decades later to be bound by the
limitations of machines that represent less than 0.0001% of the
marketplace.

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

#99001

On 12/12/16 01:10, supercat@casperkitty.com wrote:
> On Sunday, December 11, 2016 at 4:37:50 PM UTC-6, David Brown wrote:
>> On 11/12/16 20:52, jacobnavia wrote:
>>> I do not have any idea what a predictable wraparound could be.
>>
>> I was thinking of simple two's complement wraparound.  It is what you 
>> typically get with signed integer overflow on most machines, except that 
>> now the compiler /knows/ you might get this and takes that into account 
>> in optimising.  With standard C, overflow is undefined behaviour, and 
>> therefore unpredictable, even though for simple cases you usually have 
>> two's complement wrapping.
> 
> I find it interesting that some people seem absolutely astonished by the idea
> that overflow could have predictable consequences, notwithstanding the fact
> that on *most* platforms a compiler would have to go out of its way to make
> it do anything other than yielding some number which is congruent to the
> arithmetically-correct value, mod the integer range (if "int" is 16 bits,
> the easiest way to perform a computation like "long x = int1*1000;" might
> yield -1000000 if int1 happens to equal -1000; that value wouldn't be wrapped
> to -16960, but would be congruent to -16960 mod 65536).
> 

Who is astonished by the idea that overflow /could/ have predictable
consequences?  I haven't seen anyone deny that, or be surprised by it.

But more importantly, overflow might /not/ have predictable
consequences.  Unless your toolchain specifically says otherwise, a
compiler can optimise code on the assumption that it will not happen.
Thus you have /unpredictable/ consequences.

So unless you are very sure of the circumstances, such as by using a
compiler with switches to control overflow or by casting back and forth
between unsigned types (with a knowledge of the signed integer format on
the target), you are not /entirely/ sure of what will happen on
overflow.  And if you are not /entirely/ sure, the result is unpredictable.

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

#98858

On Sunday, December 11, 2016 at 11:57:25 AM UTC-6, David Brown wrote:
> "Impossible" is perhaps too strong a word.  But I think it is 
> extraordinarily unlikely that some version of overflow checking as 
> standard for signed integer arithmetic would ever become part of the C 
> standards.  Even then, I cannot see it being anything other than 
> "implementation dependent" or an optional feature, losing much of the 
> point of making it "standard".

Should code that relies upon Annex F features be regarded as no more
portable than code which relies upon aspects of floating-point behavior
which are unique to one particular implementation?

Suggesting that implementations which can support certain features should
do them a particular way when practical would be far more useful than
saying that code which uses any feature that would only practical on 70%
of implementations should be considered no more portable than code which
needs features that are unique to one.

> It is somewhat more realistic to imagine that user-accessible functions 
> such as "_Overflow_add" (corresponding to existing 
> __builtin_overflow_add) could be added to the standard library as an 
> optional feature.  I would be quite happy to see such an addition, but I 
> won't hold my breath waiting for it.

Such functions would be better than nothing, but since they cannot obey
the same associative laws as mathematical integers, code using them could
not be nearly as efficient as code which used looser integer-overflow
semantics.

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

#98861

David Brown <david.brown@hesbynett.no> writes:

> On 11/12/16 15:01, Ben Bacarisse wrote:
>> David Brown <david.brown@hesbynett.no> writes:
>> <snip>
>>> By now you must have realised that it is /impossible/ for C to have a
>>> standard method of detecting integer overflows
>>
>> I don't get this.  Why is it impossible?
>>
>
> There are two reasons.  One is that people want wildly different
> things for overflow detection.
<snip>
> Secondly, it has already been established that while all processors
> will have some way to detect overflow, many cannot do so efficiently -
<snip>
> "Impossible" is perhaps too strong a word.

Ah, I see.  I would no call that "impossible" but I know what you mean now.

<snip>
-- 
Ben.

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

#98839

On Sunday, December 11, 2016 at 6:22:48 AM UTC-6, David Brown wrote:
> By now you must have realised that it is /impossible/ for C to have a 
> standard method of detecting integer overflows (and buffer overruns, 
> though these are new to the thread here).  Please do not continue 
> arguing for them - it cannot and will not happen, and I believe you 
> already know this and understand some of the reasons for that (even if 
> you don't agree with all of the reasons).

There are many C implementations where it would be impractical to support
concepts like NaN, infinities, and signed zeroes, but that didn't prevent
C89 from defining such concepts.  Instead, Annex F classifies them as an
optional feature.  Implementations must indicate via macro whether they
guarantee the semantics in that Annex; an implementation-writer who doesn't
to bother with Annex F can satisfy all obligations related to that Annex
merely by indicating that its features are not supported.

Since implementations of languages like Java are becoming more and more
efficient, I don't think C will remain competitive on the basis of
performance alone.  If, however, there were an annex which allowed C
to offer safety features which were better than those of other languages
like Java, that would be a major selling point in its favor.  Such
features might not be practical on all implementations, but support for
integer types that have a latching overflow flag should be practical on
many.  If 25% of implementations could accommodate such a thing, having
a standard way to make code portable among those 25% of implementations
would be far more useful than having every implementation that could
support such features do so in a different way.

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

#98849

The C standard already specifies

<quote>
SIGFPE an erroneous arithmetic operation, such as zero divide or an 
operation resulting in overflow
<end quote>
(7.14 Signal handling <signal.h>)

it ALREADY prescribes a possible solution but in the next sentence it says
<quote>
An implementation need not generate any of these signals.
<end quote>

In any case I will modify lcc-win to generate SIGFPE instead of 
branching to an ad-hoc routine.

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

#98877

jacobnavia <jacob@jacob.remcomp.fr> writes:
> The C standard already specifies
>
> <quote>
> SIGFPE an erroneous arithmetic operation, such as zero divide or an 
> operation resulting in overflow
> <end quote>
> (7.14 Signal handling <signal.h>)
>
> it ALREADY prescribes a possible solution but in the next sentence it says
> <quote>
> An implementation need not generate any of these signals.
> <end quote>
>
> In any case I will modify lcc-win to generate SIGFPE instead of 
> branching to an ad-hoc routine.

Sure, but the FPE in SIGFPE stands for "floating point exception".

Signed integer overflow has undefined behavior, so raising SIGFPE is
a perfectly valid response, but I don't believe that was the intent.
Just for the sake of clarity, you might consider defining a separate
signal for integer overflow and divide by zero.

(I'm curious to see how you'll manage to interpret this as an insult.
For the record, it is not intended that way.)

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

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

#98880

Keith Thompson <kst-u@mib.org> writes:

> jacobnavia <jacob@jacob.remcomp.fr> writes:
>> The C standard already specifies
>>
>> <quote>
>> SIGFPE an erroneous arithmetic operation, such as zero divide or an 
>> operation resulting in overflow
>> <end quote>
>> (7.14 Signal handling <signal.h>)
>>
>> it ALREADY prescribes a possible solution but in the next sentence it says
>> <quote>
>> An implementation need not generate any of these signals.
>> <end quote>
>>
>> In any case I will modify lcc-win to generate SIGFPE instead of 
>> branching to an ad-hoc routine.
>
> Sure, but the FPE in SIGFPE stands for "floating point exception".

IIRC It is used for integer division by 0 on Unix and generating it for
floating point operations at least need some work (they tend to generate
NaN or infinities instead of signals).

> Signed integer overflow has undefined behavior, so raising SIGFPE is
> a perfectly valid response, but I don't believe that was the intent.
> Just for the sake of clarity, you might consider defining a separate
> signal for integer overflow and divide by zero.

My personal guess about why it not something commonly done is that the
signals in Unix are intended as an asynchronous communication channel
between the kernel and the process.  They are used when the process
generate an interruption as well as for other asynchronous events (IO or
accounting time out for instance).  I'd find somewhat surprising to get
them in other contexts (on a ISA generating exceptions on overflow,
implicitly or with TRAPV-like instruction inserted by the compiler, I'd
expect them), especially if the other ways of handling signals in Unix are
not available.

I don't know if Windows use signals like that; ISTR that Windows has a
notion of exception and mapping to them could be better.

Yours,

-- 
Jean-Marc

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

#98889

On Sunday December 11 2016 15:09, in comp.lang.c, "Keith Thompson"
<kst-u@mib.org> wrote:

> jacobnavia <jacob@jacob.remcomp.fr> writes:
>> The C standard already specifies
>>
>> <quote>
>> SIGFPE an erroneous arithmetic operation, such as zero divide or an
>> operation resulting in overflow
>> <end quote>
>> (7.14 Signal handling <signal.h>)
>>
>> it ALREADY prescribes a possible solution but in the next sentence it says
>> <quote>
>> An implementation need not generate any of these signals.
>> <end quote>
>>
>> In any case I will modify lcc-win to generate SIGFPE instead of
>> branching to an ad-hoc routine.
> 
> Sure, but the FPE in SIGFPE stands for "floating point exception".
> 
> Signed integer overflow has undefined behavior, so raising SIGFPE is
> a perfectly valid response, but I don't believe that was the intent.
> Just for the sake of clarity, you might consider defining a separate
> signal for integer overflow and divide by zero.

Great minds think alike, I see  ;-)
Message-ID: <o27bm1$mgq$1@dont-email.me> Date: Tue, 06 Dec 2016 16:49:04 -0500
Message-ID: <o2c20i$ulr$2@dont-email.me> Date: Thu, 08 Dec 2016 11:34:43 -0500

[snip]

-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

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

#98916

Le 11/12/2016 à 21:09, Keith Thompson a écrit :
> jacobnavia <jacob@jacob.remcomp.fr> writes:
>> The C standard already specifies
>>
>> <quote>
>> SIGFPE an erroneous arithmetic operation, such as zero divide or an
>> operation resulting in overflow
>> <end quote>
>> (7.14 Signal handling <signal.h>)
>>
>> it ALREADY prescribes a possible solution but in the next sentence it says
>> <quote>
>> An implementation need not generate any of these signals.
>> <end quote>
>>
>> In any case I will modify lcc-win to generate SIGFPE instead of
>> branching to an ad-hoc routine.
>
> Sure, but the FPE in SIGFPE stands for "floating point exception".
>

Who knows?

It could be Final Point before Exit, Full Program Error, Freak Problem 
Encountered, even False Prejudices lead to Errors, isn't it?

:-)

In any caase the standard doesn't speak of any floating point. The 
sentence is:

erroneous arithmetic operation, such as zero divide or an
operation resulting in overflow

An implementation that generates SIGFPE is standard conforming.

> Signed integer overflow has undefined behavior, so raising SIGFPE is
> a perfectly valid response, but I don't believe that was the intent.

Who cares about any "intent"? Better stick to what is actually written 
there.

> Just for the sake of clarity, you might consider defining a separate
> signal for integer overflow and divide by zero.
>

The signal function requires an "int" parameter, that could give a lot 
of information about the exact location of the overflow, type of the 
required result, line and file used, whatever.

> (I'm curious to see how you'll manage to interpret this as an insult.
> For the record, it is not intended that way.)
>

How cute Thompson, how cute.

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

#98970

jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 11/12/2016 à 21:09, Keith Thompson a écrit :

jacob, some or all of your articles have this header line:

Content-Type: text/plain; charset=windows-1252; format=flowed

The system I use doesn't handle that correctly, causing the words "à"
and "écrit" to be displayed incorrectly.  Is there any way you can
configure your newsreader to post using UTF-8?

>> jacobnavia <jacob@jacob.remcomp.fr> writes:
[...]
>>> In any case I will modify lcc-win to generate SIGFPE instead of
>>> branching to an ad-hoc routine.
>>
>> Sure, but the FPE in SIGFPE stands for "floating point exception".
>
> Who knows?
>
> It could be Final Point before Exit, Full Program Error, Freak Problem 
> Encountered, even False Prejudices lead to Errors, isn't it?
>
> :-)

No, I'm reasonably sure it stands for floating-point exception.  But my
conclusions based on that were incorrect.

Quoting the C99 Rationale:

    The signal machinery contains many misnomers: SIGFPE, SIGILL,
    and SIGSEGV have their roots in PDP-11 hardware terminology, but
    the names are too entrenched to change. The occurrence of SIGFPE,
    for instance, does not necessarily indicate a floating-point
    error. A conforming implementation is not required to field
    any hardware interrupts.

And as James Kuyper points out, POSIX allows (but does not require)
SIGFPE to be raised for integer errors.

[...]

>> Just for the sake of clarity, you might consider defining a separate
>> signal for integer overflow and divide by zero.

I withdraw that suggestion.

[...]

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

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

#98874

supercat@casperkitty.com writes:
[...]
> There are many C implementations where it would be impractical to support
> concepts like NaN, infinities, and signed zeroes, but that didn't prevent
> C89 from defining such concepts.  Instead, Annex F classifies them as an
> optional feature.
[...]

It's C99, not C89.

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

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

#98872

David Brown <david.brown@hesbynett.no> writes:
[...]
> By now you must have realised that it is /impossible/ for C to have a 
> standard method of detecting integer overflows (and buffer overruns, 
> though these are new to the thread here).  Please do not continue 
> arguing for them - it cannot and will not happen, and I believe you 
> already know this and understand some of the reasons for that (even if 
> you don't agree with all of the reasons).

I don't know how you reached that conclusion.

Standard C of course does not specify overflow checking.  But leaving
aside the question of whether it's a good idea, either a future C
standard or a C implementation with extensions certainly could.

As proof of concept, I present Ada.  Ada has exceptions as a language
feature, very similar to C++ exceptions.  It also requires arithmetic
operations to be checked, raising an exception if the result is out of
range.  (Ada also has modular types, similar to C unsigned types, with
wraparound semantics.)

For example, you might have:

    declare
        N: Integer := Integer'Last;
    begin
        N := N + 1;
        Put_Line("Overflow not detected");
    exception
        when Constraint_Error =>
            Put_Line("Overflow detected");
    end;

and the program *must* print "Overflow detected" in a conforming
implementation.

Why do you think something similar (perhaps using signals rather than
exceptions?) would be impossible in C?

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

[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