Re: Importing C function with variable argument list

[David Thompson <dave.thompson2@verizon.net>]

On Thu, 3 May 2012 13:15:09 -0700 (PDT), sbelmont700@gmail.com wrote:

> On Friday, April 27, 2012 4:24:59 AM UTC-4, Natasha Kerensikova wrote:
> > Of course, on platforms where calling convention transmits C.short
> > arguments exactly like C.int (e.g. for improved alignment, or because
> > the platform has C.short equivalent to C.int (but then you could use
> > C.char instead of C.short, since C.char is guaranteed to be strictly
> > smaller than C.int on conforming hosted implementations)).
> 
> Isn't the general rule of thumb (since nothing in C is ever well-defined) 
that an int is the size of the default machine word (32-bit on 32-bit,
64 on 64, etc)?  If that's the case, whether it's stack or register,
the calling convention is very likely going to use an int sized
argument for anything smaller than an int anyway (e.g. if it uses the
32-bit stack, it would have to push a one-byte char as an int-sized
value anyway).

Yes. There are _some_ things well-defined in C (not nearly all), but
to your main point, 6.2.5p5 (formerly 6.1.2.5) says: A [signed] int
object has the natural size suggested by the architecture of the
execution environment (large enough to contain any value in the range
INT_MIN to INT_MAX as defined in the header <limits.h>). And p6 says
that unsigned int has the same size as signed int, and 5.2.4 requires
(without explicitly saying so) that size be at least 16 bits.

Technically this is normative text but there is no formal definition
of 'natural' so it can't actually be verified/enforced. And there are
machines where there can be legitimate controversy which of two (or
even more) widths is more natural. But where the machine does have a
word size, it is >= 16, and a C implementor doesn't use it for int,
they deserve to be tarred and feathered (not gzipped! <G>).

And yes, for all ABIs I've seen and most I can imagine, this means
that C.char and C.short will be passed the same as C.int, even though
formally they have different types in C (as well as Ada). However, the
default argument promotions in C (for varargs and also K&R1, as PP
correctly noted) also take 'float' to 'double'; it is fairly common
(though not required) for these to be passed differently in C, and
thus probably demonstrate PP's issue.

Also it isn't absolutely guaranteed that C char is smaller than int
(or more precisely that sizeof(int)>1). c.l.c loves to discuss offbeat
architectures like DSPs where it may actually make sense to have
char=short=int all 22-bit or somesuch, and thus 110%-portable code
can't assume that getchar()==EOF isn't actually a data character and
must 'confirm' it with feof() and/or ferror(). In practice no one has
reported any system where it both makes sense to have (C) char other
than 8 or at most 9 bits, and using stdio makes any sense at all.