Re: Build-Breaking MingW 3.3 Stuff

[Andrew Haley <aph at redhat dot com>]

Mohan Embar writes:
 > Hi Andrew,
 > 
 > > > (The code in question is placeholder, do-nothing code.)
 > >
 > >Okay.  That sounds like it's fairly safe.
 > 
 > I looked at the code in question again and saw that the patch
 > in question affects code that is NOT placeholder, do-nothing code.
 > Many of the functions in this file are placeholder, but these ones
 > are not. I am terribly sorry for the misinformation.
 > 
 > This being said, the patch is trivial and hopefully, I can convince you
 > the pre-patch code is incorrect. The UNIX socket functions send()
 > and receive() each require a char* as their second parameter
 > which is the data to write or the read buffer, respectively. The
 > previously code passed a jbyteArray directly as this parameter
 > instead of using elements(jbyteArray), which is required to
 > gain access to the raw byte array. That's basically all the patch
 > is doing.
 > 
 > Oh, and come to think of it, this is NOT a Windows-specific patch.
 > The code is incorrect on all platforms, so you should be able to
 > run a regression test for this specific patch if you are so inclined.

Very good.  I take it the patch we need is
http://gcc.gnu.org/ml/java-patches/2003-q1/msg00672.html

I don't think the reinterpret_cast is necessary on POSIX because the
signature of the message arguement to send() is void*:

       int send(int s, const void *msg, size_t len, int flags);

I presume on Windows it's char*, so this is another case of an
unnecessary divergence between Windows and Berkeley sockets.

For 3.3 I suppose it makes sense to cast the message pointer to char*
as your patch does, because char* is compatible with void*, so the
code will be correct on both Windows and POSIX.  Casting a pointer to
char* in order to pass the result to a void* argument seems weird, but
I guess an appropriate comment will help.

I note that natPlainSocketImplWin32.c does this:

	// These functions make the Win32 socket API look more POSIXy
	static inline int
	write(int s, void *buf, int len)
	{
	  return send(s, (char*)buf, len, 0);
	}
	
	static inline int
	read(int s, void *buf, int len)
	{
	  return recv(s, (char*)buf, len, 0);
	}
	
which limits the breakage to a Windows-specific file.

I can't help thinking that life would be much nicer if java.nio and
java.net had an OS abstraction layer that both used.  That way, fixing
problems like this wouldn't touch common code.

Andrew.