Assertions in principle

[jeffc226]

This might be less of a design issue than a C++ language issue per se,
but I have a problem with assertions. I mean, they work, of course.
But there's something I'm uncomfortable with that's never been
explained to my satisfaction.

I recently read this explanation. "There is an effective litmus test
to differentiate the cases in which you need to use assert and when
you need to use genuine error checking: you use error checking for
things that could happen, even very improbably. You use assert only
for things that you truly believe cannot possibly happen under any
circumstances. An assertion that fails always signals a design or a
programmer error - not a user error."

OK I can buy that. But what keeps going unmentioned is that
assertions are debug-mode only. Well, it's mentioned, but usually in
the context of increased efficiency at runtime since they're compiled
out.

I understand the idea that even the things you take for granted as
being true might not be true. Software has bugs, and today almost
every decent sized application uses third party supplements and
interfaces. Interfaces change, code versions change, versions of code
get mismatched. New permutations of hardware and software mixes are
constantly occurring.

And where does all this manifest itself? At the developer's box?
Sometimes. But the majority of time in a modern large application
with many users, it's very likely for a bug to show itself in the
field. And that is exactly where the assertion does not exist. Even
most test departments use release code, not debug code. What exactly
is the point of checking for "impossible " error situations only at the
developer's desk? That just doesn't make sense to me. The code gets
executed far too much outside of that environment, in ways the
original developer might not even have imagined, for that to be good
enough.

I would go so far as to say the original developer's box is precisely
where assertions are NOT needed, because that's the only place where a
debugger is available. (I see how they can come in handy, and force
you to resist making assumptions.) But you really need assertions (or
something) in environments where the debugger isn't available.

[Alf P. Steinbach]

* Greg Herlihy:

On 3/5/07 9:14 AM, in article 55************* @mid.individual .net, "Alf P.
Steinbach" <al***@start.no wrote:

>* Greg Herlihy:

>>I think that a better compiler would have the asserts turned off. The
point here is that a more thoroughly-tested compiler would see no
benefit from shipping with its asserts enabled. Shipping a program
with asserts enabled can only mean that the software has not been
adequately tested. So in this case, anyone who uses g++ is
effectively participates in the product's QA.

And while such an arrangement may be reasonable for a free product
like g++, it probably won't fly for those who program with a $500 C++
compiler.

As they say, that's not even wrong. $500-compilers do produce Internal
Compiler Errors. And g++'s free support is superior to e.g. Microsoft's
non-existent free support.

I see you disagree with several points that are not in my post, but it would
be interesting to know whether you take issue with anything that I actually
wrote. After all, I offered no opinion whether a $500 compiler crashes any
less often than a free C++ compiler - only that some who spends $500 on a
compiler (such as the Intel compiler) but be expecting something different
than would expect from a free compiler.

Insights into people's actual expectations are probably better discussed
in an ESP or psychology group.
[snip]

I have used commercial programs - but I never remember using a shipping
version of a commercial program that had its asserts enabled. And until
programmers start writing software that does not fail often enough, I doubt
I'll be seeing asserts in shipping commercial software anytime soon.

The commercial version of MSVC is one commercial compiler (in the price
range you mention, the 7.1 version with documentation was about 13.000
NKr) that ships with asserts enabled -- it ICEs regularly.

For that matter, even Windows Explorer, the Windows GUI, ships with
asserts, or an equivalent mechanism, enabled, doing a report-and-restart
when it crashes.

For an honest and competent developer it's lunacy to turn off asserts.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Gavin Deane]

On 6 Mar, 07:27, Greg Herlihy <gre...@pacbell .netwrote:

Who would prefer to have a PlayStation II
game abort because of a failed assert? How likely is it that debugging the
assert failure would be more popular than playing the games itself?

You're still missing the point of assert. assert is used to identify
bugs. You do not reduce the number of bugs or the probability that a
user will encounter one just by removing your bug identification tool.
What you change is the outcome *if* a bug is encountered. You seem to
be suggesting:

Option 1: Leave bug identification in and annoy users when it
identifies one.
Option 2: Take bug identification out so that users can continue to
use the software even in the presence of bugs.

That's nonsense. The choice is:

Option 1: Leave bug identification in.
1a. If no bug is encountered, the software continues to work.
1b. If a bug is encountered, the user is made aware that their
software does not work and its behaviour can not be relied upon in to
do what they were trying to do.

Option 2: Take bug identification out.
2a. If no bug is encountered, the software continues to work.
2.b If a bug is encountered, the behaviour of the software is not
reliable but the user may have no way of knowing that and may be
relying on it anyway. That's bad.

