Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


#Actualcr88192

Posted 26 March 2013 - 05:06 PM

Empty argument lists in C is a terrible idea! It's also different to C++ where it means the function is void. It just seems like an incredibly lazy way to prototype a function and what's more the compiler doesn't complain when you pass the wrong number or type of arguments!!! It's basically the same as using ellipsis argument list except without the requirement that you have at least one argument before the ellipsis.

 

At least one bug has been incredibly hard to track down in our codebase because of this "feature" (i.e. someone does a local prototype in a c file for a function that was once void, and it continues to work (incorrectly of course) without complaint when someone added an argument to the function).

 

yes, but this is more about what would be defined by the standard, not about whether or not it is good practice.

the issue is, there is still a lot of code floating around which would break if you took away "()", but relatively little which would break if the rest of old-style declarations were taken away.

 

(FWIW, my C compiler had effectively dropped both, making "()" behave like "(void)" and treating relying upon the old-style semantics as a warning).

 

 

but, anyways, to clarify a few of the thoughts: the endianess specifiers would probably be as special preprocessor defines, which would have undefined behavior (probably being no-op) if the compiler doesn't support the feature. preprocessor defines could exist to specify whether the feature is present and works.

 

the declaration ordering restrictions would be more subtle, probably placing a few restrictions like:

type qualifiers will precede specifiers (except in certain conditions);

other type specifiers and user-defined types (typedef-name) will be mutually exclusive;

only one (and exactly one) user-defined type may be referenced as part of a given declaration type;

...

 

most existing code already does this, and making this an optional requirement can result in a parser speedup (though, as-is, a command-line option can achieve similar effect). basically, it allows eliminating most cases where it is necessary to check whether or not an identifier is a known typedef (IME: this is where a big chunk of the time goes when parsing declarations from headers, at least in my tools).


#2cr88192

Posted 26 March 2013 - 05:06 PM

Empty argument lists in C is a terrible idea! It's also different to C++ where it means the function is void. It just seems like an incredibly lazy way to prototype a function and what's more the compiler doesn't complain when you pass the wrong number or type of arguments!!! It's basically the same as using ellipsis argument list except without the requirement that you have at least one argument before the ellipsis.

 

At least one bug has been incredibly hard to track down in our codebase because of this "feature" (i.e. someone does a local prototype in a c file for a function that was once void, and it continues to work (incorrectly of course) without complaint when someone added an argument to the function).

 

yes, but this is more about what would be defined by the standard, not about whether or not it is good practice.

the issue is, there is still a lot of code floating around which would break if you took away "()", but relatively little which would break if the rest of old-style declarations were taken away.

 

(FWIW, my C compiler had effectively dropped both, making "()" behave like "(void)" and treating relying upon the old-style semantics as a warning).

 

 

but, anyways, to clarify a few of the thoughts: the endianess specifiers would probably be as special preprocessor defines, which would have undefined behavior (probably being no-op) if the compiler doesn't support the feature. preprocessor defines could exist to specify whether the feature is present and works.

 

the declaration ordering restrictions would be more subtle, probably placing a few restrictions like:

type qualifiers will precede specifiers (except in certain conditions);

other type specifiers and user-defined types (typedef-name) will be mutually exclusive;

only one (and exactly one) user-defined type may be referenced as part of a given type-declaration;

...

 

most existing code already does this, and making this an optional requirement can result in a parser speedup (though, as-is, a command-line option can achieve similar effect). basically, it allows eliminating most cases where it is necessary to check whether or not an identifier is a known typedef (IME: this is where a big chunk of the time goes when parsing declarations from headers, at least in my tools).


#1cr88192

Posted 26 March 2013 - 05:03 PM

Empty argument lists in C is a terrible idea! It's also different to C++ where it means the function is void. It just seems like an incredibly lazy way to prototype a function and what's more the compiler doesn't complain when you pass the wrong number or type of arguments!!! It's basically the same as using ellipsis argument list except without the requirement that you have at least one argument before the ellipsis.

 

At least one bug has been incredibly hard to track down in our codebase because of this "feature" (i.e. someone does a local prototype in a c file for a function that was once void, and it continues to work (incorrectly of course) without complaint when someone added an argument to the function).

 

yes, but this is more about what would be defined by the standard, not about whether or not it is good practice.

the issue is, there is still a lot of code floating around which would break if you took away "()", but relatively little which would break if the rest of old-style declarations were taken away.

 

(FWIW, my C compiler had effectively dropped both, making "()" behave like "(void)" and treating relying upon the old-style semantics as a warning).

 

 

but, anyways, to clarify a few of the thoughts: the endianess specifiers would probably be as special preprocessor defines, which would have undefined behavior (probably being no-op) if the compiler doesn't support the feature. preprocessor defines could exist to specify whether the feature is present and works.

 

the declaration ordering restrictions would be more subtle, probably placing a few restrictions like:

type qualifiers will precede specifiers (except in certain conditions);

type specifiers and user-defined types (typedef) will be mutually exclusive;

only one (and exactly one) user-defined type may be referenced as part of a given type-declaration;

...

 

most existing code already does this, and making this an optional requirement can result in a parser speedup (though, as-is, a command-line option can achieve similar effect). basically, it allows eliminating most cases where it is necessary to check whether or not an identifier is a known typedef (IME: this is where a big chunk of the time goes when parsing declarations from headers, at least in my tools).


PARTNERS