Sunday, February 8, 2015

Digest for comp.lang.c++@googlegroups.com - 9 updates in 5 topics

David Brown <david.brown@hesbynett.no>: Feb 08 03:02PM +0100

On 07/02/15 15:30, Christian Gollwitzer wrote:
 
> Sure there is, e.g.,
> https://gcc.gnu.org/onlinedocs/gcc/Integer-Overflow-Builtins.html
> but still a simple clean standard way is lacking.
 
In most cases, I think checking for overflow after integer operations
would be unnecessary (since you should work with types and values that
won't overflow), or it will be too late (the damage is done by the time
you have detected the error).
 
But I agree that it would sometimes be nice to have a good way of
checking, with some sort of integer types that appear as normal integers
but have overflow detection. For C++, the obvious choice would be to
throw an exception on overflow - but many of the systems for which this
would be useful are embedded systems which often have exceptions
disabled on the compiler.
 
For saturated arithmetic, it would be easier to make a clean solution
that fits well in normal code, as there are no error conditions or
exceptions. There are some complications for optimisation - the
compiler can no longer reduce "a + 1 - 1" to "a". There is a move
towards standardising saturated arithmetic (along with fixed-point
arithmetic) in C:
 
<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf>
<https://gcc.gnu.org/onlinedocs/gcc/Fixed-Point.html>
 
However, there are two major problems so far - in a move designed to
annoy embedded programmers (the ones that need this stuff most) and to
repeat the mistakes of history as closely as possible, the new types are
given names like "_Sat long long" without any specifications of the
exact sizes. Idiocy of the highest level, "justified" by excuses about
different hardware supporting different sizes better.
 
Secondly, you can guarantee that if and when these new types make it
into the C standards, the C++ committee will declare that they are
better implemented as a library of templates that are incompatible with
the C versions, as a method of ensuring that the spread of C++ in
embedded systems is hindered.
"Öö Tiib" <ootiib@hot.ee>: Feb 08 10:22AM -0800

On Sunday, 8 February 2015 16:02:56 UTC+2, David Brown wrote:
> would be unnecessary (since you should work with types and values that
> won't overflow), or it will be too late (the damage is done by the time
> you have detected the error).
 
On lot of cases closing the application with error signal is good enough
because there is (at least one of) programming errors like:
* collecting the input data for calculating the value is defective.
* algorithm that calculates the value is defective.
* data type is chosen that can not contain the value.
 
> arithmetic) in C:
 
> <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf>
> <https://gcc.gnu.org/onlinedocs/gcc/Fixed-Point.html>
 
Saturated arithmetic is useful in situations where "unavailable",
"out of lower limit" or "out of higher limit" are valid and expected
values. For example because of noise or possible destruction of
sensory hardware or communication channels are expected and handled.
These values are already usually present with floating point types ...
with integers we have to use things like Boost.Optional.
 
> given names like "_Sat long long" without any specifications of the
> exact sizes. Idiocy of the highest level, "justified" by excuses about
> different hardware supporting different sizes better.
 
Programmer needs most often value that can be only within certain limits.
For example something can (by laws of nature) take from 150 000
nanoseconds to 30 000 000 nanoseconds with around 2 000 000 most common. Everything outside of it is indicating defect in executing or measuring hardware or software.
 
> better implemented as a library of templates that are incompatible with
> the C versions, as a method of ensuring that the spread of C++ in
> embedded systems is hindered.
 
Major problem is that those solutions solve next to nothing. For example
information that automatic passenger counting system does overflow 'long'
with counted passengers is uninteresting because sane limits to that value
are way smaller than 'LONG_MAX'. It is indeed possible that for
something 2 147 483 647 is useful limit ... but for me it is rather hard
to imagine what it is.
David Brown <david.brown@hesbynett.no>: Feb 08 08:35PM +0100

On 08/02/15 19:22, 嘱 Tiib wrote:
> * collecting the input data for calculating the value is defective.
> * algorithm that calculates the value is defective.
> * data type is chosen that can not contain the value.
 
Many of the systems where you are dealing with saturated arithmetic or
overflow detection are embedded systems where you have limited resources
or are aiming for maximal speed. A DSP application might be carefully
tuned to do 4 multiply-accumulate operations per clock cycle - you can't
just add some extra code for range checking as you might on a desktop
application. Similarly, you might need to stick to 16-bit integers -
you can't simply step up to 32-bit or floating point arithmetic to avoid
overflows.
 
In such systems, even though you may be correct about likely causes of
overflow, closing the application is seldom a good plan.
 
And in high-performance computing, you will often want to use a "sticky"
overflow flag - you do all the calculations with the assumption that
there are no problems (at maximum speed), then after finishing a batch
you check the overflow flag and if necessary, through away the whole batch.
 
> sensory hardware or communication channels are expected and handled.
> These values are already usually present with floating point types ...
> with integers we have to use things like Boost.Optional.
 
Saturated arithmetic is very common in a lot of physical modelling and
control applications - that's why it is often supported in hardware in
DSP's and microcontrollers. Of course, it would often be useful to have
the limit as a programmable value rather than the hard limit of the type.
 
