Re: Seg fault reading data from IOChannel

[Chris Vine <chris cvine freeserve co uk>]

On Tue, 03 Feb 2009 11:14:27 +0100
"Víctor M. Palacio Tárrega" <victorpalacio adtelecom es> wrote:
> You are absolutely right. buff remains from another workaround and 
> should be eliminated.
> 
> About data, should be defined as char foo[<data_lenght>]; where I use 
> only 1 or 4 as data_lenght.
> Below are included the calls to read_data() function I'm using.
> 
> I'm doing something nasty with data conversion, or is just fine for
> you?
> 
> Thanks a lot,
> 
> Code:
>     int value;
>     char ID;  [ ... as corrected in your subsequent e-mail ... ]
>     //.........................................
>     ioc_unix.read_data(&ID,1);
>     std::cout<<"command received: " << (int)ID << std::endl;
>     //Get value
>     switch(ID)
>     {
>     case 0: //speed
> //..........................
>     break;
>     case 1: //RPM
>         if(ioc_unix.read_data((char*)value,4) !=-1){
> //......................................

If all you are doing is pass a single byte key followed by an integer
value over the socket, there is nothing intrinsically wrong with your
approach, provided that you have set the Glib::IOChannel object to null
(binary) encoding, if Glib::IOChannel is what you are using.  If you
haven't, it won't work, because GLib::IOChannel uses a text UTF-8
encoding by default. However, in this usage an IOChannel object looks
like overkill anyway.

However, as has already been mentioned you should pass sizeof(int) not 4
when reading and writing the int value - you cannot assume any
particular integer size, as that is platform and processor dependent.
Assuming the reader and write are on the same machine you don't need to
worry about endianness, but if they are on different machines (you are
communicating over a network other than localhost) then you do need to
worry about it.

Chris