Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!snorkelwacker!spdcc!merk!xylogics!world!madd
From: madd@world.std.com (jim frost)
Newsgroups: comp.windows.x
Subject: Re: Storing data structure as a property
Keywords: properties, XChangeProperty, selections
Message-ID: <1989Dec14.025002.16049@world.std.com>
Date: 14 Dec 89 02:50:02 GMT
References: <1989Nov29.072922.18738@ntvax.uucp> <1936@odin.SGI.COM>
Organization: Software Tool & Die
Lines: 44

karlton@sgi.com (Phil Karlton) writes:
>In article <1989Nov29.072922.18738@ntvax.uucp>, doug@ntvax.uucp (Douglas
>Scott) writes:
>> I have an application in which I wish to transfer a structure containing some
>> data between two instances of the same application, using the Selection
>> mechanism.  It is a small structure containing the name and size of a
>> temporary file

>The principle problem is that you have enclosed an
>integer (probably 32 bits wide) into the same data structure with the
>file name. This will not work across applications that are running on
>different endian machines.

Your solutions are fine, but you could also use the networker's
approach towards byte-ordering problems, ntohl()/htonl(), which also
makes those people who avoid atoi() because of performance happier.

Or, if you don't trust the network byte-ordering functions:

  unsigned char *intToStr(i)
       unsigned int i;
  { static char s[4];

    s[3]= i & 0xff;
    s[2]= (i >> 8) & 0xff;
    s[1]= (i >> 16) & 0xff;
    s[0]= (i >> 24) & 0xff;
    return(s);
  }

  unsigned int strToInt(s)
       unsigned s[4];
  {
    return((s[0] << 24) + (s[1] << 16) + (s[2] << 8) + s[0]);
  }

This will work regardless of which endian the machine is.

Personally I like the idea of saving the number as a string but
there are a variety of ways to deal with the problem.

jim frost
saber software
jimf@saber.com