Re: RFR JDK-8005120
Real sense of deja-vu here. Didn't we go through this same thing with the HPI socket routines? Depending on the OS (and version?) we should be using socklen_t not int and not uint32_t. David On 20/12/2012 2:35 AM, Chris Hegarty wrote: John, I grabbed your patch, and with it I now see different warnings. ../../../../src/share/transport/socket/socketTransport.c: In function 'socketTransport_startListening': ../../../../src/share/transport/socket/socketTransport.c:310:40: warning: pointer targets in passing argument 3 of 'dbgsysGetSocketName' differ in signedness [-Wpointer-sign] ../../../../src/share/transport/socket/sysSocket.h:58:5: note: expected 'uint32_t *' but argument is of type 'int *' ../../../../src/share/transport/socket/socketTransport.c: In function 'socketTransport_accept': ../../../../src/share/transport/socket/socketTransport.c:371:33: warning: pointer targets in passing argument 3 of 'dbgsysAccept' differ in signedness [-Wpointer-sign] ../../../../src/share/transport/socket/sysSocket.h:41:5: note: expected 'uint32_t *' but argument is of type 'int *' Do you see these in your build? -Chris. On 12/19/2012 03:42 PM, Alan Bateman wrote: John - this is the debugger socket transport so cc'ing the serviceability-dev list as that is where this code is maintained. On 19/12/2012 15: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/
Re: RFR JDK-8005120
John,
On 2012-12-19 23:33, John Zavgren wrote:
> Dmitry:
> Are you suggesting that in the definition of, for example, dbgsysConnect(),
> we convert the namelen argument to be a socklen_t?
The best approach IMHO, is
dbgsysConnect(int fd, struct sockaddr *name, socklen_t namelen)
and change
share/transport/socket/socketTransport.c:462
err = dbgsysConnect(socketFD, (struct sockaddr *)&sa, sizeof(sa));
to
err = dbgsysConnect(socketFD, (struct sockaddr *)&sa,
(socklen_t) sizeof(sa));
-Dmitry
>
>
> 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
hg: jdk8/tl/jdk: 8005097: Tie isSynthetic javadoc to the JLS
Changeset: 1f9c19741285 Author:darcy Date: 2012-12-19 11:53 -0800 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/1f9c19741285 8005097: Tie isSynthetic javadoc to the JLS Reviewed-by: mduigou ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Executable.java ! src/share/classes/java/lang/reflect/Member.java ! src/share/classes/java/lang/reflect/Method.java
Re: RFR JDK-8005120
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
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
Re: RFR JDK-8005120
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. 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
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
hg: jdk8/tl/langtools: 8005098: Provide isSynthesized() information on Attribute.Compound
Changeset: f72c9c5aeaef Author:jfranck Date: 2012-12-16 11:09 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/f72c9c5aeaef 8005098: Provide isSynthesized() information on Attribute.Compound Reviewed-by: jjg ! make/build.properties ! src/share/classes/com/sun/tools/javac/code/Attribute.java ! src/share/classes/com/sun/tools/javac/code/Symbol.java ! src/share/classes/com/sun/tools/javac/comp/Annotate.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/tree/TreeMaker.java ! src/share/classes/com/sun/tools/javadoc/PackageDocImpl.java ! src/share/classes/com/sun/tools/javadoc/ParameterImpl.java ! src/share/classes/com/sun/tools/javadoc/ProgramElementDocImpl.java
Re: RFR JDK-8005120
John, I grabbed your patch, and with it I now see different warnings. ../../../../src/share/transport/socket/socketTransport.c: In function 'socketTransport_startListening': ../../../../src/share/transport/socket/socketTransport.c:310:40: warning: pointer targets in passing argument 3 of 'dbgsysGetSocketName' differ in signedness [-Wpointer-sign] ../../../../src/share/transport/socket/sysSocket.h:58:5: note: expected 'uint32_t *' but argument is of type 'int *' ../../../../src/share/transport/socket/socketTransport.c: In function 'socketTransport_accept': ../../../../src/share/transport/socket/socketTransport.c:371:33: warning: pointer targets in passing argument 3 of 'dbgsysAccept' differ in signedness [-Wpointer-sign] ../../../../src/share/transport/socket/sysSocket.h:41:5: note: expected 'uint32_t *' but argument is of type 'int *' Do you see these in your build? -Chris. On 12/19/2012 03:42 PM, Alan Bateman wrote: John - this is the debugger socket transport so cc'ing the serviceability-dev list as that is where this code is maintained. On 19/12/2012 15: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/
Re: RFR JDK-8005120
John - this is the debugger socket transport so cc'ing the serviceability-dev list as that is where this code is maintained. On 19/12/2012 15: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/
RFR JDK-8005120
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/
hg: jdk8/tl/langtools: 8004833: Integrate doclint support into javac
Changeset: 67b01d295cd2 Author:jjg Date: 2012-12-19 11:29 + URL: http://hg.openjdk.java.net/jdk8/tl/langtools/rev/67b01d295cd2 8004833: Integrate doclint support into javac Reviewed-by: mcimadamore ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/main/Option.java ! src/share/classes/com/sun/tools/javac/resources/javac.properties + test/tools/javac/doclint/DocLintTest.java
