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@xxxxxxxxxxxxxxxxx / jhay@xxxxxxxxxxx
