Re: setsockopt() compat issue

[Alan Barrett <apb%cequrux.com@localhost>]

On Sun, 19 Oct 2008, Joerg Sonnenberger wrote:
> On Sun, Oct 19, 2008 at 01:07:22PM +0200, Johnny Billquist wrote:
> > How about the fact that the C standard says that an int should be the  
> > "native word size of the hardware"?
> 
> Where? I can find only a single place where "native" is used in the C99
> specification

Section 6.2.5 of the C99 standard (actually the n1124 draft) says "A
``plain'' int object has the natural size suggested by the architecture
of the execution environment".

> and it should be noted that e.g. sizeof() is specified to
> return size_t, not int. That makes it pretty clear that none of the
> standard types is guarantied to always have the same size as a pointer
> or even an index.

Right.  Even intptr_t is not guaranteed to be the same size as a
pointer; it's large enough for lossless conversions back and forth
between "valid" pointers and intptr_t, but it could be larger than a
pointer, or if valid pointers have a representation in which some bits
are unused or redundant then I believe that it's possible for intptr_t
to be smaller than a pointer (provided the C implementation knows how to
reinstate the extra bits in a lossless way).

> The very concept of "native word size" is fuzzy, as soon as hardware has
> registers of different sizes. For most purposes size_t is reasonable,
> but not always. It can be more efficient to use shorter registers, e.g.
> on AMD64 you get shorter opcodes.

That's also true.  If the architecture suggests multiple "natural" sizes
(e.g. if both 32 and 64 bit registers appear equally "natural") then the
C implementation can presumably pick any of the appropriate sizes for
"int" without violating the requirement.

--apb (Alan Barrett)