5 ms·
DRY principle - you give the variables a name once, in the function definition. e.g: //decl in the header int pow(int exponent, int base); if you only
by foxhill 12y ago
DRY principle - you give the variables a name once, in the function definition. e.g:
//decl in the header
int pow(int exponent, int base);
if you only look at the header you might think that the arguments are one way, but
//actual definition
int pow(int base, int exponent){
//math is correct but base <-> exponent..
}
i'm not saying i agree with this at all - it's a contrived example..!
- tedunangst 12y agoCVE-2014-3956
- erhardm 12y agoReplying with a CVE is like icing on the cake. :) It really shows that OpenBSD devs take security seriously. Funny timing, I was just reading Absolute OpenBSD.
- bigfoot 12y agoOK, agreed. C (and C++) just suck regarding this detail.
- steveklabnik 12y agoIt also demonstrates that sometimes, there are additional constraints that you may not understand in choices you may not agree with.
- ajross 12y agoI don't see how that's relevant. The bug in that CVE is that the function call got the parameter order wrong. The declaration was correct AFAICT, and of course completely irrelevant because you can make that mistake regardless of what the header says. Parameters in headers are just documentation, by definition. Documentation can be wrong however you write it, but in general it helps to have it instead of not. Would you seriously argue that function parameters should not be given names in documentation?
- clarry 12y ago> The bug in that CVE is that the function call got the parameter order wrong. The declaration was correct AFAICT Actually if you look at the patch to fix this issue, they swap the identifiers in the declarator. Of course when something like this happens, you're free to choose whether the definition or the callers should be changed. https://www.FreeBSD.org/security/patches/SA-14:11/sendmail.patch https://www.FreeBSD.org/security/patches/SA-14:11/sendmail.p...
- ajross 12y agoThat's the function definition, not its declaration. It's pre-ANSI C, so that semicolon can mislead. I didn't bother to grab the source to check whatever the header said (or, heh, didn't say, per OpenBSD convention), but I'm going to assume it was correct. It amuses me greatly that we're sitting here arguing over the minutiae of coding standards when this thing is still written in K&R syntax. But regardless: whatever the header said, it wouldn't have affected this bug, which was just a straightforward transpose thing between compatible types. People get memcpy() reversed all the time too, and frankly I don't know if I've ever looked at its function declaration in a header.
- deleted 12y ago[deleted]
- foxhill 12y agoi would argue that had the function prototype had names for it's arguments that this might not have happened.
- cesarb 12y agoHm. This is the kind of thing where a compiler warning could be useful. I took a quick look at gcc's manual, but it does not seem to have a warning for this particular mistake (argument names do not match between declaration and definition). That way, you could repeat yourself safely, since the repetition would be checked by the compiler.
- hga 12y agoI did a quick -Wall test with gcc 4.4.5 and it doesn't warn.