Messages in this thread |  | | | Date | Thu, 19 Nov 1998 16:09:00 +1300 | | From | Gevan <> | | Subject | Re: [PATCH] Re: [ipchains] logging tcp/udp port numbers |
| |
Quoting Linus Torvalds (torvalds@transmeta.com), twice:
>>> 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/
|  |