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.

[Ian Collins]

Roland Pibinger wrote:

On Sun, 04 Mar 2007 23:14:14 +1300, Ian Collins rote:

>>I am describing using asserts to enforce the contract between the
application and its operating environment. If a device or library
specificati on specifies a valid set of output values, assert is a good
sanity check.

Is a contract violation a bug or an expected runtime scenario? IMO,
the latter.

Well it's certainly a bug in the provider.

A piece of hardware saying data is ready in one register while saying
there isn't any data to read most definitely isn't an expected runtime
scenario. Nor is it a bug in the application. It is something that
should never happen.

--
Ian Collins.

[Gavin Deane]

On 4 Mar, 10:29, rpbg...@yahoo.c om (Roland Pibinger) wrote:

On Sun, 04 Mar 2007 23:14:14 +1300, Ian Collins rote:

I am describing using asserts to enforce the contract between the
application and its operating environment. If a device or library
specification specifies a valid set of output values, assert is a good
sanity check.

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
specifications? If you expect them to do that you need to change
supplier.

Gavin Deane

[Roland Pibinger]

On 4 Mar 2007 03:36:41 -0800, "Gavin Deane" wrote:

>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
specifications ? If you expect them to do that you need to change
supplier.

You are right. The caller must rely on the contracts (specifications )
of third party components. I misinterpreted Ian Collins' remark that
he's "using asserts to enforce the contract between the application
and its operating environment". asserts may check some aspects of
contracts in non-release settings but are not appropriate to 'enforce'
them in release mode.

Best regards,
Roland Pibinger

[Ian Collins]

Roland Pibinger wrote:

On 4 Mar 2007 03:36:41 -0800, "Gavin Deane" wrote:

>>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
specification s? If you expect them to do that you need to change
supplier.

You are right. The caller must rely on the contracts (specifications )
of third party components. I misinterpreted Ian Collins' remark that
he's "using asserts to enforce the contract between the application
and its operating environment". asserts may check some aspects of
contracts in non-release settings but are not appropriate to 'enforce'
them in release mode.

Why are they not appropriate to 'enforce' them in release mode? If
something you trust breaks that trust, would you rather experience a
random, possibly damaging, failure or a controlled one?

--
Ian Collins.

[Roland Pibinger]

On Mon, 05 Mar 2007 07:44:00 +1300, Ian Collins wrote:

>Roland Pibinger wrote:

>asserts may check some aspects of
contracts in non-release settings but are not appropriate to 'enforce'
them in release mode.

Why are they not appropriate to 'enforce' them in release mode? If
something you trust breaks that trust, would you rather experience a
random, possibly damaging, failure or a controlled one?

assert is a means of finding bugs in your code. What you check at
runtime in your released program is something different (though
necessary and useful).

Best regards,
Roland Pibinger

[Kai-Uwe Bux]

Roland Pibinger wrote:

On Mon, 05 Mar 2007 07:44:00 +1300, Ian Collins wrote:

>>Roland Pibinger wrote:

>>asserts may check some aspects of
contracts in non-release settings but are not appropriate to 'enforce'
them in release mode.

Why are they not appropriate to 'enforce' them in release mode? If
something you trust breaks that trust, would you rather experience a
random, possibly damaging, failure or a controlled one?

assert is a means of finding bugs in your code. What you check at
runtime in your released program is something different (though
necessary and useful).

I feel this is going around in circles. As for a concrete example, I find
that g++ sometimes crashes upon me. Usually, it dies with a friendly
invitation to send in a bug report. It even gives some file and line number
info. I am pretty certain that the developers left some sanity check
assertions in g++. I highly appreciate that for the following reasons:

a) I prefer g++ crashing over generating faulty code. If I had no indication
that there was a problem with the compiler and the generated program
behaves not as expected, I would start searching for a bug in my code. That
could be a tremendous waste of time.

b) I can use the file and line number info to check the bugzilla database
and see whether the bug has already been reported.

Do you think, the compiler would be a better program with those assertions
turned off?
Best

Kai-Uwe Bux

[Old Wolf]

On Mar 3, 9:40 pm, Alan Johnson <[e-mail] wrote:

I'm not sure I like Hoare's analogy. Consider this one: When you are
learning to ride a bicycle you attach training wheels to catch you when
you make a mistake. When you are competing in the Tour de France you no
longer use the training wheels. Analogously, when you are writing code
you use asserts to catch when your invariants stop being invariant.
After you are satisfied the code is correct you disable them for
performance.

If it is really an invariant then you could do a compile-time check.
I hate it when people assert that one constant is bigger than another.

That said, I do find the rest of the arguments compelling.

I never use assert(), mostly for the reasons already listed. In C++ I
throw a logic_error exception and in C I call an error function that
prints out what happened and suspends the program. There have been
one or two instances over the years where one of the supposed
'impossible asserts' has happened in the field and I am very glad I
had the printout of what happened, instead of a vague report of a
malfunctioning device.

[Ian Collins]

Old Wolf wrote:

>
I never use assert(), mostly for the reasons already listed. In C++ I
throw a logic_error exception and in C I call an error function that
prints out what happened and suspends the program. There have been
one or two instances over the years where one of the supposed
'impossible asserts' has happened in the field and I am very glad I
had the printout of what happened, instead of a vague report of a
malfunctioning device.

So you do use asserts, you just give them a different name!

--
Ian Collins.

[Ian Collins]

Roland Pibinger wrote:

On Mon, 05 Mar 2007 07:44:00 +1300, Ian Collins wrote:

>>Roland Pibinger wrote:

>>>asserts may check some aspects of
contracts in non-release settings but are not appropriate to 'enforce'
them in release mode.

Why are they not appropriate to 'enforce' them in release mode? If
something you trust breaks that trust, would you rather experience a
random, possibly damaging, failure or a controlled one?

assert is a means of finding bugs in your code.

Says who? All the standard has to say is "The assert macro puts
diagnostic tests into programs".

What you check at
runtime in your released program is something different (though
necessary and useful).

Are we arguing over a name, or a technique? Do you include any
diagnostic tests for internal (rather user generated) state in your
released code?

--
Ian Collins.

[Old Wolf]

On Mar 5, 11:27 am, Ian Collins <[e-mail] mwrote:

Old Wolf wrote:

I never use assert(), mostly for the reasons already listed. In C++ I
throw a logic_error exception and in C I call an error function that
prints out what happened and suspends the program. There have been
one or two instances over the years where one of the supposed
'impossible asserts' has happened in the field and I am very glad I
had the printout of what happened, instead of a vague report of a
malfunctioning device.

So you do use asserts, you just give them a different name!

Please learn to read. I said "I never use assert()". assert() is
a C++ (and C) feature that aborts the program at runtime when its
argument is false , unless the macro NDEBUG is defined, in which
case it is a no-op. You can look it up in the C standard or in
various other references.