When no bug is encountered, whether bug identification is still in
*makes no difference* to the user. The only difference is what happens
when a bug is encountered. Continuing to use the software in the way
they were *is not an option* for the user but if they are not informed
of the bug that might be exactly what they try and do. And the problem
may not manifest itself until some way down the line in whatever
process the use of that software was part of.

That is the advantage of leaving bug identification in. If you decide
that that advantage is appropriate, you *might* also decide that, at
the same time as telling the user that their software is broken, you
will provide information that they could feed back to you to help
diagnose the problem (or you might decide that simply identifying that
a bug has been encountered is sufficient). Having made all those
design decisions, you might find that assert provides the
implementation of bug identification that you need. Or you might need
to implement something else.

Gavin Deane

[Roland Pibinger]

On Tue, 06 Mar 2007 09:31:56 +0100, "Alf P. Steinbach" wrote:

>The commercial version of MSVC is one commercial compiler (in the price
range you mention, the 7.1 version with documentation was about 13.000
NKr) that ships with asserts enabled -- it ICEs regularly.

But ICE doesn't mean that all asserts are turned on in production
code.

>For that matter, even Windows Explorer, the Windows GUI, ships with
asserts, or an equivalent mechanism, enabled, doing a report-and-restart
when it crashes.

When it crashes! Again, that doesn't mean at all that asserts are
turned on in production code. Quite the contrary! Probably a signal
handler for SIGSEV is invoked. BTW, people interested in Microsoft's
usage of assert should read Steve Maguire's classic book 'Writing
Solid Code':
http://www.amazon.com/Writing-Solid-.../dp/1556155514

>For an honest and competent developer it's lunacy to turn off asserts.

LoL!

[Alf P. Steinbach]

* Roland Pibinger:

On Tue, 06 Mar 2007 09:31:56 +0100, "Alf P. Steinbach" wrote:

>The commercial version of MSVC is one commercial compiler (in the price
range you mention, the 7.1 version with documentation was about 13.000
NKr) that ships with asserts enabled -- it ICEs regularly.

But ICE doesn't mean that all asserts are turned on in production
code.

Right, it doesn't mean that the moon is gouda-cheese, but so what?

An ICE (Internal Compiler Error) is an assert.

For optimization some small parts of the code will instead (typically)
be very intensively tested. However, that is impractical for the
complete application. The asserts that are left on also serve to
hopefully catch invalid state caused by any remaining errors in the
intensively tested code.

>For that matter, even Windows Explorer, the Windows GUI, ships with
asserts, or an equivalent mechanism, enabled, doing a report-and-restart
when it crashes.

When it crashes! Again, that doesn't mean at all that asserts are
turned on in production code. Quite the contrary! Probably a signal
handler for SIGSEV is invoked.

Probably not, unless you're talking of a *nix version of Windows Explorer.

BTW, people interested in Microsoft's
usage of assert should read Steve Maguire's classic book 'Writing
Solid Code':
http://www.amazon.com/Writing-Solid-.../dp/1556155514

>For an honest and competent developer it's lunacy to turn off asserts.

LoL!

Hm.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Old Wolf]

On Mar 6, 9:31 pm, "Alf P. Steinbach" <[e-mail] rote:

For that matter, even Windows Explorer, the Windows GUI, ships with
asserts, or an equivalent mechanism, enabled, doing a report-and-restart
when it crashes.

That's a separate background task that detects segfaults and then
takes over.

[Adrian Hawryluk]

Chris Theis wrote:

>
"Alan Johnson" <aw***@yahoo.co mwrote in message
news:tI******** *************** *******@comcast .com...

But how do you actually "assert" that the code is correct? Running your
own tests, extended beta-testing etc. etc. is certainly a mandatory
thing, but it does not at all guarantee correct code in the sense, that
it will act correctly under each and every aspect that might come along.

You could always try and build a theorem prover. In university, I was
involved in building one for the Eiffel language. It is pretty
intriguing stuff. Too bad it is far from going main stream.

IMO the sailing analogy hits the point. Staying with the analogies -
even those competing in the TDF wear helmets for safety, but not all of
them. Of course one would disable asserts in time critical parts in the
production code, but this is not necessarily useful throughout the whole
program. Especially when implementing complex parser/compiler systems
they come in extremely handy in code that is already shipped to customers.

This makes sense, but an assert in this case is not very useful when a
customer calls and says, "your programme (he's a Canadian, eh? :D) went
down and it is reporting some gibberish on the screen." Even if s/he
gives you the info on the screen, it may not be enough, and usually they
hit ok and don't write down anything.

