RFR JDK-8005120
David Holmes
david.holmes at oracle.com
Wed Dec 19 12:52:26 PST 2012
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/
>>
More information about the serviceability-dev
mailing list