All of lore.kernel.org
 help / color / mirror / Atom feed
From: Paul Brook <paul@codesourcery.com>
To: qemu-devel@nongnu.org
Cc: Sylvain Petreolle <spetreolle@users.sourceforge.net>,
	Mike Frysinger <vapier@gentoo.org>
Subject: Re: [Qemu-devel] [patch] use socklen_t with getsockopt()
Date: Fri, 6 Apr 2007 22:59:00 +0100	[thread overview]
Message-ID: <200704062259.01789.paul@codesourcery.com> (raw)
In-Reply-To: <200704061751.28458.vapier@gentoo.org>

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	other threads:[~2007-04-06 22:02 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-05  8:43 Re : [Qemu-devel] [patch] use socklen_t with getsockopt() Sylvain Petreolle
2007-04-05 10:42 ` Jamie Lokier
2007-04-06 21:51   ` Mike Frysinger
2007-04-06 21:59     ` Paul Brook [this message]
2007-04-10 10:59     ` Jamie Lokier
  -- strict thread matches above, loose matches on Subject: below --
2007-06-23 18:27 Mike Frysinger
2007-03-31  8:24 Mike Frysinger
2007-04-01 18:43 ` Thiemo Seufer
2007-04-01 22:25   ` Mike Frysinger

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200704062259.01789.paul@codesourcery.com \
    --to=paul@codesourcery.com \
    --cc=qemu-devel@nongnu.org \
    --cc=spetreolle@users.sourceforge.net \
    --cc=vapier@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.