Integer arithmetic when overflow exists

[Öö Tiib]

In my experience bugs which appear in release, but not in debug, are very
rare. Even if they are much harder to fix, it does not outweigh the
convenience of solving the rest 99.9% of problems with the debug build.

Yes. Conditions where differences (like integer overflow that is itself
rare in good code) causes issue are rare. So everybody seem to use "debug"
build for solving lot of issues. That is why I did not understand why
David Brown called having "debug" builds as "common mistake".

All tests must of course pass with the final release build.

Yes. Some performance hungry modules (nothing to talk of fully integrated
end products) may even be time consuming to test as "debug" build because
of low performance of those.

YMMV, of course. I have a habit of littering the code with debug-mode
asserts. As a result, the program runs 10 times slower in debug mode, but
often the reported bug triggers some assert much earlier in the code, and
then it becomes *much* easier to fix.

I trust that it is good practice. I have noticed that slowness of debug
builds is mostly because of less optimizations, usage of various
instrumented things (like checked iterators and memory managers) and
more log/trace output. The asserts, even if used over line are commonly
not causing very major performance differences because the checks are
usually simple.

 

[Tobias Müller]

That's a quite unfriendly comment, I think.

Of the insidious kind.

That was certainly not meant to be unfriendly. I was just pointing out that
I don't like your discussion style and your disrespect of other meanings
(just count the word fallacy in your posts). A possible employer reading
this NG might feel the same.
If you
Just be aware that many readers here don't know you personally as it was
maybe the case in the good old times before the "influx of small trolls".
If I did I would maybe thing differently.

Oh!

Well, right above (see comment) you are saying very unfriendly things,
and since it has nothing to do with anything technical it can only be
purely personal -- you know, ad hominem, which is a known fallacy.

Sure, it is personal, but not meant to be unfriendly, just honest.

But it's only a self-contradiction (another fallacy) if you are aiming
for employment, he he.

I'm not and I actually doubt that many possible employers read this NG.

In Norwegian mythology the trolls don't survive exposure to daylight.

Just sayin'. ;-)

Still living, but I the current weather can barely be called daylight, so I
probably won't make you happy today.

Just stayin'. ;-)

Tobi

 

[Öö Tiib]

