> In message <200001210533.OAA04917@srapc342.sra.co.jp>, Noriyuki Soda writes:
> >It is not so rare, programmers who don't understand default promotion
> >might easily produce this kind of problems.
> >And because this is ABI issue, the wrapper library maitanance is too
> >hard to do. I think K&R style is far easy to keep ABI.
> 
> I suppose, but it is inefficient and obsolete.

All we knows that K&R style is obsolete.
But what I'm talking is "keeping ABI".

For static functions, I don't care whether ANSI style or K&R.
But for global functions which are related to ABI, we should not use
"short" and "char" argument. Since "short" and "char" argument has
ABI problem.

And if we don't use "short" and "char" argument, the "inefficient"
issue doesn't matter, because K&R style function exactly produce
same performance as ANSI style does.

> >Which spec?
> >As Chris Torek wrote in Message-Id: <200001190230.TAA19047@forge.BSDI.COM>,
> >K&R style and ANSI prototype is no problem from ANSI/ISO-C standard POV.
> 
> I'd have to disagree with Chris.

You are wrong, then. :-)

> I don't do this lightly, but I'm pretty
> sure that it's a conflict.  Of course, it's only a conflict in the cases
> where the promotions are different, but
> 	int foo(s)
> 		short s;
> 	{
> 	}
> declares foo to take an *int* argument, for purposes of the rest of the code.

Yes, thus, prototype should be defined as follows. (as Chris said.)
	int foo __P((int));

If you try to define as follows:
	int foo __P((short));
then *YOU MADE ABI PROBLEM*.

> If, elsewhere, you say
> 	int foo(short);
> you are allowed to be using different calling conventions.

And breaks ABI compatibility.

So, it is better to use K&R style for global functions which are
related to ABI (e.g. functions declared in /usr/include, and kernel
functions which can be called from device drivers and 3rd party
filesystems).  Because K&R style automatically detects ABI problem
like above.
--
soda