Style (?) issue

Em 4/1/2011 08:08, David Brown escreveu:
> On 04/01/2011 00:22, D Yuniskis wrote:
>> Hi David,
[snipped]

>> Sorry, I understood your point. I am commenting that, in my case(s),
>> the compiler can't tell whether "src is non-NULL" (e.g., imagine
>> walking a tree and chasing pointers to next branches; you can't
>> know at compile time which pointers will be NULL or "valid").
>> So "probe_subtree(pointer)" must either *itself* check that it
>> doesn't dereference "pointer" *or* the caller does so before
>> invoking probe_subtree(). In either case, the compiler can't help.

More or less.

>
> 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.
>

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]

>> The "problem" is a pathological one. What looks to be valid
>> argument proves to be, um, "inappropriate" -- but, only because
>> of the requirements that the called function "later" imposes
>> on it.
>>
>
> 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.

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/

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

> No. I'm arguing that the second set of invariants shouldn't be there.
> I.e., that the "problem" they are trying to detect is caused by
> something not exported by the function's interface (or its
> specification).
>
> Note an example I mentioned "someplace" regarding an 8 digit
> "add()". It makes sense to define the interface to ensure
> both arguments have fewer than 8 digits. But, it *doesn't*
> make sense (IMO) to define the interface such that "the
> SUM of these two arguments must fit in 8 digits". Rather, if
> the sum *happens* to not fit, you signal an *error* (overflow),
> not a contractual violation.

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.

>
> Otherwise, you start writing "recursive" interface definitions;
> in effect, saying, "Use this function but only in a way that
> the function applied to the inputs WILL HAVE caused the *actual*
> function invocation to work properly..." :-/

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

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