Re: socklen_t (Re: Multicast problems [PATCH])

On Wed, 20 Jun 2007, Harti Brandt wrote:

> On Wed, 20 Jun 2007, Daniel Eischen wrote:
>
> DE>On Wed, 20 Jun 2007, Stefan Farfeleder wrote:
> DE>
> DE>> On Tue, Jun 19, 2007 at 06:36:39PM -0400, Daniel Eischen wrote:
> DE>>
> DE>> >  POSIX states that:
> DE>> >
> DE>> >    o The <sys/socket.h> header shall define the type socklen_t,
> DE>> >      which is an integer type of width of at least 32 bits; see
> DE>> >      APPLICATION USAGE.
> DE>> >
> DE>> >  and goes on to state:
> DE>> >
> DE>> >    o The <sys/socket.h> header shall define the unsigned integer
> DE>> >      type sa_family_t.
> DE>> >
> DE>> >  This seems to imply that our socklen_t should not be an unsigned
> DE>> >  integer (uint32_t), but a signed integer.  In APPLICATION USAGE,
> DE>> >  POSIX states:
> DE>>
> DE>> I don't understand how you come to that conclusion.  Why does not
> DE>> mentioning whether socklen_t is signed or unsigned imply it should be
> DE>> signed?
> DE>
> DE>Because it explicitly says unsigned for sa_family_t and does not
> DE>say unsigned for socklen_t.  To me, "integer" means a C (signed)
> DE>integer.  The fact that older APIs and implementations used "int"
> DE>might support the argument to use int32_t just for compatibility
> DE>reasons.  As it stands now, portable code has to have some sort
> DE>of autoconfig to determine whether or not to use socklen_t or int.
> DE>I don't see how you can do this with #ifdefs unless you know
> DE>OS version numbers and when socklen_t first got introduced.
>
> In standardese stating 'integer type' means any integer type. It does not
> imply signed or unsignedness. You might look at paragraph 14 of 6.2.5 of
> the C standard: "The type char, the signed and unsigned integer types, and
> the enumerated types are collectively called integer types."

Ok, but it still makes it difficult to write portable code.

I do not care so much about this to argue it, so consider the
subject dropped :-)

-- 
DE