qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [patch] use socklen_t with getsockopt()


From: Paul Brook
Subject: Re: [Qemu-devel] [patch] use socklen_t with getsockopt()
Date: Fri, 6 Apr 2007 22:59:00 +0100
User-agent: KMail/1.9.5

On Friday 06 April 2007 22:51, Mike Frysinger wrote:
> On Thursday 05 April 2007, Jamie Lokier wrote:
> > Sylvain Petreolle wrote:
> > > Was incorrect before too, since it was sizeof(int) in the first place ?
> >
> > The old type of "val" was "int", so it made no different to the size.
> > When "val" is of type socklen_t, it matters.
>
> val is still of type int which is fine ... socklen_t is for the variable
> which describes the length of val

It's worth noting that socklen_t should be "int" anyway.
From the accept(2) manpage:

NOTE
       The  third  argument  of accept() was originally declared as an `int *'
       (and is that under libc4 and libc5 and on many other systems  like  4.x
       BSD,  SunOS 4, SGI); a POSIX.1g draft standard wanted to change it into
       a `size_t *', and that is what it is for SunOS 5.  Later  POSIX  drafts
       have `socklen_t *', and so do the Single Unix Specification and glibc2.
       Quoting Linus Torvalds:

       "_Any_ sane library _must_ have "socklen_t" be the same  size  as  int.
       Anything  else  breaks any BSD socket layer stuff.  POSIX initially did
       make it a size_t, and I (and hopefully others, but  obviously  not  too
       many)  complained  to  them  very loudly indeed.  Making it a size_t is
       completely broken, exactly because size_t very seldom is the same  size
       as  "int"  on  64-bit architectures, for example.  And it has to be the
       same size as "int" because that's what the  BSD  socket  interface  is.
       Anyway,   the   POSIX   people  eventually  got  a  clue,  and  created
       "socklen_t".  They shouldn't have touched it in the  first  place,  but
       once  they  did  they felt it had to have a named type for some unfath-
       omable reason (probably somebody didn't like losing  face  over  having
       done  the  original  stupid  thing, so they silently just renamed their
       blunder)."




reply via email to

[Prev in Thread] Current Thread [Next in Thread]