Assertions in principle

[Ian Collins]

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.

 

[Gavin Deane]

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]

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]

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?

 

[Roland Pibinger]

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]

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]

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]

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]

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?

 

[Old Wolf]

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.

 

[Ian Collins]

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.

It aborts by default, but there is nothing stopping you changing the
action. On an embedded system without a standard output, logging the
file and line and rebooting is a reasonable thing to do.

 

[=?iso-8859-1?q?Kirit_S=E6lensminde?=]

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.

Isn't the ability to do just that what we strive to do? To write
reliable software even in the face of the unexpected?

I always looked at everything that I've done to try to engineer better
software as being able to cope with every more error cases and faulty
systems (and users) with the minimum of problems.


K

 

[Ian Collins]

Isn't the ability to do just that what we strive to do? To write
reliable software even in the face of the unexpected?

You can't defend against all possible invalid input form third party
components. You should be able to defend against all possible invalid
input from users.

I always looked at everything that I've done to try to engineer better
software as being able to cope with every more error cases and faulty
systems (and users) with the minimum of problems.

I'm sure we all do, but the are situations where the only safe thing to
do is bail out as soon as possible.

 

[=?iso-8859-1?q?Kirit_S=E6lensminde?=]

You can't defend against all possible invalid input form third party
components. You should be able to defend against all possible invalid
input from users.

Can't we? In the sense of analysing whether we have defended against
them all I suspect this is probably the same as solving the halting
problems. That doesn't mean we can't do it in specific circumstances
though. To turn the original question around:

"How do you engineer a reliable product if you expect third party
components (software or hardware) to always adhere to their interface
specifications?"

We should be defending against as many of these errors as we possibly
can in third party components and we shouldn't forget to do so for
those in our own as well.

I'm sure we all do, but the are situations where the only safe thing to
do is bail out as soon as possible.

I completely agree, but this is a measure of last resort and should
really only be undertaken as a response when to not do so would cause
an even worse eventuality.


K

 

[Ian Collins]

Can't we? In the sense of analysing whether we have defended against
them all I suspect this is probably the same as solving the halting
problems. That doesn't mean we can't do it in specific circumstances
though. To turn the original question around:

I worded my response badly, I should have said we can't *handle* all
possible invalid input form third party components. We have to try a
defend against them, which is where asserts are often or best and only
weapon. After all, if the input is something we can safely handle, it
isn't invalid.

I completely agree, but this is a measure of last resort and should
really only be undertaken as a response when to not do so would cause
an even worse eventuality.

Assuming unexpected input is by deffinition input we are unable to
process safely, then we have reached the last resort.

 

[Roland Pibinger]

Says who?

That's the common meaning of the C/C++ assert macro which is also
indicated by the NDEBUG define. Assertions (as in DBC) may have a
different meaning.

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

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?

The criterion is whether the diagnostic test checks a programmer error
or an expected (probably rare) incident.

Best regards,
Roland Pibinger

 

[Ian Collins]

The criterion is whether the diagnostic test checks a programmer error
or an expected (probably rare) incident.

I see. So why don't you consider asserts to be appropriate for these
non-programmer errors?

 

[Roland Pibinger]

I see. So why don't you consider asserts to be appropriate for these
non-programmer errors?

Because asserts are not available in the relased program and you most
probably want these non-programmer errors to be detected also in the
released program.

Best regards,
Roland Pibinger

 

[Gavin Deane]

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.

I always looked at everything that I've done to try to engineer better
software as being able to cope with every more error cases and faulty
systems (and users) with the minimum of problems.

Users are different. You have to be prepared for anything from them.

I was talking about faulty systems that *are part of* the product, as
opposed to systems the product interacts with.

An example, I hope not too contrived, suppose I am producing DVD
recorders. The DVD drive that reads and writes discs is part of the
product. If it violates its interface spec (which in this case will
have electrical and mechanical aspects as well as software, but the
principle is the same) I can't build a product around it and that's
that. On the other hand, the individual discs the users put in the
machine are something my system interacts with. I must be able to
detect incorrect format or faulty discs and inform the user while
continuing to run.

Gavin Deane

 

[Ian Collins]

Because asserts are not available in the relased program and you most
probably want these non-programmer errors to be detected also in the
released program.

I guess that all depends whether you define NDEBUG or not.