7 ms·
Archaic and impractical. Example: Instead of using Linux' pragmatic approach to function prototypes: "In function prototypes, include parameter names with the
by bigfoot 12y ago
Archaic and impractical. Example: Instead of using Linux' pragmatic approach to function prototypes:
"In function prototypes, include parameter names with their data types.
Although this is not required by the C language, it is preferred in Linux
because it is a simple way to add valuable information for the reader."
OpenBSD enforces this:
"Prototypes should not have variable names associated with the types; i.e.,
void function(int);
not:
void function(int a);"
Instead of letting the code tell the parameters' purposes, this now has to be deduced from informal descriptions, or the function definition in some .c file.
- 0x0 12y agoWhat would be a reason for leaving out the parameter names? Genuinely curious.
- foxhill 12y agoDRY 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.
- Denzel 12y agoTo allow the function definition to serve as the single source of truth. That would be my guess. They simply don't want to have to update the parameter name at N places, if a parameter were to be renamed.
- deleted 12y ago[deleted]
- imanaccount247 12y agoI love how frequently people on HN decry actual real working things people actually work on and use as "impractical". I suspect the combined experience of the entire openbsd team is greater than yours.