Subject: Re: C Language Standard(s)
To: None <current-users@NetBSD.ORG>
From: Simon J. Gerraty <sjg@frodo.dn.itg.telecom.com.au>
List: current-users
Date: 01/10/1996 19:08:53
[This discussion probably belongs in comp.lang.c so I appologise for
dragging it out and wasting everyone's bandwidth... After this I'll
try and keep my mouth shut... :-)]

>    But less ugly than 
>    
>    #ifdef __STDC__
>    int foo(short x)
>    #else
>    int foo(x) short x;
>    #endif
>    {
> 
> but how *else* do you do this correctly, for it to work with both
> k&r compilers and "strict ansi" ones ?

My whole point is that you _can't_ do it correctly.  The example I
gave above is incorrect - or rather of questionable (certainly not
portable) behavior in the case of the K&R compiler, and best avoided
altogether.

Any old style function definition that claims sub-int args, such as
the above is dubious at best.

If you decide that you want code that will work "as expected" with a
K&R compiler, then the _only_ guaranteed method is:

int foo(x)
	int x;
{
	short s = some suitable manipulation of x;
}

C has sub-int objects for dealing with the real world.  Using them for
other purposes is usually counter productive (eg if performance is of
interest).  An int is (should be) the natural word size of the
processor and be the object that it deals with most efficiently.
Using sub-int interators etc can greatly slow down some processors.

If you adopt the ANSI style definitions so that you can have pid_t as
a short - then you can no longer unproto it and be sure that it will
still work - without first fixing all the sub-int args.

You either chose to implement code that will work no matter what - in
which case the old style definitions lose you nothing, or you chose to
define functions that take sub-int args in which case only an ANSI
compiler will do the right thing - and then only if there is a
correct prototype in scope at the time of the function call.

And since some one asked, the latest versions of HP-UX 9 and SunOS 4
both ship with only a K&R compiler.

Most of the code I write must work on *BSD, HP-UX, SunOS and just
about every other flavour of *nix.  So I write code that will work
with K&R compilers and I use __P() to get benefits from ANSI
compilers. 


--sjg