enforce()?

[Walter Bright]

Vladimir Panteleev wrote:
> On Sun, 20 Jun 2010 03:04:31 +0300, Walter Bright 
> <newshound1 at digitalmars.com> wrote:
> 
>> Andrei Alexandrescu wrote:
>>> On 06/19/2010 03:55 PM, bearophile wrote:
>>>> Inside Phobos2 I have counted about 160 usages of the "body" keyword.
>>>> I think contract programming can be used more often inside Phobos2
>>>> (and maybe some usages of enforce() can be turned into contract
>>>> programming because they are more similar to program sanity checks).
>>>  Walter and I discussed this and concluded that Phobos should handle 
>>> its parameters as user input. Therefore they need to be scrubbed with 
>>> hard tests, not contracts.
>>
>> I should add that any library that may be used as a dll should have 
>> its interface API checked with hard tests, not contracts. This is 
>> because a dll cannot control who connects to it, and therefore must 
>> regard anything sent to it as unvalidated user input.
> 
> I don't see the logic in this...
> 
> Are we talking about validating user input for the sake of security, or 
> debugging (catching bugs early)?

An input to a dll is user input, and should be validated (for the sake of 
security, and other reasons). Validating it is not debugging.


> If it's for the sake of debugging, debug checks should remain in debug 
> builds (that's what contracts are for?). Otherwise, you are stripping 
> the programmer of the choice between higher performance or more debug 
> checks.
> 
> If it's for the sake of security - parameter validation in DLLs is 
> pointless. If you are able to load and call code from inside a DLL, you 
> are already able to do everything that the DLL can. DLLs don't have any 
> "setuid"-like properties. If we were talking, for example, about 
> syscalls for a kernel module (functions called from userland but 
> executed in kernel land), then that would be a completely different 
> situation.

If you, for example, provide a pluggable interface to your browser app, that's 
done using a dll, and you'd better validate anything you get through that plugin 
interface!

> Also, I don't think that one rule can apply for everyone. For example, a 
> high-performance DLL may specify in its documentation that the function 
> parameters are not checked by the DLL and must be valid, otherwise 
> undefined behavior will occur. (I believe some Windows APIs do not check 
> some parameters and will cause access violations when called with 
> invalid parameters.)

If you don't validate the input, then you must accept the risk.