"Öö Tiib" <ootiib@hot.ee>: Feb 08 01:49PM -0800

On Sunday, 8 February 2015 20:56:17 UTC+2, Stefan Ram wrote:
> increment_passenger_count();
 
> Both versions are perfectly fine as long as the limit is clearly
> documented.
 
In what sense of perfection? Neither of the limits feels correct;
both feel way too odd. I either do not understand the purpose or
the documentation is defective or the requirements are gathered by
idiot. It would be irresponsible to code it away blindly and not to
consult rest of the team that is involved.
 
> the rocket explode.
 
> So, when the client does not react properly, even detection of
> overflow by the routine does not help.
 
If the software does not handle the situations then it does
not matter if it is saturated overflow, exception thrown or usual
undefined behavior. It will not work. You can have three or more
alternative systems that vote for mutual decision and you can keep
backup system warm for each that takes over on case of failure but
if all of those do not handle the situation then nothing helps.
 
> be documented in a prominent place. And there, Java has an
> edge with JavaDoc, because it makes cleare where to write
> the documentation.
 
What edge? C++ community has had Doxygen and AFAIK both it and
JavaDoc were released 1997. The first document generator was
perhaps by Donald Knuth in 1981 ... nothing to do with Java.
 
Documentation is helpful but it does not write software.
Java has edge that Java's exception specifications work.
In C++ it is too easy to forget about exceptions since language
is unhelpful about those.
Martijn Lievaart <m@rtij.nl.invlalid>: Feb 08 09:20PM +0100

On Fri, 30 Jan 2015 16:29:33 +0000, Scott Lurndal wrote:
 
> In fact, ICMP packets are almost universally blocked at the edge ingress
> gateway, for very good reasons. The yahoo servers are a notable
> exception.
 
In fact, people are starting to see blocking ping is a rather useless
measure when you reply to tcp/syn on port 80. Those 'very good reasons'
may have been good 20 years ago, but are just historic artifacts at best
today.
 
M4
 
P.S. My current preferences for Internet facing hosts.
 
Allow icmp-host-unreachable-fragmentation-needed-but-packet-to-big
(that's not a preference, that is a must).
 
Allow icmp-echo and reply.
 
Block all other ICMP.
Martijn Lievaart <m@rtij.nl.invlalid>: Feb 08 09:21PM +0100

On Sat, 31 Jan 2015 07:53:16 +0000, Jorgen Grahn wrote:
 
> Not to mention there's a whole bunch of ICMP messages apart from Echo
> Request (ping). Some of them are vital if you want IPv4 to work
> properly, so I don't think anyone blocks the whole ICMP protocol.
 
Most people get it right today. The firewall software of today silently
does the right thing, it's actually hard today to do it wrong.
 
Not that people don't try....
 
M4
Martijn Lievaart <m@rtij.nl.invlalid>: Feb 08 09:23PM +0100

On Thu, 05 Feb 2015 04:00:03 -0500, DSF wrote:
 
> template". It only became obvious since I found this error.
 
> How did I find it? Through many sleepless nights and blurry-eyed
> days. :o)
 
Thanks for the extensive followup!
 
M4
Martijn Lievaart <m@rtij.nl.invlalid>: Feb 08 09:11PM +0100

On Thu, 29 Jan 2015 21:57:34 +0000, Jorgen Grahn wrote:
 
> But the Raspberry Pi, Beaglebone and so on that you mention -- those are
> really on the "big and general-purpose" end of the scale.
 
<plug> and the Arietta G25, it's awesome! </plug>
 
M4
ram@zedat.fu-berlin.de (Stefan Ram): Feb 08 06:56PM

>are way smaller than 'LONG_MAX'. It is indeed possible that for
>something 2 147 483 647 is useful limit ... but for me it is rather hard
>to imagine what it is.
 
When you write a counting routine, you just need to specify its limits
in the contract, whatever those limits might be: Version 1:
 
/* This routine must not be called more often then 10 times */
increment_passenger_count();
 
Version 2:
 
/* This routine must not be called more often then 10000000000000000000000 times */
increment_passenger_count();
 
Both versions are perfectly fine as long as the limit is clearly
documented.
 
The Ariane 4 had a subroutine with a velocity limitation. It was
documented, too, but kind of »hidden« in the middle of a multi-page
document. The oversight of this limitation than lead to the
explosion of the Ariane 5 when that routine was re-used.
 
This was not even UB. Instead the routine even /did/ detect
the overflow and throw an exception IIRC. Ie., it was all
»super clean«. Only problem was that there was no proper
handler for that exception, so the exception reached the
general top-level exception handler which terminated
the process. In this case, however, ironically, everything
would have been fine, if the exception would just have been
ignored or not been created in the first place. In a sense,
it was the well-intentioned overflow-detection that made
the rocket explode.
 
So, when the client does not react properly, even detection of
overflow by the routine does not help.
 
Lesson learned was that limitations of routines needs to
be documented in a prominent place. And there, Java has an
edge with JavaDoc, because it makes cleare where to write
the documentation.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.lang.c+++unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)