I can see I've been explaining myself rather badly here. I'll try again
from a different angle. First note that this applies mainly to small
teams or single developers, not to larger groups with more rigorous
development and test procedures, and it applies mainly to what you might
call "windows-style" tools (big all-in-one IDE's, wizards, etc.) rather
than "unix-style" (makefiles, mix-and-match editors, compilers,
debuggers, etc., to suite the task).

For me those are actually same thing. The "windows style" tools are the
very same "unix-style" easily automatically testable modules integrated
under relatively thin GUI layer. Simplest is let to write GUI in Python.
It can be later translated to C++ or turned into web service and GUI can
be switched to HTML + Javascript.

A lot of development tools, when you click on "New project", set up two
configurations - a "release" and a "debug". The "release" configuration
has higher optimisation and debug information disabled, and the "debug"
configuration has low (or no) optimisation and debug information
enabled. Many developers use such a setup with minimal modifications,
and they do their development, debugging and testing using the "debug"
configuration. Then they build with "release", and do some basic "check
that it works" testing.

It is fairly obvious the dangers that this can involve.

Key obvious mistake I see here is that expressed illusion that debugging
and development and "basic check that it works" can somehow replace
testing.

That small team should have at least one of:
* 1000 fans eager to try out and report issues in the alpha releases
* full coverage automatic tests
* dedicated testers. At least one full time tester per 4 full time
developers.

Otherwise it will be crap what they make. The whole "release"/"debug"
question seems orthogonal to the actual issue here.

 

[Alf P. Steinbach]

That was certainly not meant to be unfriendly. I was just pointing out that
I don't like your discussion style and your disrespect of other meanings
(just count the word fallacy in your posts).

So, in your opinion anyone who responds to a stream of fallacies by
pointing them out, is disrepectful. The more fallacies the person points
out, the worse is that person. Perhaps even unemployable. One should
respect the personal attacks -- such as yours. Yeah.

Plink.

- Alf

 

[Alf P. Steinbach]

Indeed.

In your one posting in the debate you offered a number of unverifiable
but not implausible assertions, plus one that was easy to dismiss as
certainly not being correct, that of C++11 having gained decimal
integers, in the context of integer representation "Not to mention the
decimal stuff added to C11."

Honest people do not engage in pure personal attacks when they lose the
technical debate and are exposed as employing fantasy facts, as you are
now doing.

Plink.

 

[Alf P. Steinbach]

Indeed. But like it or not, that's as good as testing often gets in
most software development (professional and amateur).

I'm happy to report that Google Test, a unit test framework, now
supports "death tests", testing that something crashes as it should.

Maybe it did that years ago also but just nobody knew about it?

Anyway, then I had to create my own framework for personal work (a combo
of Python and C++) in order to test asserts and such. Others did the
same but some favored redefining their asserts to throw exceptions, for
easier but not so reliable death testing. Now I just installed Google
Test, and while it's a quite old fashioned and imperfect in places, what
with named initializer functions (I say this only once!) and Java-like
singletons and non-prefixed macros and such, very much in the "C++ as
power-C" tradition of Google, it does Get the Job Done.


Cheers,

- Alf

 

[Ian Collins]

I'm happy to report that Google Test, a unit test framework, now
supports "death tests", testing that something crashes as it should.

Maybe it did that years ago also but just nobody knew about it?

Anyway, then I had to create my own framework for personal work (a combo
of Python and C++) in order to test asserts and such. Others did the
same but some favored redefining their asserts to throw exceptions, for
easier but not so reliable death testing.

assert is a macro, so I just use an alternative definition that throws
and exception when testing. Easy!

 

[Jorgen Grahn]

Op 14-Oct-13 18:57, Paavo Helde schreef:
....
Debugging code compiled with aggressive optimizations can be very
confusing and even misleading, especially for less experienced
programmers. If the problem also reproduces with a debug build I see no
reason why one would go through the trouble of insisting on using a
release build for debugging.

....

Nitpick perhaps, but ...
You (and others upthread I think) write "debugging" but mean "running
a symbolic debugger". Debugging as an activity is something you can
do in many different ways, and most of those ways don't involve a
symbolic debugger, or have problems with compilers optimizing things.

(No disrespect to symbolic debuggers or their users intended.)

/Jorgen

 

[Öö Tiib]

Indeed. But like it or not, that's as good as testing often gets in
most software development (professional and amateur).

That results with the piles of low quality software (some professional
and most amateur-made) floating around. I don't know who likes it; all
seem to not like it. Doing wrongly because lot of people do it wrongly
is fallacious logic called "argumentum ad populum". If you want to be
lamb then indeed run with sheep, what can I do?

I don't disagree at all, except that the emphasis is on "should have".
I think a very large proportion of software is released with very little
serious testing - and given that, avoiding different settings for
release and development reduces the risk of some classes of bugs.

I propose that better choice is to not release it. Releases of low quality
software are among best ways to turn away potential users. When you have
too lot of users then better publicly accuse them in stupidity, that is
bit cheaper way to reduce their amounts.

If you do not release then potential user is unhappy that you lied that
you can make it. If you are publicly sorry about it then people may
understand. If you didn't make it but released anyway then user is
additionally unhappy that her time was wasted to find that out by trying
out your broken crap. Sheep who release their sheep droppings give ideas
and users (and so the very piles of money) to wolves like Apple.

I also think that even with good test procedures, having just the one
configuration helps catch bugs earlier - it is always best to find them
in development rather that testing.

How so? You give away all the useful features of debug version (useful
debuggers that can match code and data with binary, instrumented memory
management, buffer overflow checking, asserts, checked iterators etc)
and hope to find problems early? Totally on the contrary I'm afraid.

With majority of issues the difference is that "debug" blows up clearly
indicating the issue why while "release" becomes silently unstable and
crazy.

On very little amount of issues the "debug" fails to detect some simple
problems. Solution to current integer overflow has been proposed in this
very thread: -ftrapv in "debug" and the issue is found clearly with
"debug". So I'm actually happy that Alf started such educating flame
war.

But it's not a major issue - it's a help, but there are far more
important measures to reduce errors (such as enabling good warnings, or
perhaps using something like pc-lint or domain-specific checkers -
enabling warnings would let gcc inform Alf of the risks in his overflow
code).

Static code analysis can't replace testing either. It can reduce length
(and so cost) of test-fix-test-fix work. If there won't be testing then
sorry, better rethink that strategy.

Only full coverage automatic tests (of automatically testable modules)
can reduce human testing. It is paying back in long run. Anyway you
need "debug" version to measure coverage, no profiler I've seen can
measure it accurately by using "release".

 

[Öö Tiib]

...

Nitpick perhaps, but ...
You (and others upthread I think) write "debugging" but mean "running
a symbolic debugger". Debugging as an activity is something you can
do in many different ways, and most of those ways don't involve a
symbolic debugger, or have problems with compilers optimizing things.

Yes. I did argue with idea that only one configuration should be used when
actually more than two configurations are commonly used by successful.

There are variety of tools that involve matching source code lines, source
code structures and variables to run-time behavior. Some may be not
for debugging draw diagrams, aid in refactoring, measure code coverage
etc. Very few of those work passably with modern heavily optimized binary.

(No disrespect to symbolic debuggers or their users intended.)

I got it. The term "debugging" has lost its clarity in English and lot
of it means various tests. I'm not actually English speaker.

What I meant with "debugging" was "not testing". Programmers run lot of
tests too but I meant the activity when there is issue found, conditions
reproducible and programmer now has to find and to eliminate the bug in
code base. IOW to "debug" it.

Experienced can do it often by looking at code (debugging in mind) but
see lot of stack overflow C++ questions: copy paste some code (often
partial, irrelevant or that does not expose the issue) and "why it does
not work?". Symbolic debugger is best tool for those guys.

 

[Rosario1903]

So far, it seems that the strongest point for putting the wrap-over into
the standard is that otherwise a bunch of x86 and other assembler
programmers might have some misconceptions about C++.

it is not wrapp aroudn to put in the standard is overflwo flag

Why should we care
so much about assembler programmers?

yes why care c++s?
.....

No problem, I think gcc won't optimize in debug mode and will catch my UB
in the debug mode (i am regularly running the tests in debug mode, in
addition to the automatic release mode testing). .....
All tests are run after each commit, in the continous integration builds.
No problem here, other than that we don't yet have 100% code coverage in
tests. So I will probably switch off this flag in the stable branch
(actually delivered to customers) in order to avoid false positives at
customer site.

in assembly, if it would be possible some overflow, i would detect
it...
i don't know how big programmers do it etc