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?

--
Mike's Patented Blocklist; compile with gcc:

i=0;o(a){printf("%u",i>>8*a&255);if(a){printf(".") ;o(--a);}}
main(){do{o(3);puts("");}while(++i);}

[Jack Klein]

On Sun, 07 Dec 2003 23:13:17 -0800, "Michael B."
<us*****@spamblocked.com> wrote in comp.lang.c:

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.

--
There's nothing so precious as a cafe full of Gap kiddies trying to
work out whether you're really wearing rubber pants.
-- Mike Smith

[Mark F. Haigh]

Michael B. wrote:

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
mf*****@sbcglobal.net

[Dan Pop]

In <pa****************************@spamblocked.com> "Michael B." <us*****@spamblocked.com> writes:

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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Eric Sosman]

Dan Pop wrote:

In <pa****************************@spamblocked.com> "Michael B." <us*****@spamblocked.com> writes:

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).

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).

--
Er*********@sun.com

[CBFalconer]

"Michael B." wrote:

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 */
}

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[E. Robert Tisdale]

CBFalconer wrote:

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]

"Michael B." <us*****@spamblocked.com> writes:

[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.
--
int main(void){char p[]="ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuv wxyz.\
\n",*q="kl BIcNBFr.NKEzjwCIxNJC";int i=sizeof p/2;char *strchr();int putchar(\
);while(*q){i+=strchr(p,*q++)-p;if(i>=(int)sizeof p)i-=sizeof p-1;putchar(p[i]\
);}return 0;}

[John Bode]

"Michael B." <us*****@spamblocked.com> wrote in message news:<pa****************************@spamblocked.c om>...

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]

On Mon, 8 Dec 2003, E. Robert Tisdale wrote:

CBFalconer wrote:

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 */
}

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]

"Michael B." <us*****@spamblocked.com> wrote in message news:<pa****************************@spamblocked.c om>...

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]

"J. J. Farrell" wrote:

"Michael B." <us*****@spamblocked.com> wrote in message news:<pa****************************@spamblocked.c om>...

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.

--
Er*********@sun.com

[CBFalconer]

"E. Robert Tisdale" wrote:

CBFalconer wrote:

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 */
}

**** 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.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Mark McIntyre]

On Sun, 07 Dec 2003 23:13:17 -0800, in comp.lang.c , "Michael B."
<us*****@spamblocked.com> wrote:

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
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

[Mark McIntyre]

On Mon, 08 Dec 2003 16:57:23 GMT, in comp.lang.c , CBFalconer
<cb********@yahoo.com> wrote:

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...

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

[Chris Torek]

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

In article <news:3F***************@sun.com>
Eric Sosman <Er*********@Sun.COM> writes:

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.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[CBFalconer]

Mark McIntyre wrote:

<cb********@yahoo.com> wrote:

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...

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

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Dan Pop]

In <br*********@enews2.newsguy.com> Chris Torek <no****@torek.net> writes:

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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Alan Balmer]

On 9 Dec 2003 05:00:53 GMT, Chris Torek <no****@torek.net> wrote:

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();
--
Al Balmer
Balmer Consulting
re************************@att.net

[Kevin D. Quitt]

On Tue, 09 Dec 2003 07:27:56 GMT, CBFalconer <cb********@yahoo.com> wrote:

Mark McIntyre wrote:

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

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

Curious that Mr t missed that. OTOH, maybe he didn't - I don't get his
posts for some reason.

--
#include <standard.disclaimer>
_
Kevin D Quitt USA 91387-4454 96.37% of all statistics are made up
Per the FCA, this address may not be added to any commercial mail list

[Dan Pop]

In <ru********************************@4ax.com> Alan Balmer <al******@att.net> writes:

On 9 Dec 2003 05:00:53 GMT, Chris Torek <no****@torek.net> wrote:

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();

He wasn't talking about K&R C programs, but about standard C programs
using K&R function definitions. It is perfectly legal to have a
K&R function definition and a prototype declaration for it in a standard
C program.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Alan Balmer]

On 9 Dec 2003 18:50:46 GMT, Da*****@cern.ch (Dan Pop) wrote:

In <ru********************************@4ax.com> Alan Balmer <al******@att.net> writes:

On 9 Dec 2003 05:00:53 GMT, Chris Torek <no****@torek.net> wrote:

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();

He wasn't talking about K&R C programs, but about standard C programs
using K&R function definitions. It is perfectly legal to have a
K&R function definition and a prototype declaration for it in a standard
C program.

Dan

Missed that. Dunno why we're talking about it anyway ;-) I wouldn't
bother inventing prototypes for K&R function definitions without
changing the definitions as well.

--
Al Balmer
Balmer Consulting
re************************@att.net

[Chris Torek]

>In <br*********@enews2.newsguy.com> Chris Torek <no****@torek.net> writes:

... For instance:
int f(c) char c; { ... } /* K&R declaration/definition */
... requires:
int f(int); /* not int f(char)! */
as its prototype.

In article <news:br**********@sunnews.cern.ch>
Dan Pop <Da*****@cern.ch> writes:But that would be misleading, given that the type of c is still char:
[long program, reformatted a bit for vertical compression]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.

Narrow parameters behave as if converted twice, once with "the
default argument promotions", and then back to the narrow type in
the K&R function definition. Thus, this is the same as an ANSI C
program that reads, for f.c:

#include <stdio.h>
int f(int c0) { char c = c0; return printf("%d\n", (int)c); }

The same trick applies to short and float, of course.

