RFR JDK-8005120

[John Zavgren]

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.samersoff at oracle.com
To: john.zavgren at oracle.com
Cc: net-dev at 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.samersoff at oracle.com
> To: john.zavgren at oracle.com
> Cc: net-dev at 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