A good production assert (which I would really like) would be to dump
the call stack in a manner that I could read it (dumped to a file). And
no, I've not have had a good experience with core dumps as they are not
available on all compiled systems, and the ones I have had them on are
junk as I can not find any documentation as to how to read em.

An even better one would describe the state of the system (really
difficult to implement, though if core dumps were a standard and worked
as they ought, I'm sure it would be suitable).
I've even see Windoze apps display stack dumps, but no docs in how to
use them.

What is really needed is a standard way of representing the state of a
failed system.
Adrian

[Adrian Hawryluk]

Roland Pibinger wrote:

On 2 Mar 2007 08:08:55 -0800, "jeffc226@...co m" wrote:
This is a very good explanation (source?). assert is for finding bugs
in a program. Input validation, error handling, ... is not done with
asserts. Therefore asserts should never be used in production
(release) code.

Sure

>OK I can buy that. But what keeps going unmentioned is that
assertions are debug-mode only. Well, it's mentioned, but usually in
the context of increased efficiency at runtime since they're compiled
out.

Yes, that's their purpose. Actually, assert should be renamed to
debug_assert.

Sure

>I understand the idea that even the things you take for granted as
being true might not be true. Software has bugs, and today almost
every decent sized application uses third party supplements and
interfaces. Interfaces change, code versions change, versions of code
get mismatched. New permutations of hardware and software mixes are
constantly occurring.

Well tested software has so few bugs that is can be smoothly used by
the client. And what have interface changes and mismatched code to do
with asserts?

Sure, if you put your foot down and tell your manager that "I don't care
if the deadline is tomorrow, it ain't ready!" ;)

Library interface changes, if done incorrectly could cause a whole whack
of problems. Input interfaces may only be narrowed, never widened.
Output interfaces may be widened, never narrowed. You tell that to some
programmers and they will stare at you with a blank look, or worse argue
with you. :)

>And where does all this manifest itself? At the developer's box?
Sometimes. But the majority of time in a modern large application
with many users, it's very likely for a bug to show itself in the
field. And that is exactly where the assertion does not exist.

The bug crashes the program, assert calls abort which crashes the
program. So?

So, you keep the programme from corrupting persistent data causing a
cascade of other problems afterwards.

>Even most test departments use release code, not debug code.

Of course, they test the program that is shipped, not a debug version.

Of course.

>What exactly
is the point of checking for "impossible " error situations only at the
developer's desk?

To find bugs in the program. Nothing more, nothing less. Together with
unit tests, functional tests, integration tests, ... it is one step to
produce a deployable program. Actually, assert can be seen as
automated test built into code.

Definitely.

>That just doesn't make sense to me. The code gets
executed far too much outside of that environment, in ways the
original developer might not even have imagined, for that to be good
enough.

That just doesn't make sense to me. You write code that consists of
(public) interfaces to encapsulated code. You validate the input.
Since software is (should be) reusable it's no problem (even desired)
that it is used in ways 'the original developer might not even have
imagined'. You check the input as part of the contract between your
code and the caller. When the input is within the allowd range your
code must work.

Given the set of valid inputs, your system (since you defined the valid
inputs) should work always.

>I would go so far as to say the original developer's box is precisely
where assertions are NOT needed, because that's the only place where a
debugger is available. (I see how they can come in handy, and force
you to resist making assumptions.) But you really need assertions (or
something) in environments where the debugger isn't available.

Using a debugger is the most inefficient activity in programming. It
is entirely resistant to automation. asserts help you avoid using the
debugger.

Yeah, well that goes to design and the human factor. If the computer
did everything for us, what would we do? ;)

The debugger, though resistant to automation, is still required, even
when you use asserts since that is the only way to get access to the
system state.

