K&R-Style Function Declarations: Good or Bad?

[Michael B.]

I tend to use rather descriptive names for parameters, so the old style of
declaration appeals to me, as I can keep a declaration within 80 chars:

void * newKlElem (frame_size,num_blocks,num_frames,frame_locator)
size_t frame_size;
unsigned short num_blocks;
unsigned short num_frames;
Kl_frame_locator *locator;
{
/* code goes here */

I've found many who despise this sort of declaration, and also some who
say it's going to be deprecated in a future standard. Should I avoid
something like this, or keep doing as I please?

 

[Jack Klein]

On Sun, 07 Dec 2003 23:13:17 -0800, "Michael B."

Very, very, VERY bad.

I tend to use rather descriptive names for parameters, so the old style of
declaration appeals to me, as I can keep a declaration within 80 chars:

void * newKlElem (frame_size,num_blocks,num_frames,frame_locator)
size_t frame_size;
unsigned short num_blocks;
unsigned short num_frames;
Kl_frame_locator *locator;

Note that this is a function definition as well as a declaration, but
it is not a prototype.

You do realize that full prototype definitions are not required to fit
on a single line?

And how is this any better than:

void *newKlElem (size_t frame_size, unsigned short num_blocks,
unsigned short num_frames, Kl_frame_locator *locator)

....(which takes fewer vertical lines than yours) or:

void *newKlElem (
size_t frame_size,
unsigned short num_blocks,
unsigned short num_frames,
Kl_frame_locator *locator )

....which takes no more vertical lines than yours???

{
/* code goes here */

I've found many who despise this sort of declaration, and also some who
say it's going to be deprecated in a future standard. Should I avoid
something like this, or keep doing as I please?

The pre-standard function definition does not create a prototype for
the function. The single most important improvement to C in its
entire existence was the addition of real function prototypes. To
give up that advantage for style reasons does not seem like a good
idea.

There is also the issue of keeping prototypes in sync with
definitions. Generating or updating a prototype from a standard
definition is as simple as copying the text, pasting it into the
header file or wherever the prototype is needed, and adding a ; after
the closing right parenthesis.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq

 

[Adam G.]

于 Sun, 07 Dec 2003 23:13:17 -0800，Michael B.写到：

I tend to use rather descriptive names for parameters, so the old style of
declaration appeals to me, as I can keep a declaration within 80 chars:

void * newKlElem (frame_size,num_blocks,num_frames,frame_locator)
size_t frame_size;
unsigned short num_blocks;
unsigned short num_frames;
Kl_frame_locator *locator;
{
/* code goes here */

I've found many who despise this sort of declaration, and also some who
say it's going to be deprecated in a future standard. Should I avoid
something like this, or keep doing as I please?

I prefer this kind of declaration just because of its readability
and clearness.

 

[Mark F. Haigh]

I tend to use rather descriptive names for parameters, so the old style of
declaration appeals to me, as I can keep a declaration within 80 chars:

void * newKlElem (frame_size,num_blocks,num_frames,frame_locator)
size_t frame_size;
unsigned short num_blocks;
unsigned short num_frames;
Kl_frame_locator *locator;
{
/* code goes here */

I've found many who despise this sort of declaration, and also some who
say it's going to be deprecated in a future standard. Should I avoid
something like this, or keep doing as I please?

I don't recommend doing this. netKlElem's definition above is not a
prototype. If you don't provide your own prototype, then subsequent
calls to it may not have any type checking, and will go through the
default argument promotions.

Be aware of the strange situation that may result if your source file
above is compiled without a prototype in scope, and a maintenence
programmer decides to put one into another header or source file. If
the prototype's types do not match with the types of the original
function *after* default argument promotions, then the behavior is
undefined.

This sounds contrived, but can actually happen in practice when a
function is needed in more than one file, and somebody de-statics it and
adds a prototype to a header somewhere.


Mark F. Haigh
(e-mail address removed)

 

[Dan Pop]

I tend to use rather descriptive names for parameters, so the old style of
declaration appeals to me, as I can keep a declaration within 80 chars:

void * newKlElem (frame_size,num_blocks,num_frames,frame_locator)
size_t frame_size;
unsigned short num_blocks;

^^^^^^^^^^^^^^^^^^^^^^^^^

unsigned short num_frames;

^^^^^^^^^^^^^^^^^^^^^^^^^

Kl_frame_locator *locator;
{
/* code goes here */

I've found many who despise this sort of declaration, and also some who
say it's going to be deprecated in a future standard. Should I avoid
something like this, or keep doing as I please?

Do you realise that your function definition *requires* a new style
function declaration for newKlElem() to be in scope when the function
is called? Even if the function definition precedes the function call.

In the absence of such a declaration, the num_blocks and num_frames
arguments will be (most likely) promoted to int and there is nothing you
can do to prevent this (not even casts or variables of the expected
types help). This promotion results in undefined behaviour when the
function is called (argument/parameter type mismatch).

If you want to use old style function definitions/declarations, at least
use them correctly. And don't forget to lint your code (unless you're
the kind of programmer who never makes a mistake) because the compiler
is not required to perform any function call checks without a new
style function declaration in scope.

Dan

 

[Eric Sosman]

Do you realise that your function definition *requires* a new style
function declaration for newKlElem() to be in scope when the function
is called? Even if the function definition precedes the function call.

In the absence of such a declaration, the num_blocks and num_frames
arguments will be (most likely) promoted to int and there is nothing you
can do to prevent this (not even casts or variables of the expected
types help). This promotion results in undefined behaviour when the
function is called (argument/parameter type mismatch).

Argument promotion causes no undefined behavior here. The
promoted types don't need to match the argument types, they need
to match the *promoted* argument types (6.5.2.2/6).

If you want to use old style function definitions/declarations, at least
use them correctly. And don't forget to lint your code (unless you're
the kind of programmer who never makes a mistake) because the compiler
is not required to perform any function call checks without a new
style function declaration in scope.

He's using them correctly (as far as we can see, at any
rate: he hasn't shown us any calls to the function). But it's
a poor idea to discard a helpful feature just to make the source
formatting look "better" (de gustibus non disputandum est).

 

[CBFalconer]

I tend to use rather descriptive names for parameters, so the old
style of declaration appeals to me, as I can keep a declaration
within 80 chars:

void * newKlElem (frame_size,num_blocks,num_frames,frame_locator)
size_t frame_size;
unsigned short num_blocks;
unsigned short num_frames;
Kl_frame_locator *locator;
{
/* code goes here */

I've found many who despise this sort of declaration, and also
some who say it's going to be deprecated in a future standard.
Should I avoid something like this, or keep doing as I please?

Why not have the best of both worlds and write:

void *newKlElem(size_t frame_size; /* comment */
unsigned short num_blocks; /* comment */
unsigned short num_frames; /* comment */
Kl_frame_locator *locator) /* comment */
{
/* code goes here */
}

 

[E. Robert Tisdale]

Why not have the best of both worlds and write:

void* newKlElem( /* comment */
size_t frame_size; /* comment */
unsigned short num_blocks; /* comment */
unsigned short num_frames; /* comment */
Kl_frame_locator* locator /* comment */
) {
/* code goes here */
}

 

[Ben Pfaff]

[K&R-style function definitions]

I've found many who despise this sort of declaration, and also some who
say it's going to be deprecated in a future standard.

K&R-style function definitions have been obsolete since 1989; see
section 6.9.5 "Function definitions" in the C90 standard.

 

[John Bode]

I tend to use rather descriptive names for parameters, so the old style of
declaration appeals to me, as I can keep a declaration within 80 chars:

void * newKlElem (frame_size,num_blocks,num_frames,frame_locator)
size_t frame_size;
unsigned short num_blocks;
unsigned short num_frames;
Kl_frame_locator *locator;
{
/* code goes here */

I've found many who despise this sort of declaration, and also some who
say it's going to be deprecated in a future standard. Should I avoid
something like this, or keep doing as I please?

It's in your best interest to stop using the above style and start
using prototype syntax.

void * newKlElem (
size_t frame_size,
unsigned short num_blocks,
unsigned short num_frames,
Kl_frame_locator *locator)
{ /* code */ }

For one thing, prototype syntax saves keystrokes since you only have
to type the name of each parameter once. But more importantly, it
allows you to catch errors at compile time that the old-style syntax
won't.

 

[Arthur J. O'Dwyer]

No, he didn't write *quite* that. For one thing, his
comment blocks were lined up, and I'm fairly sure he
put the ) and the { on different lines, not being an
infidel and all that.
But did you have anything to say, or were you just
practicing cut-and-paste again?

-Arthur

 

[J. J. Farrell]

I tend to use rather descriptive names for parameters, so the old style of
declaration appeals to me, as I can keep a declaration within 80 chars:

void * newKlElem (frame_size,num_blocks,num_frames,frame_locator)
size_t frame_size;
unsigned short num_blocks;
unsigned short num_frames;
Kl_frame_locator *locator;
{
/* code goes here */

How is that better than

void * newKlElem (
size_t frame_size,
unsigned short num_blocks,
unsigned short num_frames,
Kl_frame_locator *locator )
{
/* code goes here */

which appears to give you far more space for descriptive parameter
names or long type names, while being very similar to your current
style? I find the latter far more readable since there is less
clutter.

The example you give is also invalid. Unless you have a prototype
in scope at the time of the call, it is not possible for your
function to receive parameters of type <unsigned short>. They will
have been promoted at the time of the call to be either <int> or
<unsigned int> depending on the type sizes in the implementation -
so to make your version portable, you need some ugly compile-time
duplication of the parameters in the function definition, or you
need to explicitly cast the parameters to an appropriate type in
each call.

The addition of function prototypes was probably the most valuable
change in the history of C. The advantages of checking the numbers
and types of parameters, and having explicit control of the types
that get passed, are immense - I've seen countless bugs get caught
this way.

I've found many who despise this sort of declaration, and also some who
say it's going to be deprecated in a future standard. Should I avoid
something like this, or keep doing as I please?

You can obviously do as you please, but if you did that in front
of me in an interview you wouldn't get hired - even if the error
in your example were corrected.

 

[Eric Sosman]

I tend to use rather descriptive names for parameters, so the old style of
declaration appeals to me, as I can keep a declaration within 80 chars:

void * newKlElem (frame_size,num_blocks,num_frames,frame_locator)
size_t frame_size;
unsigned short num_blocks;
unsigned short num_frames;
Kl_frame_locator *locator;
{

[...]

The example you give is also invalid. Unless you have a prototype
in scope at the time of the call, it is not possible for your
function to receive parameters of type <unsigned short>. They will
have been promoted at the time of the call to be either <int> or
<unsigned int> depending on the type sizes in the implementation -
so to make your version portable, you need some ugly compile-time
duplication of the parameters in the function definition, or you
need to explicitly cast the parameters to an appropriate type in
each call.

This is the second time this piece of misinformation has
cropped up in this thread. I can only conclude that people
have become so accustomed to prototyped functions (that's
understandable; they *are* better) that they've completely
forgotten how old-style functions worked.

For the record:

- Pre-Standard C is/was a language without function
prototypes, in which the O.P.'s style of function
definition is/was the only possible style, and

- In pre-Standard C it is/was possible to write a
function with promotable argument types like `char'
and `short' and `float', and to call such functions
even though the supplied values are/were subject to
promotion at the point of call, and

- Standard C retains the pre-Standard function style,
augmenting rather than supplanting it, and

- Pre-Standard functions and calls work in Standard C
just as they do/did in pre-Standard C.

Reference: ISO/IEC 9899:1999 (E), Section 6.5.2.2,
paragraph 6, sentences 1, 2 and 5:

If the expression that denotes the called function has
a type that does not include a prototype, the integer
promotions are performed on each argument, and arguments
that have type float are promoted to double. These are
called the default argument promotions. [...] If the
function is defined with a type that does not include a
prototype, and the types of the arguments after promotion
are not compatible with those of the parameters after
promotion, the behavior is undefined, [...]

In short, the types of the promoted arguments need not match the
types of the formal parameters, they need to match the *promoted*
types of those parameters.

People seem to have lost sight of the fact that although
Standard C was born in 1989, C itself had been around for some
dozens of weeks before that -- and yes, during that Paleozoic
time, young 'uns, it *was* possible to write C programs. Been
there, done that -- don't want to go back. Use prototypes.

 

[CBFalconer]

**** an entirely empty message ****

Which at least contained none of the usual Trollsdale errors or
misinformation. He restricted himself to reformatting the quote
without mentioning it. He is quite sneaky, because you have to
look twice to see what he did.

 

[Mark McIntyre]

I tend to use rather descriptive names for parameters, so the old style of
declaration appeals to me, as I can keep a declaration within 80 chars:

your reasoning is spurious. You can equally keep a proper prototyping
declaration within 80 chars too.

(snip 20 year old declaration style.)

I've found many who despise this sort of declaration, and also some who
say it's going to be deprecated in a future standard. Should I avoid
something like this, or keep doing as I please?

Its already deprecated, don't use it. You're doing the equivalent of
using a goose quill to write letters.

 

[Mark McIntyre]

Why not have the best of both worlds and write:

void *newKlElem(size_t frame_size; /* comment */
unsigned short num_blocks; /* comment */
unsigned short num_frames; /* comment */
Kl_frame_locator *locator) /* comment */

you may want to consider replacing those semicolons by commas tho...

 

[Chris Torek]

[this followup is also a test of trn-4.0-test76...]

In short, the types of the promoted arguments need not match the
types of the formal parameters, they need to match the *promoted*
types of those parameters.

Indeed. You may also write a prototype for a K&R-style
function, as long as you use those promoted types. For instance:

int f(c) char c; { ... } /* K&R declaration/definition */

which requires:

int f(int); /* not int f(char)! */

as its prototype. This assumes that plain char promotes to signed
int, which is true on any sensible hosted implementation -- but it
also points to the problem with writing prototypes for functions
like (to take a real example):

int chown(file, uid, gid)
char *file;
uid_t uid;
gid_t gid;
{
...
}

If uid_t is:

typedef short uid_t;

then the correct prototype uses "int", but if it is:

typedef unsigned short uid_t;

then it depends on whether USHRT_MAX > INT_MAX. If USHRT_MAX is
(say) 65535 and INT_MAX is 32767, as is true on the PDP-11, the
correct prototype uses "unsigned int" instead.

If uid_t is typedef'ed as signed or unsigned int, there is no
change in types between the K&R declaration and a prototype.

 

[CBFalconer]

you may want to consider replacing those semicolons by commas tho...

Eee-yup. That does tend to reduce the error listings

 

[Dan Pop]

Indeed. You may also write a prototype for a K&R-style
function, as long as you use those promoted types. For instance:

int f(c) char c; { ... } /* K&R declaration/definition */

which requires:

int f(int); /* not int f(char)! */

as its prototype.

But that would be misleading, given that the type of c is still char:

f.c:

#include <stdio.h>

int f(c)
char c;
{
return printf("%d\n", (int)c);
}

main.c:

int f(int);
int main()
{
f(1000);
return 0;
}

I'm not sure about the behaviour of this code in K&R C, which talks about
float parameters getting widened to double, but no mention about char and
short parameters getting promoted to int.

Dan

 

[Alan Balmer]

Indeed. You may also write a prototype for a K&R-style
function, as long as you use those promoted types. For instance:

int f(c) char c; { ... } /* K&R declaration/definition */

which requires:

int f(int); /* not int f(char)! */

Some compilers at least, in K&R mode, complain about anything other
than int f();