On Thu, 27 Sep 2001, Wayne E. Van Loon Sr. wrote:
> Stephen:
>
> I have been using memcpy() to copy stucts (sometimes several of them) into a
> buffer. I then call write() on the buffer and then the opposite
> at the other end. I think this is the same thing as calling write() on a
> structure. I have been doing something like:
>
> unsigned char *pu8to = &buffer;
> unsigned char *pu8from = &struct;
>
> for(int i=0; i<sizeof(struct); i++){
> *pu8to++ = *pu8from++
> }
>
> write(fd, buffer, sizeof(struct));
>
>
> If I understand you, this means that my code might fail when both ends of a fifo
> were not compiled by the same gcc version or when both ends of a network are not
> compiled by the same gcc version or are differing platforms.
Don't worry about this possibility. As long as you read the structs on
the other end using the same machine architecture you shuld be fine. Have
you ever used a compiled library? A lot of the stuff in glibc relies on
you passing pointers to structs *you* created. Glibc would be broken if
changing compiler versions was so likely to cause struct re-ordering...
-Calin
>
> I am trying to imagine some reasonable way to unpack / pack structures across a
> network that does not depend upon some structure being organized in the same
> manner at both ends. This is the only thing that I could come up with:
>
>
> struct USED_BOTH_IN_RTL_AND_LINUX_1
> {
> type1 member1;
> type2 member2;
> type3 member2;
> };
>
>
> struct USED_BOTH_IN_RTL_AND_LINUX_2
> {
> type4 member1;
> type5 member2;
> type6 member3;
> USED_BOTH_IN_RTL_AND_LINUX_1 member4
> ...
> };
>
> unsigned char buffer[sizeof(USED_BOTH_IN_RTL_AND_LINUX_2)];
> USED_BOTH_IN_RTL_AND_LINUX_2 object1;
>
> unsigned char *pu8s = (unsigned char *) &object1.member1;
> unsigned char *pu8d = (unsigned char *) &buffer;
> unsigned n;
>
> n = sizeof(object1.member1);
> memcpy(pu8d, pu8s, n);
> pu8d += n;
>
>
> pu8s = (unsigned char *) &object1.member2;
> n = sizeof(object1.member2);
> memcpy(pu8d, pu8s, n);
> pu8d += n;
>
>
> pu8s = (unsigned char *) &object1.member3;
> n = sizeof(object1.member3);
> memcpy(pu8d, pu8s, n);
> pu8d += n;
>
>
> pu8s = (unsigned char *) &object1.member4.member1;
> n = sizeof(object1.member4.member1);
> memcpy(pu8d, pu8s, n);
> pu8d += n;
>
>
> pu8s = (unsigned char *) &object1.member4.member2;
> n = sizeof(object1.member4.member2);
> memcpy(pu8d, pu8s, n);
> pu8d += n;
>
> ....
>
> This does depend upon the size of the types involved being the same size at both
> ends and I think that it requires the bytes in the types, (int for example) to
> be stored in the same order at both ends.
>
> How do you do it?
>
> Wayne
>
> > Mr. Calianu Wrote:
> > > More specifically, I plan on writing structs into the fifo and reading
> > > them in userland.
> >
>
> "Stephen D. Cohen" wrote:
>
> > Then you are already dooming yourself to a great deal of pain.
> > Avoid simply using rtf_put on a struct and expecting the same thing in user
> > space. That is, of course, unless you are willing to sort through every
> > compiler option and optimization setting to make absolutely certain that the
> > structs will be aligned exactly the same way in RT space and user space. It
> > would be much better to simply define your own format for the data in the
> > FIFO and copy out of the struct to a buffer, send the buffer, then copy out
> > of the buffer into your struct. This also assures that your code is
> > maximally portable across platforms, etc.
> >
> > You will be amazed to find that it is *much* easier to textualize /
> > bufferize it yourself and disassemble the buffers at the other end, rather
> > than simply writing structs. You will find this the first time the darned
> > compiler bites you in the rear end and you spend two days tracking down why
> > something that obviously works doesn't. You may not find this until your
> > version of gcc changes or some such. By then you won't remember that you
> > might have a problem. In that case, expect to spend the whole week tracking
> > this down. Creating the buffers properly, on the other hand, will only take
> > an hour of your life and you will have the pleasure of the knowledge of a
> > job done properly. Your choice. :-)
> >
> > Regards,
> >
> > Steve Cohen
> >
> > --------------------------
> > Stephen D. Cohen
> > Xybion Sensor Positioning Systems
> > 11528 53rd Street North
> > Clearwater, FL 33760
> > Voice: (727) 299-0150
> > Fax: (727) 299-0804
> > [EMAIL PROTECTED]
> > www.xybion.com
> >
> > -- [rtl] ---
> > To unsubscribe:
> > echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
> > echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
> > --
> > For more information on Real-Time Linux see:
> > http://www.rtlinux.org/
>
> -- [rtl] ---
> To unsubscribe:
> echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
> echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
> --
> For more information on Real-Time Linux see:
> http://www.rtlinux.org/
>
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/
