Re: Checking values

[carolyn.ryll () philips com]

Wouldn't logic state that you should be paranoid outside your own circle 
of proven trust? If you do not know if validation is assured, then test 
it. If the test fails, then you know you need to validate it at your end. 
Truly not meant as a Microsoft OS slam, but you are putting trust in 
classes that Microsoft certainly uses themselves - and they are the 
KingPin of the buffer overflow vulnerability. Documented doesn't mean 
anything, either. Documentation is usually written by tech-writers who 
clean up documents thrown together by the designers and programmers (that 
documented after the fact), and have never stepped foot into the 
development process.

Like I said, if it's not in your *proven* circle of trust, then why should 
you trust it?

Regards,
Carolyn.

Chris Richards <[EMAIL PROTECTED]>
Sent by: 
[EMAIL PROTECTED]
2003-12-05 10:19 AM

 
        To:     "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
        cc:     (bcc: Carolyn Ryll/ATL-BTL/MS/PHILIPS)
        Subject:        [SC-L] Checking values
        Classification: 



Here's a question:
How paranoid should I be in checking values?  For example:

I frequently have need to check registry keys for values, so I commonly do
something like the following:
 
CRegKey crReg;
CString csValue;
DWORD dwBuffSize = 1024, dwReturn = 0xFFFFFFFF;
TCHAR *lpszValue;
 
//code to open registry
.
.
.
//get reg value
lpszValue = csValue.GetBuffer(dwBuffSize);
if(NULL != lpszValue)
{
    dwReturn = crReg.QueryValue(lpszValue, "SomeRegistryValueName",
&dwBuffSize);
    csValue.ReleaseBuffer(dwBuffSize);
    lpszValue = NULL;
    if(ERROR_SUCCESS != dwReturn)
    {
        //do error processing
    }
}
//other processing
 
These are all MFC classes.  CString is documented as initializing itself 
to
a null string.  Should I believe the docs, or should I initialize the 
string
anyway?  If I don't believe it, then what is the point of using the class
(one of the reasons you use classes is because the constructors and
destructors are supposed to take care of house-keeping issues like this 
for
you)?  If I assume that it is correct and it turns out not to be, do I 
bear
some of the blame for the failure of the application?
 
In short, how far do we go in assuming the rest of the world is out to get
us?  If I create a function, and document that only certain input ranges 
are
valid and that unpredictable behavior may result if you violate those
bounds, is it my fault if someone violates those bounds when using my
function?
 
Generally speaking, my rule of thumb has always been to assume that direct
user input is hostile, because users are dumb and will ignore all of the
warnings that you give them.  On the other hand, if the design of an
application guarantees that a function requiring input data within a 
certain
range will only ever see data within that range, I may not do any bounds
checking within that function, though I will document the range of inputs
the function expects.  The exception to this is in cases where I am 
writing
a function specifically for general use, where the range of inputs may
violate expectations.
 
What say you?  And why?
 
Later,
Chris