Prev: Inputs left floating at the very start
Next: Microcontroller USB interface chip
From: Andrew Smallshaw on 4 May 2008 15:33
On 2008-05-04, Dombo <dombo(a)disposable.invalid> wrote:
>
> The assert() macro (or a homebrew equivalent)) offers a reasonably
> concise way to achieve that, and can be considered to be a way of
> documenting the pre- and postconditions of the code.

Agreed. I encouraged the use of assert() on this very group only
a couple of days ago. It has a few things that your typical range
checking code doesn't. Firstly of course it compiles to nothing
with a flick of a compile time switch. Also when an assert fails
the action is to crash and burn. That is good because the function
interfaces do not need to allow for the possibility of an error
occurring.

This is one of the main problems when testing prerequisites in a
language such as C that lacks exceptions - there often isn't any
natural method of indicating the error to the caller, which forces
yet more logic there to test for the error condition that was picked
up by the callee. That is one reason why it is usually better
simply to test the prerequisites in the caller in the first instance.

> My experience is that a bit of defensive programming saves far more time
> than it costs. Not only because catching errors early can save days of
> debugging and (re-)testing, but more importantly because it forces one
> to think about the pre- and postconditions and make them explicit.

That is an argument for better specification and documentation,
not for redundant code in the final product. If there is ambiguity
in what input is valid for an particular function then that says
more about design processes and project management than it does
about the quality of the code in question.

--
Andrew Smallshaw
andrews(a)sdf.lonestar.org
From: Dombo on 4 May 2008 16:53
Andrew Smallshaw schreef:
> On 2008-05-04, Dombo <dombo(a)disposable.invalid> wrote:
>> The assert() macro (or a homebrew equivalent)) offers a reasonably
>> concise way to achieve that, and can be considered to be a way of
>> documenting the pre- and postconditions of the code.
>
> Agreed. I encouraged the use of assert() on this very group only
> a couple of days ago. It has a few things that your typical range
> checking code doesn't. Firstly of course it compiles to nothing
> with a flick of a compile time switch. Also when an assert fails
> the action is to crash and burn. That is good because the function
> interfaces do not need to allow for the possibility of an error
> occurring.
>
> This is one of the main problems when testing prerequisites in a
> language such as C that lacks exceptions - there often isn't any
> natural method of indicating the error to the caller, which forces
> yet more logic there to test for the error condition that was picked
> up by the callee. That is one reason why it is usually better
> simply to test the prerequisites in the caller in the first instance.

It depends on your error strategy. Which error strategy is most
appropriate depends on the application. For some applications the log,
crash and burn strategy is preferable over muddling along in an
inconsistent state with unknown consequences. In other applications it
may be better to just continue and hope the customer will never notice.

Ideally one would be able to prove that there are no errors in the code
instead of adding runtime checks (being it at the side of the caller or
the callee). Source code analysis tooling like Coverity, Grammatech and
Polyspace should render those runtime checks unnecessary. I have no
first hand experience with any of these tools, but I'm interested in
hearing from anyone who has.

>> My experience is that a bit of defensive programming saves far more time
>> than it costs. Not only because catching errors early can save days of
>> debugging and (re-)testing, but more importantly because it forces one
>> to think about the pre- and postconditions and make them explicit.
>
> That is an argument for better specification and documentation,
> not for redundant code in the final product. If there is ambiguity
> in what input is valid for an particular function then that says
> more about design processes and project management than it does
> about the quality of the code in question.

Even with perfect specifications and documentation in place you still
have to deal with people who may have misread, forgot or just interpret
things differently. Training people to make their assumptions explicit
(e.g. by using assert()) makes it easier to detect deviations from the
design specification, identify gaps and ambiguities in the design
specification and it triggers people to check the design specification.

Of course this wouldn't be necessary if all specifications were perfect
(they rarely are, even official specifications, like those from ISO,
often have ambiguities), and if all people would perfectly adhere to the
specifications. Unfortunately I live in an imperfect world; neither the
specifications nor the people (including myself) are flawless. The best
way to deal with that is to assume errors will be made at any stage of
the process and try to catch (and correct) them as early as possible.
Finding the right balance however is the real challenge.
From: Robert Adsett on 5 May 2008 00:25
In article <481DF1B6.56D5FBDD(a)yahoo.com>, CBFalconer says...
> Robert Adsett wrote:
> >
> ... snip ...
> >
> > However, the fact that no one considered that the inputs could be
> > out of range (and for that matter your reaction to the observation)
> > is an interesting commentary on how we view this practice we call
> > programming. We seem to default to the assumption that the input
> > values to our current problem will be in the range we expect.
>
> So you didn't bother reading my reply?

I had to check back to make sure I had, my apologies for forgetting it.
Your solution does at least limit the range of outputs. It does leave
open the question of whether values other than 1 or 2 are acceptable
inputs.

At least someone is considering other inputs may occur.

Robert
** Posted from http://www.teranews.com **
From: CBFalconer on 5 May 2008 02:14
Robert Adsett wrote:
> CBFalconer says...
>> Robert Adsett wrote:
>>>
>> ... snip ...
>>>
>>> However, the fact that no one considered that the inputs could be
>>> out of range (and for that matter your reaction to the observation)
>>> is an interesting commentary on how we view this practice we call
>>> programming. We seem to default to the assumption that the input
>>> values to our current problem will be in the range we expect.
>>
>> So you didn't bother reading my reply?
>
> I had to check back to make sure I had, my apologies for forgetting
> it. Your solution does at least limit the range of outputs. It does
> leave open the question of whether values other than 1 or 2 are
> acceptable inputs.
>
> At least someone is considering other inputs may occur.

No, look again. It accepts all inputs, but only outputs the values
1 and 2. It was:

if (1 == x) x = 2;
else x = 1;

or similar.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.


** Posted from http://www.teranews.com **
From: Nils on 6 May 2008 15:48
tims next home schrieb:

>>>
>>> x = "\00\02\01"[x];
>>
>> You are insufficiently depraved.
>> x = x["0\02\01"];
>> works, and is perfectly valid C.
>
> Not when working on my team, it isn't:-)
>
> tim

How about x = 4>>x

:-)

Nils
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: Inputs left floating at the very start
Next: Microcontroller USB interface chip