Variadic argument functions (Was Re: cdecl keyword)

[Alan J Rosenthal]

In article <253 at teletron.UUCP> andrew at teletron.UUCP (Andrew Scott) writes:
>	void (*vector)();
>	int arg;
>
>	(*vector)(arg);
>
...
[ possible values of `vector' are the following two functions: ]
>
>	void funcA(arg)
>	int arg;
>	{
>		/* do something */
>	}
>
>	void funcB()
>	{
>		/* do something else */
>	}
>
...
>should I re-work it so that all possible functions assigned to the
>vector have exactly one integer argument, as to be consistent with the
>vector call?

I argue that as is it is fine K&R C (if you like, "pre-ansi C").
Others here have recently disagreed with me.

It definitely is invalid ANSI C and should be re-worked as you say.
You may also want to change the declaration of vector to something more
like "void (*vector)(int);".

>Also, I have a totally unrelated question...
>Suppose one (integer) argument is limited to values in the range
>0..1000.  Should the argument be of type short, to emphasize the range
>of the argument?  Or should I use ints everywhere and simply document
>the range of acceptable argument values?  How about function return
>values?

The argument is not of type short.  If you examine the default
arithmetic promotions, you will see that shorts in an expression become
ints.  Therefore it is impossible to actually pass a short, since the
mention of a short is an int-valued, not short-valued, expression.[1]
In other words, "SHOULD the argument be of type short" is not the question.

[ Also, you would still have to document the range limitation, as
``short'' allows -32768 to 32767, not just 0 to 1000. ]

Unfortunately, compilers do not give an error message for a declaration
such as

	int f(x)
	    short x;
	{
	    ...
	}

In fact, K&R, and all current practice, makes it quite clear that the
short declaration is simply rewritten to be an int declaration.
(The same behaviour happens for array formal declarations, which are
rewritten as pointer declarations due to the conversion of array names
to pointers in expressions.)

I think that this rewriting is bizarre, but some people take advantage
of it for "comment" purposes.  You may choose to use "short" for this
purpose in your functions, but I would recommend against it as this
bizarre rewriting can cause some strange facts.  For example, within
the function `f' as defined above, the call ``scanf("%hd",&x)'' would
be invalid as x is not a short, it is an int.

Now as for function return values, the situation is not quite the
same.  For these I would argue for using int rather than char or short
for the same reason I would argue against using char or short for
single variables (i.e. when they're not part of a larger object like an
array).  This is simply that since they keep getting converted to ints
for calculations, it really isn't helpful to merely store them as
smaller objects.  In the case of function return values which are
probably just in a register somewhere anyway, the advantage then
becomes zero and the penalty remains non-zero.

ajr

--
[1] In ANSI-compatible compilers it will be possible to pass shorts and
chars, by using the Pascal-style declarations.  This is used in some of
the library functions.  Obviously, some people consider this advantageous.
I personally can only see the advantage on 8-bit machines.
--
Make:  Don't know how to keep up with all the new features.  Stop.