There was at least one implementation of K&R C on a big-endian
machine that failed to "convert back" correctly, so that in any
actual function written as:

f(c) char c; { ... }

&c was the wrong one of the four bytes (it was an 8-bit-char,
32-bit-int compiler). I am not sure if somehow the compiler managed
to use all four bytes when producing c's value in most contexts,
but I do remember that, while some code broke in interesting ways,
a surprising amount still worked anyway. (But everyone who used
that compiler agreed that it was broken, and that &c should have
been the address of the low byte of the widened stack copy of the
value.)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[J. J. Farrell]

Eric Sosman <Er*********@sun.com> wrote in message news:<3F***************@sun.com>...

"J. J. Farrell" wrote:

"Michael B." <us*****@spamblocked.com> wrote in message news:<pa****************************@spamblocked.c om>...

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.

Apologies for the misinformation. The curious thing is that
I remember what I said from way back then. Whether it was a
peculiarity of a certain compiler, or a failure in the teaching
or learning process, is something now lost in the mists of time.
...
- Pre-Standard functions and calls work in Standard C
just as they do/did in pre-Standard C.
Ahhh - but since they were pre-standard, we can't be sure they
all behaved the same way! I notice that Chris has mentioned a
compiler where my comment was effectively true. Perhaps I (or
whomever I picked this up from) had had dealings with a similar
compiler. Or, more likely, my brain has atrophied.
... Use prototypes.

Invariably. Except, perhaps ... are there any circumstances under
which people think it's appropriate to not use prototypes? The
only one that comes to mind is a generic function pointer.

[lawrence.jones]

Dan Pop <Da*****@cern.ch> wrote:

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.

As far as I know, all pre-ANSI compilers widened char and short
arguments to int (even if char was unsigned -- the first hint of
value-preserving conversion rules!). Behavior varied for unsigned char
and unsigned short: some compilers didn't support them at all, most
compilers widened them to unsigned int, a few (or maybe just one) used
ANSI-like value-preserving rules and widened them to either int or
unsigned int depending. Behavior also varied for the parameter
declarations -- some compilers converted the widened types back to the
declared types, other compilers quietly rewrote the parameter
declarations using the widened types (much as array declarations are
quietly rewritten as pointer declarations).

-Larry Jones

That's one of the remarkable things about life. It's never so
bad that it can't get worse. -- Calvin

[Dan Pop]

In <5c**************************@posting.google.com > jj*@bcs.org.uk (J. J. Farrell) writes:

... Use prototypes.

Invariably. Except, perhaps ... are there any circumstances under
which people think it's appropriate to not use prototypes? The
only one that comes to mind is a generic function pointer.

This is also the only counterexample I am aware of. But it doesn't
affect function *definitions*.

I'm also too lazy to type the void in the main function definition, when
I don't need its parameters, which turns it into a K&R function
definition. But that's OK, since I never call main() in my programs and
its actual caller couldn't care less about how I define it.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Dan Pop]

In <br*********@enews4.newsguy.com> Chris Torek <no****@torek.net> writes:

In <br*********@enews2.newsguy.com> Chris Torek <no****@torek.net> writes:

... For instance:
int f(c) char c; { ... } /* K&R declaration/definition */
... requires:
int f(int); /* not int f(char)! */
as its prototype.

In article <news:br**********@sunnews.cern.ch>
Dan Pop <Da*****@cern.ch> writes:

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

[long program, reformatted a bit for vertical compression]

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.

Narrow parameters behave as if converted twice, once with "the
default argument promotions", and then back to the narrow type in
the K&R function definition. Thus, this is the same as an ANSI C
program that reads, for f.c:

#include <stdio.h>
int f(int c0) { char c = c0; return printf("%d\n", (int)c); }

The same trick applies to short and float, of course.

Not to float! K&R1, page 205:

C converts all float actual parameters to double, so formal parameters
declared float have their declaration adjusted to read double.

It is precisely this text that prompted by doubts about the handling of
char and short parameters in K&R C, because their declarations could be
adjusted to int for precisely the same rationale as floats being
adjusted to doubles, but I couldn't find any mention about this hapenning.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Dan Pop]

In <k3************@jones.homeip.net> la************@eds.com writes:

Dan Pop <Da*****@cern.ch> wrote:

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.
As far as I know, all pre-ANSI compilers widened char and short
arguments to int (even if char was unsigned -- the first hint of
value-preserving conversion rules!).

This part is clear, the argument conversions are well documented by K&R1.
Behavior varied for unsigned char
and unsigned short: some compilers didn't support them at all, most
compilers widened them to unsigned int, a few (or maybe just one) used
ANSI-like value-preserving rules and widened them to either int or
unsigned int depending.
These types were a mess back then. K&R1 doesn't support them so the only
hope to write portable code was to ignore them completely.
Behavior also varied for the parameter
declarations -- some compilers converted the widened types back to the
declared types, other compilers quietly rewrote the parameter
declarations using the widened types (much as array declarations are
quietly rewritten as pointer declarations).

This is the less clear part. K&R1 Appendix A explicitly mentions float
parameter declarations being rewritten as double, but doesn't mention
char and short. OTOH, there is the following text at page 42, right
after the definition of the argument conversions:

This is why we have declared function arguments to be int and double,
even when the function is called with char and float.

Kernighan is obviously talking about function parameters. It's for this
reason that I never declared function parameters as char, short or
float back when I was writing K&R C programs. And now it's too late to
investigate what would have happened if I did ;-(

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de