lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
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