Sign in to follow this  
Endar

warning on an empty parameter list in function declaration

Recommended Posts

I'm looking to find if there's a way to raise a warning when a function is declared, in C, with an empty parameter list. I'm trying to detect when I don't put a 'void' in the function declaration of a function that has an empty parameter list. Is this possible?

Share this post


Link to post
Share on other sites
Good programming practice. One of the more senior programmers at work mentioned it and I just wondered if it were possible.

Share this post


Link to post
Share on other sites
What exactly is the keyword void in a parameter list buying you? Is it not more intuitive when there's no parameters for the parameter list to actually be empty? I never understood that.

I find the practice of putting void in the parameter list equatable to keeping $0 bills in your wallet on days when you're not shopping.

It's not good programming practice. At best, it's stylistic.

Share this post


Link to post
Share on other sites
Quote:
Original post by Rydinare
What exactly is the keyword void in a parameter list buying you? Is it not more intuitive when there's no parameters for the parameter list to actually be empty? I never understood that.


In standard C (as opposed to C++), no parameters to a function actually indicates an arbitrary number of arguments, IIRC. How one is supposed to access those arguments I never determined...

Share this post


Link to post
Share on other sites
Quote:
Original post by swiftcoder
Quote:
Original post by Rydinare
What exactly is the keyword void in a parameter list buying you? Is it not more intuitive when there's no parameters for the parameter list to actually be empty? I never understood that.


In standard C (as opposed to C++), no parameters to a function actually indicates an arbitrary number of arguments, IIRC. How one is supposed to access those arguments I never determined...


Ahh. I didn't realize that C treated it differently. That explains where the usage of foo(void) came from. Even so, that's very peculiar that they would do something so silly, when there's no way to access them (or is there?).

Just another reason why C is quite disappointing as a language.

Share this post


Link to post
Share on other sites
Quote:
Original post by Rydinare
Ahh. I didn't realize that C treated it differently. That explains where the usage of foo(void) came from. Even so, that's very peculiar that they would do something so silly, when there's no way to access them (or is there?).

Just another reason why C is quite disappointing as a language.


C++ is no better really. You get similar behavior with throw specifications (a function that does not specify any thrown exceptions can throw any, you have to explicitly specify that a function will throw no excpetions).

Share this post


Link to post
Share on other sites
Quote:
Original post by Rydinare
Quote:
Original post by swiftcoder
Quote:
Original post by Rydinare
What exactly is the keyword void in a parameter list buying you? Is it not more intuitive when there's no parameters for the parameter list to actually be empty? I never understood that.


In standard C (as opposed to C++), no parameters to a function actually indicates an arbitrary number of arguments, IIRC. How one is supposed to access those arguments I never determined...


Ahh. I didn't realize that C treated it differently. That explains where the usage of foo(void) came from. Even so, that's very peculiar that they would do something so silly, when there's no way to access them (or is there?).

Just another reason why C is quite disappointing as a language.


C was designed as a light layer on top of assembly which it does a great job of accomplishing.

Share this post


Link to post
Share on other sites
Quote:
Original post by Rydinare
Ahh. I didn't realize that C treated it differently. That explains where the usage of foo(void) came from. Even so, that's very peculiar that they would do something so silly, when there's no way to access them (or is there?).

In C function declarations don't necessarily match function definitions 100%. You can declare a function

int foo();

and later define it as

int foo(int bar);

and then hope and pray that whenever foo() is called, they use a single function parameter. In more practical terms, this can be used to bind functions with different parameter types into function pointers. Common examples in lex/yacc bind functions like sqrt() and pow() (which take different number of arguments) into the same function pointer type and then use parse trees to determine how many arguments to pass to the function pointers.

Share this post


Link to post
Share on other sites
Quote:
Original post by swiftcoder
Quote:
Original post by Rydinare
What exactly is the keyword void in a parameter list buying you? Is it not more intuitive when there's no parameters for the parameter list to actually be empty? I never understood that.


In standard C (as opposed to C++), no parameters to a function actually indicates an arbitrary number of arguments, IIRC. How one is supposed to access those arguments I never determined...


Not 100% sure but probably the same way the ... access variables.

Share this post


Link to post
Share on other sites
Quote:
Original post by swiftcoder
Quote:
Original post by Rydinare
What exactly is the keyword void in a parameter list buying you? Is it not more intuitive when there's no parameters for the parameter list to actually be empty? I never understood that.


In standard C (as opposed to C++), no parameters to a function actually indicates an arbitrary number of arguments, IIRC. How one is supposed to access those arguments I never determined...
There are several different methods, but every method revolves around the usage of the stack. For example, if you push parameters on the stack prior to calling the function, you can access the parameters within the routine by accessing the stack. (I have seen va_* macro implementations do this indirectly)

I dont know if any use of doing this in applications programming, though.

Share this post


Link to post
Share on other sites
I think you two are confusing function declarations with function definitions. See my previous post.

Share this post


Link to post
Share on other sites
Quote:
Original post by Driv3MeFar
Quote:
Original post by Rydinare
Ahh. I didn't realize that C treated it differently. That explains where the usage of foo(void) came from. Even so, that's very peculiar that they would do something so silly, when there's no way to access them (or is there?).

Just another reason why C is quite disappointing as a language.


C++ is no better really. You get similar behavior with throw specifications (a function that does not specify any thrown exceptions can throw any, you have to explicitly specify that a function will throw no excpetions).


The C++ way of doing things is certainly significantly safer than doing things the C way on many fronts, when you're programming C++. You're correct in C++ missing some important areas, though. Throw-specifications could certainly be done much better. As they are in C++ with the current standard, they are not very useful.

Share this post


Link to post
Share on other sites
Found it :D

This will generate the warning and cause it to be shown as an error:

#pragma warning(error : 4255)
void func()
{

}


It doesn't show up usually because (at least in VS) that warning if off by default and only for the C compiler, not C++.

Share this post


Link to post
Share on other sites
-Wstrict-prototypes in gcc.

And as pointed out, it *is* good programming practice to use (void) in C, while it is completely unnecessary (and messy IMO) to do so in C++. Code intended to be compiled in both languages should use (void), but no one really does that, do they?

In practice this cleanup will probably not save you any later headaches, of course.

Share this post


Link to post
Share on other sites
Why won't this save headaches?

I mean, we're not especially having a problem with this now, but since we're writing code in C, why wouldn't it help?

Share this post


Link to post
Share on other sites
It seems like you'd have to really try hard to come up with a case where it'd do the wrong thing.

But I agree, it should be done... it's probably not the highest priority thing you could do to your code though.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this