On Fri, 2013-01-04 at 10:05 +0200, John Hay wrote: > 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. Good point - I see what you're saying. Amos - given the (probably) small quantity of TOS configuration values, do you think it's worth changing tos_t back to an int for all operating systems, as it was in v3.1? This reduces the complexity of having different types for different operating systems, saves the overhead of initiating a new value for *BSD each time its used, and as John says it probably doesn't come at much (if any) of a price in terms of memory usage. Andy
