Style (?) issue

That is a different sort of function - here you are writing code where the pointer is sometimes null, and sometimes non-null. An "assert" is therefore inappropriate for testing, because both values are valid. It depends on the code whether you want to have the test inside "probe_subtree" or inside the caller, but either way the test is part of the algorithm, not a check for argument validity.

There should not be a grey area here. Arguments are either within the specification, or they are not. It's okay to treat different argument values differently, and return special codes in some cases - that is part of the specification of your function.

You have two choices here. One is to specify that the function will take two values that can be summed to an eight digit number, and it will return that sum. The other is to specify that the function will take two values, and will either return their sum if it fits within 8 digits, or FAIL if it exceeds 8 digits.

That's your functionality specified. You can use asserts to check the input specifications if you want.

What you can't do is claim the function can take any eight digit inputs, then crash or return surprise values because their sum takes more than eight digits.

Reply to
David Brown
Loading thread data ...

[snipped]

More or less.

Yes, both values are potentially 'valid' as inputs to the downstream program, _but_ in this case the program verifier should be changed to insure the null pointer case is adequately treated and the program proceeds to a correct state, 'correct' in this case having two senses, the one the verifier can examine that a branch of the program treats this case, and in the application realm that the program/device does what is sensible and adequate to the business it serves.

[snipped]

Yes. In fact reducing the need for so many special code returns and so the space of possible failure modes is an art in itself!

--
Cesar Rabak
GNU/Linux User 52247.
Get counted: http://counter.li.org/
Reply to
Cesar Rabak

Em 4/1/2011 03:26, D Yuniskis escreveu: [snipped]

Humm... I think you need to think with more precision and have an accurate definition of terms.

An overflow is a _condition_ the program has reached. It can only be considered an error if in the specific application this leads to state which no useful progress of the program flow can be devised other than an 'error recovery' like asking the user to re-enter the numbers, etc.

Once you have a function that returns error codes, you have it!

--
Cesar Rabak
GNU/Linux User 52247.
Get counted: http://counter.li.org/
Reply to
Cesar Rabak

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.