Re: SSH_BIND_OPTIONS_BINDPORT type confusion

[Andreas Schneider <asn@xxxxxxxxxxxxxx>]

On Thursday 01 May 2014 05:21:14 Mike Jones wrote:
> Hello,
> 
> I don't consider this a bug in any way because it is clearly documented
> (and I need to learn to read better... <ahem>).
> When setting up a server and defining the port number to be used,
> ssh_bind_options_set() takes an 'unsigned int'.
> 
> SSH_BIND_OPTIONS_BINDPORT The port to bind (unsigned int)
> 
> Port numbers range from [0..65535] which fits in an unsigned short.
> That's how my particular application stores them.
> 
> The documentation says the parameter is 'unsigned int', but the function
> actually  takes the value as a void pointer.
> You can pass in anything, but the code inside the function will cast
> that to an (int *) and then mask off the low-order 2 bytes (i.e. back to
> an unsigned short).
> 
> unsigned short port = 2000;
> ssh_bind_options_set( SSH_BIND_OPTIONS_BINDPORT, &port );  // oops...
> &port will be cast to (int *) inside
> 
> On a little-endian (e.g. Intel x86) platform, we get away with this.
> On a big-endian (e.g. Sun sparc) platform, the cast to (int *) changes
> the byte order and it ends up masking off the other 2 bytes of whatever
> happens to be there on the stack next to the short, which is the wrong
> value, of course.
> 
> My "fix" was to just introduce a temporary variable of type int, which
> pleases both architectures.
> 
> I am just curious to understand why this would not be passed as an
> 'unsigned short' to avoid confusion and the potentially problematic
> cast/masking.

I think a patch to use an 'unsigned short' instead of an 'int' would be great. 
Please also check the client options. I think it is an integer there too.


	-- andreas



-- 
Andreas Schneider                   GPG-ID: CC014E3D
www.cryptomilk.org                asn@xxxxxxxxxxxxxx