Dmitry:
Are you suggesting that in the definition of, for example, dbgsysConnect(), we 
convert the namelen argument to be a socklen_t? 


int
dbgsysConnect(int fd, struct sockaddr *name, uint32_t namelen) {
    int rv = connect(fd, name, (socklen_t)nameLength);<--- NEW
    if (rv < 0 && (errno == EINPROGRESS || errno == EINTR)) {
        return DBG_EINPROGRESS;
    } else {
        return rv;
    }
}
Thanks!
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:40:11 PM GMT -05:00 US/Canada Eastern
Subject: Re: RFR JDK-8005120

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

Reply via email to