>>> it (ie instead of using
>>>
>>> num = va_arg(args, short);
>>>
>>> it might be proper to use
>>>
>>> num = (short) va_args(args, int);
> Yes, I'm almost positive that the second version is always correct due to
> the C language rules about integer promotions.
That seems to be the case. Of course, I'm assuming that the actual
argument is a short, because I haven't seen the original mail. =)
> However, I also suspect that the first version really _should_ work, and
> that it really is a problem in gcc or the varargs header files that makes
> it not work.
I don't think it's guaranteed to work. Unfortunately I don't have
access to the current C standard, but I let memory and the C9x draft
guide me.
> Alternatively, I'd really like to know whether maybe the C standard really
> says that you _have_ to use the second form. It's possible it does.
Here're a couple of relevant extracts:
The ellipsis notation in a function prototype
declarator causes argument type conversion to stop after the
last declared parameter. The default argument promotions
are performed on trailing arguments.
In this context "default argument promotions" means the integer
promotions, as you mention above.
With reference to va_arg(va_list ap, type):
...if type is not compatible with the type of the actual
next argument (as promoted according to the default argument
promotions), the behavior is undefined.
Note that "compatible with" basically means "the same as"; it's rather
strict by definition.
i.e., the first form above *may* invoke undefined behaviour, but the
second one is guaranteed to work for any type that would be promoted
to an int by the default argument promotions.
To be taken with a grain of salt, at least. Someone may wish to
expose my ignorance.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/