On Fri, Jan 04, 2013 at 07:36:35AM +0000, Andrew Beverley wrote:
> On Fri, 2013-01-04 at 06:31 +0200, John Hay wrote:
> > 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.
>
> Ah, interesting, I have to admit that I didn't read the Linux man page.
>
> > So maybe it is just luck that the current code does work and all of them
> > actually expects it in an int. :-)
>
> That said, when I was searching the BSD options, I did read somewhere
> that Linux started accepting a char value after a certain kernel
> version.
>
> > 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.
>
> Interesting - maybe I should have kept it as an int all along :)
Rereading my own paragraph, maybe an extra comment. What I meant with most
efficient size, was going through the setsockopt call. If you want to store
many of these in an array, a char will be the most space efficient, but
going through the setsockopt() call, a char will not give you any advantage,
if you look at how processors do register and stack operations.
John
-- John Hay -- jhay_at_meraka.csir.co.za / jhay_at_FreeBSD.orgReceived on Fri Jan 04 2013 - 08:05:23 MST
This archive was generated by hypermail 2.2.0 : Sat Jan 05 2013 - 12:00:04 MST