I just wrote the other day a parser with many asserts in it, but trying
to find why the assert failed wouldn't have been possible without the
debugger (and a bunch of debugging classes and functions that I wrote).
Did I tell you I *hate* pointers? :(

BTW, have you ever seen a program/library that prints/displays asserts
in production/release mode? I would be very reluctant to use that
program because the code quality most probably is very poor.

If the programme or library displays the failed asserts in
"production/release mode", I would be concerned. If they could be
redirected to a file which I could look at postmortem, I would be happy
as I would be able to talk to that company and resolve the issue in a
more timely fashion.

Asserts are good, bad and ugly part of programming. I can't wait till a
theorem prover can be properly build.

Man, this thread spans 4 days. Its interesting, but I'm reading the
rest of it later.
Adrian

[Adrian Hawryluk]

Greg Herlihy wrote:

On Mar 4, 1:33 pm, Kai-Uwe Bux <jkherci...@gmx .netwrote:

...Leaving asserts
enabled in a shipping program has the completely opposite effect - the
asserts make the shipping program less reliable (that is, it is more
prone to fail), and all but eliminates the chances that the developers
will have tested the software before it shipped - and not just rely
on those who use the software to make up the difference.

If the asserts are correct then the programme will not fail. If they
are incorrect, then someone has forgotten something (we are only human
after all) and it should be checked. Having this information may prove
to be invaluable as there are times that something _could_ have been
forgotten. Yes, it shouldn't have happened, but it did. Now the
customer would want to know how long before it is fixed. If you have no
starting point, you may be a long while making the customer even more
frustrated. (Man I could tell you stories...)
Adrian

--
=============== =============== =============== ===========
Adrian Hawryluk BSc. Computer Science
--------------------------------------------------------
Specialising in: OOD Methodologies in UML
OOP Methodologies in C, C++ and more
RT Embedded Programming
__------------------------------------------------__
-----[blog: http://adrians-musings.blogspot.com/]-----
'------------------------------------------------------'
This content is licensed under the Creative Commons
Attribution-Noncommercial-Share Alike 3.0 License
http://creativecommons.org/licenses/by-nc-sa/3.0/
=============== =============== =============== ============

[Adrian Hawryluk]

Kirit Sælensminde wrote:

On Mar 5, 4:53 pm, "Gavin Deane" <deane_ga...@ho tmail.comwrote:

>On 5 Mar, 06:43, "Kirit Sælensminde" <kirit.saelensm [e-mail]>
wrote:

>>On Mar 4, 6:36 pm, "GavinDeane " <deane_ga...@ho tmail.comwrote:
On 4 Mar, 10:29, rpbg...@yahoo.c om (Roland Pibinger) wrote:
Is a contract violation a bug or an expected runtime scenario? IMO,
the latter.
How do you engineer a reliable product if you expect third party
components (software or hardware) not to adhere to their interface
specificatio ns? If you expect them to do that you need to change
supplier.
Isn't the ability to do just that what we strive to do? To write
reliable software even in the face of the unexpected?

There may be a confusion over the meaning of "expected" here. I was
responding to Roland Pibinger's phrase "expected runtime scenario"
believing he meant that a contract violation by a third party
component was a normal ("expected") event and that your program is
inherently flawed if correct behaviour relies on third party
components not violating their contracts.

By definition, the only way[*] it is possible for a component to
violate its interface specification is if it has a bug. And you can't
build a reliable product if one of the components has a bug. If the
bug is in a component you produce, you need to fix the bug. If the bug
is in a third party component, you need to change supplier (or get the
current supplier to fix their product).

[*] Assuming the documentation fully describes the interface. But
then, if it doesn't, you don't have the information needed to
integrate that component into your product in the first place.

OK. I think I see where you're coming from. It seems you're talking
about a systematic fault due to a buggy design or implementation,
rather than a transient fault caused by hardware failure or data
corruption.

If there is a transient fault, it is the same /unless/ there is a
recovery interface to the device /or/ you are willing to write a
mechanism to shutdown further possible use of that device. Either one
could get quite complex and would require an engineering decision as to
the pros, cons, ability to meet time-lines, etc.

If there is no recovery mechanism in place for the device, then you
/probably/ have lost _reliable_ contact with that device /permanently/.
There are, of course, exceptions to what I have just said, and would
have to be dealt with on a case by case basis.

Personally I find that I never use assert, but I suspect this has much
to do with the sorts of system that I build and the historic un-
availability of any debugger. I do use exceptions for the purposes
that others use asserts though.

Using exceptions in place of asserts is a more controlled way of
implementing runtime checks like asserts, but in some cases may not buy
you much when some hardware fails and may add a lot of complexity to the
system. However, that depends on many factors and should be dealt with
on a case by case manner.
Adrian

--
=============== =============== =============== =============
Adrian Hawryluk BSc. Computer Science
----------------------------------------------------------
Specialising in: OOD Methodologies in UML
OOP Methodologies in C, C++ and more
RT Embedded Programming
__--------------------------------------------------__
----- [blog: http://adrians-musings.blogspot.com/] -----
'--------------------------------------------------------'
My newsgroup writings are licensed under the Creative
Commons Attribution-Noncommercial-Share Alike 3.0 License
http://creativecommons.org/licenses/by-nc-sa/3.0/
=============== =============== =============== =============