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