Subject: Re: standards/12703: gethostbyaddr len paramter has incorrect type
To: None <simonb@wasabisystems.com>
From: Greg A. Woods <woods@weird.com>
List: netbsd-bugs
Date: 04/19/2001 15:07:22
[ On Friday, April 20, 2001 at 02:07:14 (+1000), simonb@wasabisystems.com wrote: ]
> Subject: standards/12703: gethostbyaddr len paramter has incorrect type
>
> 	Two ABI issues come to mind - changing from a signed type to
> 	an unsigned type (size_t is unsigned on all platforms), and

There shouldn't be any ABI issue here as far as I can tell.  Signed and
unsigned values of the same base type are of equal width and if any type
coercion occurs it will always be done the same way in the calling
binary despite how it might be interpreted in the called function.

There might be an API issue if a program fails to use the proper cast
and type coercion occurs due to a prototype, but even then going from a
signed to an unsigned value shouldn't change anything unless the code
tries to actually pass a negative value (though I would expect the
result to be undefined in most cases anyway -- gethostbyaddr will
probably walk all over the designated storage space if it's not actually
allocated large enough and if the caller tries to specify a negative
size because the interpretation on the other side of the call will be
that the size is a very large value).

In the current implementation it appears that if the value of 'len'
isn't specified exactly correctly for the desired 'af' then the code
returns EINVAL anyway.

> 	changing from an int size type to a long sized type.  The only
> 	ports where size_t is long are alpha, sparc, sparc64 and ELF-vax

Is sizeof(long) != sizeof(int) on any of alpha, sparc, sparc64, or
ELF-vax?  My guess would be that this is only true on sparc64, but I'm
not 100% sure of alpha....

I.e. there's no ABI issue unless sizeof(long) != sizeof(int) too, right?

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>     <woods@robohack.ca>
Planix, Inc. <woods@planix.com>;   Secrets of the Weird <woods@weird.com>