Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #98489 > unrolled thread
| Started by | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| First post | 2016-12-09 13:26 +0100 |
| Last post | 2016-12-13 14:30 -0500 |
| Articles | 20 on this page of 121 — 28 participants |
Back to article view | Back to comp.lang.c
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 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-12-09 19:10 +0100 |
| Message-ID | <o2es0l$sea$1@dont-email.me> |
| In reply to | #98577 |
Le 09/12/2016 à 18:35, David Brown a écrit : > The length of the code coverage tests goe up to > the point that the code can no longer be tested through all paths. This is not true. Suppose we have a setup within the language like this: Any overflow, division by zero, or other mishaps generate a signal. Most CPUs can generate this signal automatically. An interrupt is generated and the code is rerouted to the current handler. Other CPUs have an overflow flag that must be tested, but that is simply a technical detail that can be ignored. It introduces an extra instruction, and a small delay since testing a CPU flag is very fast: no I/O is involved and no memory access is done. Any signal can be ignored by the software, or handled, according to the settings of the signal mechanism. The handler should receive information about the fault, making it possible to log something. A handler can either exit the program, jump to a restart point, or return a maximum value according to the type of the expected result. This adds a common path to ALL calculations, of course. But it can be tested, by supplying specially crafted data to the inputs of the program under test. My objective in this discussion is to present the viewpoint that C could have a standard method of making it easy to cover overflows and buffer overruns. The same arguments that are marshalled against array bounds checking can be mershalled against overflow testing but in both cases the naysayers are wrong. What is important here is to make it easy to avoid this kind of bugs. Note that this doesn't make any addition to the language itself. It is just a standardization of the signal mechanism for covering errors. A lot of input laundering can be avoided if you just assume that all data is ok and setup a recovery schema for the errors you expect. Some people here say that when the overflow has happened it is "too late". This is ridiculous. Error handling must be done, there is no way out of it. Errors will occur and they must be simply accounted for and the software designed in such a way that it responds with logic to bad inputs or electrical failures. People arguing about machine cycles are living in the past. Today's machines are incredible by the standards of just 10 years ago. An ARM 64 bits of today is a super computer of the year 2000... Embedded systems are no longer very small any more.
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2016-12-09 19:18 -0500 |
| Message-ID | <28be9418-2404-45df-bd0a-2cba2aede4cc@verizon.net> |
| In reply to | #98586 |
On 12/09/2016 06:54 PM, Stefan Ram wrote: ... > Here is a recent wording. Reportedly, "the explanation". > > »But shortly after the parachute deployed, > Schiaparelli's IMU [Inertial Measurement Unit] reached > saturation (maximum inertia) --- and the IMU reported at > saturation for longer than the navigation system expected.« > > . »Saturation« is not overflow. It might mean another means > of handling very large values: one does not "wrap around" or > throw exceptions, but replaces them by the largest value > still representable. > > But the wording is quite vague. What is "inertia"? Do they > mean "acceleration"? Wiktionary says: "1. (physics, uncountable or countable) The property of a body that resists any change to its uniform motion; equivalent to its mass." That's consistent with my understanding from my training as a physicist. However, that meaning doesn't fit this context. I agree that "acceleration" would make more sense. > > »When the navigation system got wind of the IMU's wacky > output, it decided that meant the spacecraft had > "an estimated altitude that was negative"«. > > This really sounds strange. There was nothing "wacky", it > sounds as if the IMU was just doing its job and reporting > correct data. And it really sounds like a programming error. > "The acceleration is large for a long time, so we must be > below the ground.", why should this implication be assumed? That depends upon the direction of the acceleration - if it was saturating in the downward direction, reasonable ways of dealing with such data would produce an estimated position that was accelerating downward at the maximum rate the system was capable of measuring.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-09 16:49 -0800 |
| Message-ID | <lnvauswqv3.fsf@kst-u.example.com> |
| In reply to | #98586 |
ram@zedat.fu-berlin.de (Stefan Ram) writes:
> ram@zedat.fu-berlin.de (Stefan Ram) writes:
>>In 2004 clock speeds suddenly stopped to grow. The single-threaded
>>free lunch was over. That's why Microsoft now prefers C++ over C#
>>again.
>
> Here is a recent wording. Reportedly, "the explanation".
>
> »But shortly after the parachute deployed,
> Schiaparelli's IMU [Inertial Measurement Unit] reached
> saturation (maximum inertia) --- and the IMU reported at
> saturation for longer than the navigation system expected.«
>
> . »Saturation« is not overflow. It might mean another means
> of handling very large values: one does not "wrap around" or
> throw exceptions, but replaces them by the largest value
> still representable.
>
> But the wording is quite vague. What is "inertia"? Do they
> mean "acceleration"?
>
> »When the navigation system got wind of the IMU's wacky
> output, it decided that meant the spacecraft had
> "an estimated altitude that was negative"«.
>
> This really sounds strange. There was nothing "wacky", it
> sounds as if the IMU was just doing its job and reporting
> correct data.
It doesn't sound like that to me. The article says that the IMU was
reporting unexpected data; how do you conclude that it was reporting
correct data?
> And it really sounds like a programming error.
I don't think we can conclude that, at least not from the information
we've seen here.
> "The acceleration is large for a long time, so we must be
> below the ground.", why should this implication be assumed?
You're assuming "maximum inertia" means "large acceleration".
I don't think that assumption is justified. The phrase "maximum
inertia" doesn't make much sense (possibly a misinterpretation by
a reporter?), but I'm very hesitant to make *any* assumptions about
what was actually meant.
--
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]
| From | "J. Clarke" <j.clarke.873638@gmail.com> |
|---|---|
| Date | 2016-12-20 20:03 -0500 |
| Message-ID | <MPG.32c39f0ff691ae6898a818@news.eternal-september.org> |
| In reply to | #98639 |
In article <lnvauswqv3.fsf@kst-u.example.com>, kst-u@mib.org says... > > ram@zedat.fu-berlin.de (Stefan Ram) writes: > > ram@zedat.fu-berlin.de (Stefan Ram) writes: > >>In 2004 clock speeds suddenly stopped to grow. The single-threaded > >>free lunch was over. That's why Microsoft now prefers C++ over C# > >>again. > > > > Here is a recent wording. Reportedly, "the explanation". > > > > »But shortly after the parachute deployed, > > Schiaparelli's IMU [Inertial Measurement Unit] reached > > saturation (maximum inertia) --- and the IMU reported at > > saturation for longer than the navigation system expected.« > > > > . »Saturation« is not overflow. It might mean another means > > of handling very large values: one does not "wrap around" or > > throw exceptions, but replaces them by the largest value > > still representable. > > > > But the wording is quite vague. What is "inertia"? Do they > > mean "acceleration"? > > > > »When the navigation system got wind of the IMU's wacky > > output, it decided that meant the spacecraft had > > "an estimated altitude that was negative"«. > > > > This really sounds strange. There was nothing "wacky", it > > sounds as if the IMU was just doing its job and reporting > > correct data. > > It doesn't sound like that to me. The article says that the IMU was > reporting unexpected data; how do you conclude that it was reporting > correct data? > > > And it really sounds like a programming error. > > I don't think we can conclude that, at least not from the information > we've seen here. > > > "The acceleration is large for a long time, so we must be > > below the ground.", why should this implication be assumed? > > You're assuming "maximum inertia" means "large acceleration". > I don't think that assumption is justified. The phrase "maximum > inertia" doesn't make much sense (possibly a misinterpretation by > a reporter?), but I'm very hesitant to make *any* assumptions about > what was actually meant. Google "inertial guidance system". It's a term of art. It doesn't measure "inertia", it measures acceleration and orientation. The "inertial" part comes from the way accelerometers work--a crude design has a ball bearing on a spring and measures acceleration by measuring the deflection of the spring as the whole device is accelerated--it uses the inertia of the ball bearing as reference.
[toc] | [prev] | [next] | [standalone]
| From | <william@wilbur.25thandClement.com> |
|---|---|
| Date | 2016-12-09 22:04 -0800 |
| Message-ID | <kgishd-74f.ln1@wilbur.25thandClement.com> |
| In reply to | #98586 |
jacobnavia <jacob@jacob.remcomp.fr> wrote: > Le 09/12/2016 à 18:35, David Brown a écrit : >> The length of the code coverage tests goe up to >> the point that the code can no longer be tested through all paths. > > This is not true. Suppose we have a setup within the language like this: > > Any overflow, division by zero, or other mishaps generate a signal. Most > CPUs can generate this signal automatically. An interrupt is generated > and the code is rerouted to the current handler. > > Other CPUs have an overflow flag that must be tested, but that is simply > a technical detail that can be ignored. It introduces an extra > instruction, and a small delay since testing a CPU flag is very fast: no > I/O is involved and no memory access is done. > > Any signal can be ignored by the software, or handled, according to the > settings of the signal mechanism. The handler should receive information > about the fault, making it possible to log something. > > A handler can either exit the program, jump to a restart point, or > return a maximum value according to the type of the expected result. > > This adds a common path to ALL calculations, of course. But it can be > tested, by supplying specially crafted data to the inputs of the program > under test. It adds a common path, but because that path is taken at different places in the code, the execution state of the program is different at each point. As Mr. Brown explained, it explodes the cyclomatic complexity of the program, prohibiting comprehensive code testing without manually inspecting each jump and excluding those jumps that cannot happen. In that way you've returned to square 0, with the automatic exception generation having only compounded your problems. IMO, normally the best way to handle overflow-inducing and other garbage inputs is to make algorithms resilient to bad input. Wrap-around behavior, saturation, etc are basic examples. The output may be semantically garbage, but if most of your application is written that way than reasoning about and testing garbage input is made much easier. For example, a function that validates a cryptographic signature doesn't break (or shouldn't break) if it's fed garabage input. Rather, the universe of all possible inputs, valid or invalid, should be constrained to and converge to a binary output: verified or not verified. Things like automatic overflow checks really only make sense if it will simply abort the task. That doesn't prohibit recovery, but it's usually best that you unwind to a process boundary or similar boundary with minimally shared state. In the context of C, creating those boundaries in a fine-grained matter is difficult. And in any event those boundaries are typically functional, not boundaries peculiar to the implementation logic; not unlike the cryptographic function example. For example, to be resilient to out-of-memory conditions, in my C code I rigorously only use data structures like queues and red-black trees that are allocation free (nodes are embedded in object structures). That minimizes the number of places where allocation can fail, and makes it much easier to reach a stable program state that can be reliably and properly unwound when memory becomes scarce. For example, if a new network connection arrives, after allocating the connection object I can insert the connection state into various data structures without worrying that each operation might fail. The only points of failure are the few allocations to create the connection object, not every line of code that modifies a list or tree. (This is not unlike the discipline behind RAII, which is not coincidentally integral to making C++ code exception safe.) Similarly, I try to avoid explicit overflow checking whenever practical. Rather, I focus on ensuring that most code is intrinsically resilient to overflow, and that the consequences of overflow converge to a smaller number of points in the program where explicit error handling can be more safely and more easily added. > My objective in this discussion is to present the viewpoint that C could > have a standard method of making it easy to cover overflows and buffer > overruns. The same arguments that are marshalled against array bounds > checking can be mershalled against overflow testing but in both cases > the naysayers are wrong. > > What is important here is to make it easy to avoid this kind of bugs. Automatic exception generation doesn't avoid bugs. Avoiding bugs requires ensuring that garbage input doesn't result in a violation of expeted state invariants. A jump to an exception handler can have the same disastrous effect as anything else. And signals are an especially poor way to handle this, especially in the absense of closures and other niceties that can isolate recovery logic like we strive to do for functional logic. If you want to avoid a particular consequence, like arithmetic overflow resulting in buffer overflow, that should be addressed directly by compilers inserting instrumention to track and check object boundaries. Nothing in the C language prohibits that. > Note that this doesn't make any addition to the language itself. It is > just a standardization of the signal mechanism for covering errors. > > A lot of input laundering can be avoided if you just assume that all > data is ok and setup a recovery schema for the errors you expect. That's a false dichotomy. I agree that input laundering is a bad idea. But the only alternative isn't to trap overflow in every arithmetic expression. The trick is to design algorithms to be resilient to garbage input, and to put error detection on the output path, preferably in as few places as is practicable. (The need to maintain context when reporting or recovering from an error is often in tension with keeping as few error paths as possible.) FWIW, it's also consonant with Postel's Law: be conservative in what you do, be liberal in what you accept. To Jon Postel that's what robustness looks like in practice. And to my mind it's a principle that scales down to the level of functions and even code blocks. > Some people here say that when the overflow has happened it is "too > late". This is ridiculous. Error handling must be done, there is no way > out of it. Errors will occur and they must be simply accounted for and > the software designed in such a way that it responds with logic to bad > inputs or electrical failures. Right, but it's _how_ you account for them that matters most.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-10 10:59 -0800 |
| Message-ID | <173d674e-cfcd-4aae-a8a8-c97f7fff8b92@googlegroups.com> |
| In reply to | #98666 |
On Saturday, December 10, 2016 at 12:15:14 AM UTC-6, wil...@wilbur.25thandclement.com wrote:
> IMO, normally the best way to handle overflow-inducing and other garbage
> inputs is to make algorithms resilient to bad input. Wrap-around behavior,
> saturation, etc are basic examples. The output may be semantically garbage,
> but if most of your application is written that way than reasoning about and
> testing garbage input is made much easier. For example, a function that
> validates a cryptographic signature doesn't break (or shouldn't break) if
> it's fed garabage input. Rather, the universe of all possible inputs, valid
> or invalid, should be constrained to and converge to a binary output:
> verified or not verified.
Especially in scenarios where one is interested in quickly rejecting things
that don't meet some criteria, a function which can identifies 90% of the
things not meeting such criteria, quickly, but identifies 10% of such things
as "potentially interesting", may be more useful than a slower function which
has no false positives. If no interesting objects would cause overflow, but
some uninteresting objects might, having overflow cause objects to be
arbitrarily regarded as "potentially interesting" or not would be harmless,
provided it doesn't cause any subsequent checks to be bypassed (e.g. given
int maybe_interesting(int x, int y, int z) { return x*y < z; }
int is_interesting(int x, int y, int z) { return (long long)x*y < z; }
some platforms could evaluate the "maybe_interesting" check much faster using
wraparound overflow than would be possible if they had to use long long math,
but a compiler that skipped the multiply in "is_interesting" because it had
already performed an equivalent calculation would cause items to pass a
validation test that they should fail.
> Things like automatic overflow checks really only make sense if it will
> simply abort the task. That doesn't prohibit recovery, but it's usually best
> that you unwind to a process boundary or similar boundary with minimally
> shared state. In the context of C, creating those boundaries in a
> fine-grained matter is difficult. And in any event those boundaries are
> typically functional, not boundaries peculiar to the implementation logic;
> not unlike the cryptographic function example.
Do you see any problem with a per-thread overflow flag? In many cases, if
overflows occur in data paths but not control paths, letting code keep
chugging away with computations that are meaningless but will naturally
end within a reasonable length of time may be a lot simpler than trying
to disrupt program execution. On a system which don't have an overflow
flag but has separate instructions for "add with overflow trap" and
"add without overflow trap" and includes a processor-mode flag to
disable the overflow traps, one could have the first overflow that occurs
simply set the overflow-occurred flag and disable the trap. If disabling
the trap isn't possible, code with lots of overflows might end up running
more slowly than would be ideal, but if overflows don't happen too often
that shouldn't be a problem.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-11 13:22 +0100 |
| Message-ID | <o2jgbu$ih7$1@dont-email.me> |
| In reply to | #98586 |
On 09/12/16 19:10, jacobnavia wrote: > Le 09/12/2016 à 18:35, David Brown a écrit : >> The length of the code coverage tests goe up to >> the point that the code can no longer be tested through all paths. > > > This is not true. Suppose we have a setup within the language like this: > > Any overflow, division by zero, or other mishaps generate a signal. Most > CPUs can generate this signal automatically. An interrupt is generated > and the code is rerouted to the current handler. > > Other CPUs have an overflow flag that must be tested, but that is simply > a technical detail that can be ignored. It introduces an extra > instruction, and a small delay since testing a CPU flag is very fast: no > I/O is involved and no memory access is done. You are missing the point about testing. The issue is not that testing an overflow flag takes time - for the most part, it's just a couple of processor cycles. (I have stated before that I think this is a waste, and I still do - but in the context of software testing there is no problem with wasting a few cycles.) The issue is that the test here is a branch. It is a decision, leading to two possible program flows. If you are drawing a graph of possible control flows, you have another split in the tree. And if you are testing the code /properly/, with full coverage test, you need to run a test through both branches. For full coverage testing, /every/ single instruction must be executed during the test runs. When devising test sequences for a function, you have to include values that will test each possible path in the function. And if you now add extra branches based on overflow checking, you also have to include test sequences that trigger the overflow checks and branches. You need to do that for /every/ possible overflow check. Code that was previously a series of arithmetic operations with no branches is now a web of possibilities, and needs lots of different inputs to test them all. And if the code is written correctly, so that overflow does not happen, you /cannot/ find test cases that trigger these branches - the code is completely untestable. > > Any signal can be ignored by the software, or handled, according to the > settings of the signal mechanism. The handler should receive information > about the fault, making it possible to log something. > > A handler can either exit the program, jump to a restart point, or > return a maximum value according to the type of the expected result. > > This adds a common path to ALL calculations, of course. But it can be > tested, by supplying specially crafted data to the inputs of the program > under test. > > My objective in this discussion is to present the viewpoint that C could > have a standard method of making it easy to cover overflows and buffer > overruns. The same arguments that are marshalled against array bounds > checking can be mershalled against overflow testing but in both cases > the naysayers are wrong. 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). The only thing to discuss is whether it would be a good thing for /particular/ compilers - such as yours - to have overflow checking. And if so, what form should it take? I have pointed out a number of disadvantages of overflow checking, when applied "blindly" to all calculations rather than as specific user-chosen cases. I am fully in favour of adding features that make it easy for a programmer to safely check for overflow (either before an operation, or after it) in a convenient way - when the programmer chooses to do so. I am also fully in favour of static checking and warning about known overflows. It may even be useful for some types of code to have compiler warnings any time the compiler sees a /potential/ overflow - if the compiler has good enough range tracking to minimise false positives. > > What is important here is to make it easy to avoid this kind of bugs. > I agree on that. I just don't think run-time checking of all operations for overflows helps that purpose. > Note that this doesn't make any addition to the language itself. It is > just a standardization of the signal mechanism for covering errors. > > A lot of input laundering can be avoided if you just assume that all > data is ok and setup a recovery schema for the errors you expect. > No - I strongly disagree with that. You cannot fix a problem by working with the bad data and hope you manage to detect some failure afterwards. > Some people here say that when the overflow has happened it is "too > late". This is ridiculous. Error handling must be done, there is no way > out of it. Errors will occur and they must be simply accounted for and > the software designed in such a way that it responds with logic to bad > inputs or electrical failures. When the error has occurred, it is too late to avoid. The best you can do is try to minimise the spread of the damage. The correct path is to do what you can to avoid the error happening - error recovery can be helpful in some cases, but it is very much a secondary concern to error avoidance. > > People arguing about machine cycles are living in the past. Today's > machines are incredible by the standards of just 10 years ago. An ARM 64 > bits of today is a super computer of the year 2000... Embedded systems > are no longer very small any more. > You don't know what you are talking about regarding embedded systems. Like many people, you are making the simple mistake that because we have fast processors in use-cases that previously had slow processors, then all processors are fast. The reality is that we have far more slow processors than we ever have had, because now things that previously had /no/ processors now have the slow processors. And in addition, we are demanding more and more out of these processors - processor cycles are as important as they have ever been in a good many fields of embedded processing. And as noted above, you have totally misunderstood the point about testing - it is not the machine cycles that matter.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-12-11 14:18 +0100 |
| Message-ID | <o2jjl5$tg3$1@dont-email.me> |
| In reply to | #98784 |
There is no point in continuing. You just keep repeating the same nonsense. I give up.
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2016-12-11 06:03 -0800 |
| Message-ID | <604fdfb9-ef94-457a-b769-a304d7f12559@googlegroups.com> |
| In reply to | #98790 |
On Sunday, December 11, 2016 at 3:18:59 PM UTC+2, jacobnavia wrote: > There is no point in continuing. > > You just keep repeating the same nonsense. I give up. You said: "A handler can either exit the program, jump to a restart point, or return a maximum value according to the type of the expected result." If you were not mentioning the last possibility, I'd agree with you and disagree with David. But with last possibility in place what he says sounds right. Of course, saturation option, that he appears to defend is no better. Personally, I don't like integer overflow checks, but for completely different reason - they make integer arithmetic non-associative, and not just mildly non-associative, like floating point aritmetic, but brutally non-associative.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-12-11 15:08 +0100 |
| Message-ID | <o2jmih$7o7$1@dont-email.me> |
| In reply to | #98794 |
Le 11/12/2016 à 15:03, already5chosen@yahoo.com a écrit : > You said: "A handler can either exit the program, jump to a restart point, or > return a maximum value according to the type of the expected result." > > If you were not mentioning the last possibility, I'd agree with you and disagree with David. But with last possibility in place what he says sounds right. It is up to the applications programmer to decide what is best. What I propose gives him the necessary tools to easily implement the choice he/she wants. Note that here there can be no general rules, and that each programmer/applications knows best how to handle overflow in a controlled manner. For you returning a maximul value is not a good idea, because in your applications is not a good idea. Other epeople may think different. The objective of my proposal is to give the programmer the tools necessary to implement what he/she think is the best
[toc] | [prev] | [next] | [standalone]
| From | already5chosen@yahoo.com |
|---|---|
| Date | 2016-12-11 06:20 -0800 |
| Message-ID | <4fe8f782-720a-4471-98c3-828e4245b604@googlegroups.com> |
| In reply to | #98796 |
On Sunday, December 11, 2016 at 4:08:44 PM UTC+2, jacobnavia wrote: > Le 11/12/2016 à 15:03, already5chosen@yahoo.com a écrit : > > You said: "A handler can either exit the program, jump to a restart point, or > > return a maximum value according to the type of the expected result." > > > > If you were not mentioning the last possibility, I'd agree with you and disagree with David. > > But with last possibility in place what he says sounds right. > > > It is up to the applications programmer to decide what is best. What I > propose gives him the necessary tools to easily implement the choice > he/she wants. > > Note that here there can be no general rules, and that each > programmer/applications knows best how to handle overflow in a > controlled manner. > > For you returning a maximul value is not a good idea, because in your > applications is not a good idea. Other epeople may think different. The > objective of my proposal is to give the programmer the tools necessary > to implement what he/she think is the best No, the point is not that for me a saturation is not a good idea. The point is, that if I had chosen saturation, than, unlike when I had chosen log and restart, which is the same for all overflow check points and can be tested with relative ease, I have different outcome at each overflow check point and I have no practical chance to test, what happens in each and every particular case. Another, unrelated point: AFAIR, signals are part of POSIX standard, but not part of C standard. And I like that they are not part of C standard.
[toc] | [prev] | [next] | [standalone]
| From | luser droog <luser.droog@gmail.com> |
|---|---|
| Date | 2016-12-11 07:08 -0800 |
| Message-ID | <ea43383d-f291-4122-be0b-4c4b854039e1@googlegroups.com> |
| In reply to | #98799 |
On Sunday, December 11, 2016 at 8:20:33 AM UTC-6, already...@yahoo.com wrote: > > Another, unrelated point: > AFAIR, signals are part of POSIX standard, but not part of C standard. And I like that they are not part of C standard. I posted a similar mistaken idea recently. C does define the `signal()` function and a few possible signals. POSIX expands this into a more useable framework, but C does describe a little bit.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-11 11:56 -0800 |
| Message-ID | <ln37huutmo.fsf@kst-u.example.com> |
| In reply to | #98799 |
already5chosen@yahoo.com writes:
[...]
> Another, unrelated point:
> AFAIR, signals are part of POSIX standard, but not part of C
> standard. And I like that they are not part of C standard.
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf section 7.14
describes C's standard signal handling.
--
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]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-12-11 21:05 +0100 |
| Message-ID | <o2kbfa$kjk$1@dont-email.me> |
| In reply to | #98873 |
Le 11/12/2016 à 20:56, Keith Thompson a écrit : > already5chosen@yahoo.com writes: > [...] >> Another, unrelated point: >> AFAIR, signals are part of POSIX standard, but not part of C >> standard. And I like that they are not part of C standard. > > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf section 7.14 > describes C's standard signal handling. > Where it is written that overflow generates SIGFPE. Why doesn't any compiler implement that? I did not know about this till today.
[toc] | [prev] | [next] | [standalone]
| From | jameskuyper@verizon.net |
|---|---|
| Date | 2016-12-11 12:57 -0800 |
| Message-ID | <fb6ac84f-475d-459e-b0cd-8da650a46c7e@googlegroups.com> |
| In reply to | #98876 |
On Sunday, December 11, 2016 at 3:05:22 PM UTC-5, jacobnavia wrote: > Le 11/12/2016 à 20:56, Keith Thompson a écrit : > > already5chosen@yahoo.com writes: > > [...] > >> Another, unrelated point: > >> AFAIR, signals are part of POSIX standard, but not part of C > >> standard. And I like that they are not part of C standard. > > > > http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf section 7.14 > > describes C's standard signal handling. > > > > Where it is written that overflow generates SIGFPE. > > Why doesn't any compiler implement that? I did not know about this till > today. 7.14p4: "An implementation need not generate any of these signals, except as a result of explicit calls to the raise function." When C leaves details up to the implementation, I normally go to POSIX for those details, since my code is required to work under POSIX, and is allowed to rely upon support for POSIX. However, I couldn't find any statement in the POSIX standard mandating generation of SIGFPE under any situations. You might want to check with Windows documentation to see if it differs in this regard. POSIX describes SIGFPE more broadly than C, as indicating "Erroneous arithmetic operation.". It adds a sigaction() function that can be used to register a signal handler that will receive a pointer to a siginfo_t struct, one of the members of which is si_code, whose value provides more information about the cause of a signal. For SIGFPE, it defines macros for the following si_code values: FPE_INTDIV: Integer divide by zero. FPE_INTOVF: Integer overflow. FPE_FLTDIV: Floating-point divide by zero. FPE_FLTOVF: Floating-point overflow. FPE_FLTUND: Floating-point underflow. FPE_FLTRES: Floating-point inexact result. FPE_FLTINV: Invalid floating-point operation. FPE_FLTSUB: Subscript out of range. Additional implementation-specific values for si_code are permitted. The si_addr member gives the address of the faulting instruction. Note: it says "For some implementations, the value of si_addr may be inaccurate." - always a useful thing to know. :-( It says "There is very little that a Conforming POSIX.1 Application can do by catching, ignoring, or masking any of the signals SIGILL, SIGTRAP, SIGIOT, SIGEMT, SIGBUS, SIGSEGV, SIGSYS, or SIGFPE. They will generally be generated by the system only in cases of programming errors. While it may be desirable for some robust code (for example, a library routine) to be able to detect and recover from programming errors in other code, these signals are not nearly sufficient for that purpose.". Again - useful to know :-(
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-11 21:26 +0000 |
| Message-ID | <87pokyuphi.fsf@bsb.me.uk> |
| In reply to | #98876 |
jacobnavia <jacob@jacob.remcomp.fr> writes: > Le 11/12/2016 à 20:56, Keith Thompson a écrit : >> already5chosen@yahoo.com writes: >> [...] >>> Another, unrelated point: >>> AFAIR, signals are part of POSIX standard, but not part of C >>> standard. And I like that they are not part of C standard. >> >> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf section 7.14 >> describes C's standard signal handling. >> > > Where it is written that overflow generates SIGFPE. I think is says that the an implementation may rise SIGFPE on overflow, not that is does. > Why doesn't any compiler implement that? I did not know about this > till today. I think quire a few do on various architectures. Some implementations (like gcc) still let you test for overflow because C99 (and later) provides access floating point exception flags, though I think even these are optional. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-11 09:23 -0800 |
| Message-ID | <ef2410a4-d731-4809-9de3-1eda5a76a135@googlegroups.com> |
| In reply to | #98794 |
On Sunday, December 11, 2016 at 8:03:34 AM UTC-6, already... wrote: > Personally, I don't like integer overflow checks, but for completely > different reason - they make integer arithmetic non-associative, and > not just mildly non-associative, like floating point aritmetic, but > brutally non-associative. One of the reasons I prefer latching flag semantics which only require reporting when precision is lost is that integer math can remain associative under such a model. Given a construct like: w=x+y+z; a compiler notices that y and z don't vary within a loop could check whether y+z overflows and, if it doesn't, it could replace the above statement with w=x+yz; While there would be some situations in which the former expression would cause an overflow but the latter would not, in all such cases the overflow caused by adding y would be counteracted by overflow adding z, so the result would end up being correct. In the event that x+y would overflow, a compiler could either branch to a version of the code that checks overflow at each step, or it could use a version of the code which uses a "wrapped" version of yz but inverts the overflow logic (if y+z overflows, then the only situations in which x+y+z would yield an arithmetically-correct answer would be those where x+yz overflows).
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-11 14:01 +0000 |
| Message-ID | <87d1gyzhsd.fsf@bsb.me.uk> |
| In reply to | #98784 |
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? <snip> -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2016-12-11 15:11 +0100 |
| Message-ID | <o2jmnl$7o7$2@dont-email.me> |
| In reply to | #98793 |
Le 11/12/2016 à 15:01, Ben Bacarisse a écrit : > 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? > > <snip> > I proposed just such a method: the signal mechanism. But he just doesn't explain anywhere why that would fail.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2016-12-11 18:57 +0100 |
| Message-ID | <o2k3vc$ahp$1@dont-email.me> |
| In reply to | #98793 |
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. 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. The C standards committee is highly unlikely to pick one method and say /this/ is what will happen for signed overflow - they are much more likely to leave it as undefined behaviour, meaning that /they/ don't pick a single way to handle the situation, but they are quite happy for implementations to pick their own way to define the behaviour. Secondly, it has already been established that while all processors will have some way to detect overflow, many cannot do so efficiently - at least for some of the possible actions that might be desired on overflow. And the C standards do not lightly decide on new standardised behaviour which might impose significant run-time costs on targets that are perfectly good for running C with the existing versions of the standard. "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". 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.
[toc] | [prev] | [next] | [standalone]
Page 2 of 7 — ← Prev page 1 [2] 3 4 5 6 7 Next page →
Back to top | Article view | comp.lang.c
csiph-web