John,
On 2012-12-19 22:25, John Zavgren wrote:
> Yes... I did consider that, but I didn't see any POSIX data types near the
> code I was changing, so I decided to use a "brute force" data type instead.
connect, recvfrom etc almost always uses socklen_t, but socklen_t could
expands either to int or to unsigned it on different OS
so as soon as the code pass a parameter directly to one of such
functions like e. g.
52 dbgsysConnect(int fd, struct sockaddr *name, uint32_t namelen) {
53 int rv = connect(fd, name, namelen);
on my opinion, we should use socklen_t
-Dmitry
>
> Shall I make that change?
>
> John
> ----- Original Message -----
> From: dmitry.samers...@oracle.com
> To: john.zavg...@oracle.com
> Cc: net-dev@openjdk.java.net
> Sent: Wednesday, December 19, 2012 1:06:52 PM GMT -05:00 US/Canada Eastern
> Subject: Re: RFR JDK-8005120
>
> John,
>
> Did you consider using socklen_t instead of uint32_t and unsigned int
> (for namelen etc) ?
>
> -Dmitry
>
>
> On 2012-12-19 19:36, John Zavgren wrote:
>> Greetings:
>> Please consider the following change to the two files:
>> src/share/transport/socket/sysSocket.h
>> src/solaris/transport/socket/socket_md.c
>> that eliminate compiler warnings that stem from the fact that the variables
>> that the native code passes to various system calls were not declared
>> correctly. They were declared as integers, but they must be "unsigned"
>> integers because they are used to define buffer lengths. Were one to supply
>> a negative value as an argument, it would be cast into an unsigned "Martian"
>> value and there'd be (hopefully) a system call error.
>>
>> Thanks!
>> John Zavgren
>>
>> http://cr.openjdk.java.net/~mullan/webrevs/jzavgren/8005120/
>>
>
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* Give Rabbit time, and he'll always get the answer
