Inexplicable Parameter-Passing Phenomena w/MinGW GCJ

[Mark Wielaard]

Hi,

On Wed, 2003-09-10 at 16:37, Andrew Haley wrote:
> Mohan Embar writes:
>  > Good gravy. You're right. The call in impl.setOption() in DatagramSocket:
>  > 
>  > ---------------------------------------8<----------------------------------
>  >   public synchronized void setSoTimeout(int timeout) throws SocketException
>  >   {
>  >     if (timeout < 0)
>  >       throw new IllegalArgumentException("Invalid timeout: " + timeout);
>  > 
>  >     impl.setOption(SocketOptions.SO_TIMEOUT, new Integer(timeout));
>  >   }
>  > ---------------------------------------8<----------------------------------
>  > 
>  > ...ends up calling getOption() in natPlainDatagramSocketImplWin32.cc:
>  > and impl.getOption() ends up calling setOption with a totally bogus
>  > second parameter.
>  [...]
> <Deep Thought mode>  All right, ... You're really not going to like it.
> 
> I would look at some assembly code.  For whatever reason, the caller
> and the called have different opinions about the method table offset
> of setSoTimeout().
> 
> I still wonder if the compiler might be looking at different versions
> of DatagramSocket.

This might or might not be related, but this code yells "Miranda
Method!" to me. setOption() is defined in the interface SocketOptions,
which is implemented (but not defined) in the abstract class
DatagramSocketImpl and finally implemented in the class 
natPlainDatagramSocketImplXXX.

I really simple thing to check would be to explicitly defined
setOption() as an abstract method in the class DatagramSocketImpl.

Cheers,

Mark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://gcc.gnu.org/pipermail/java/attachments/20030910/9e53b096/attachment.sig>