[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <NDBBKKOCALIBPMFFNMEMAEBDENAA.cseagle@redshift.com>
From: cseagle at redshift.com (Chris Eagle)
Subject: Coding securely, was Linux (in)security
> -----Original Message-----
> From: Brett Hutley [mailto:brett@...ley.net]
>
> So you're saying I don't need to worry if a file pointer is NULL before
> passing it through to fprintf()? So I don't need to worry if an argument
> to strcpy() is NULL? Or are you trying to say that the standard library
> is badly written?
Nope, I never said the caller shouldn't check what they pass. But, the
subroutine should NEVER assume that the caller has checked. I find it
comical that others in this thread say in one breath, you should always
validate user supplied input, but in another breath that subroutines should
not be responsible for validating supplied parameters. A subroutine that
states something like "never pass in a NULL pointer" and then chokes when
someone does is poorly coded, plain and simple. If that applies to
functions in the standard library then yes it is badly written. Undefined
behavior in response to unexpected inputs is always a problem.
Are you saying that subroutine authors should rely on the "good will" of
callers to supply only valid arguments? Microsoft seems to take that
approach regarding user input validation and it clearly doesn't work
Chris
Powered by blists - more mailing lists