Incompatible data size using 32 bits SocketAppender and 64 bits S ocketNode

["Sluis, Minto van der" <Mi...@isc.politie.nl>]

Hi,

After a little bit of struggling we succeeded in building
0.9.7 on the tru64 using the compaq cxx compiler. However,
we now run into a runtime problem.

Using the DelayedLoop example and the simple socket server
on the same platform works fine. However, if we run the 
DelayedLoop example on windows and the simple socket server
on tru64 it does not work. DeleyedLoop does succeed in 
establishing a connection with the socket server, however
no messages arrive (also no error reports on either 
side). We suspect something like an 32 bits integer is written
and a 64 bits integer is read. Could this be the case? If
so, will this still be the case in the next release?

After some poking around (in CVS head) I discovered that 
the SocketOutputStream class uses plain int, long and 
unsigned int types for writing data to the socket. 
Shouldn't this be some kind of platform safe types?

How is this best fixed?

regards,

Minto van der Sluis

Re: Incompatible data size using 32 bits SocketAppender and 64 bits S ocketNode

[Curt Arnold <ca...@apache.org>]

I added your comment to the existing LOGCXX-7 bug on the socket format 
being incompatible with Chainsaw 
(http://nagoya.apache.org/jira/browse/LOGCXX-7).


On Dec 22, 2004, at 6:04 AM, Sluis, Minto van der wrote:

> Hi,
>
> After a little bit of struggling we succeeded in building
> 0.9.7 on the tru64 using the compaq cxx compiler. However,
> we now run into a runtime problem.
>
> Using the DelayedLoop example and the simple socket server
> on the same platform works fine. However, if we run the
> DelayedLoop example on windows and the simple socket server
> on tru64 it does not work. DeleyedLoop does succeed in
> establishing a connection with the socket server, however
> no messages arrive (also no error reports on either
> side). We suspect something like an 32 bits integer is written
> and a 64 bits integer is read. Could this be the case? If
> so, will this still be the case in the next release?
>
> After some poking around (in CVS head) I discovered that
> the SocketOutputStream class uses plain int, long and
> unsigned int types for writing data to the socket.
> Shouldn't this be some kind of platform safe types?
>
> How is this best fixed?
>
> regards,
>
> Minto van der Sluis
>