On Thu, Jan 03, 2013 at 03:41:52PM +0000, Andrew Beverley wrote: > On Thu, 2013-01-03 at 08:13 +0200, John Hay wrote: > > > Again, no official documentation found, but I found other bug reports in > > > software packages for a variety of BSD operating systems, so I think it > > > should apply to any BSD derivative (including OSX). > > > > Doing a google of "setsockopt freebsd" and "setsockopt netbsd" point > > directly to their man pages > > Yeah, thanks, I had already RTFM ;-) > > I expected something specific for IP_TOS though, given that it's always > exactly an 8 bit value. > > > Most socket-level options utilize an int argument for optval. For > > setsockopt(), the argument should be non-zero to enable a boolean option, > > or zero if the option is to be disabled. SO_LINGER uses a struct linger > > argument, defined in <sys/socket.h>, which specifies the desired state of > > the option and the linger interval (see below). SO_SNDTIMEO and > > SO_RCVTIMEO use a struct timeval argument, defined in <sys/time.h>. > > But you're right: "most options utilise an int" should probably be > interpreted as "all options utilise an int unless otherwise specified". Looking at a linux man page: http://linux.die.net/man/2/setsockopt I see the same kind of text: Most socket-level options utilize an int argument for optval. For setsockopt(), the argument should be nonzero to enable a boolean option, or zero if the option is to be disabled. So maybe it is just luck that the current code does work and all of them actually expects it in an int. :-) I think it started because of hysterical raisins, from the days before function prototypes, but even the examples in recentish rfcs (3493 and 3542) that describe IPv6 usage, use an int in all their examples that will fit in an int. Also a plain int is used and not a int32, probably because a native int is assumed to be the most efficient size. Regards John -- John Hay -- jhay@xxxxxxxxxxxxxxxxx / jhay@xxxxxxxxxxx
