enforce()?

Vladimir Panteleev vladimir at thecybershadow.net
Mon Jun 21 22:05:45 PDT 2010


On Mon, 21 Jun 2010 04:53:46 +0300, BCS <none at anon.com> wrote:

> If I didn't write the DLL I'm calling, I'll assume it doesn't check  
> stuff. If I didn't write the code calling my DLL, I'll assume it doesn't  
> check stuff. Why should I assume that the documentation is right or that  
> people will even read my documentation? Unless you can show me that this  
> causes a perf problem, the benefit just isn't worth the cost.

If you can't trust the DLL to perform correct user data validation, you  
can't trust it AT ALL! For all you know it can have a buffer overflow  
vulnerability. Re-validating any data you get from it may save you from  
one type of bug, but it doesn't improve security by much overall.

Regarding performance: what is not a "performance problem" in any one  
single place can make a considerable difference when you sum up all the  
redundant checks in your entire codebase.

A practical example from the industry:

For Microsoft partners, Windows is available in a "free" (or retail) build  
and a "checked" build [1].
Since driver code runs in kernel space, drivers can crash the entire  
system anyway - for this reason, there are few checks or kernel mode APIs.  
(That's why sometimes when debugging BSoDs, crashes will happen in a  
completely unrelated kernel module.)
However, if you need to debug your driver, you run it on the checked  
version of Windows, which additionally to having lots of debug checks is  
also built without most compiler optimizations.

   [1]: http://msdn.microsoft.com/en-us/library/ff543450(VS.85).aspx

-- Best regards,
  Vladimir                            mailto:vladimir at thecybershadow.net


More information about the Digitalmars-d mailing list