Newsgroups: comp.lang.c Path: utzoo!utgpu!jarvis.csri.toronto.edu!dgp.toronto.edu!flaps From: flaps@dgp.toronto.edu (Alan J Rosenthal) Subject: Re: Variadic argument functions (Was Re: cdecl keyword) Message-ID: <8804170150.AA05741@caboto.dgp.toronto.edu> Organization: University of Toronto References: <1238@wjvax.UUCP> <297@ho7cad.ATT.COM> <1242@wjvax.UUCP> <7667@brl-smoke.ARPA> <253@teletron.UUCP> Date: Sat, 16 Apr 88 19:50:05 EDT In article <253@teletron.UUCP> andrew@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.