none
System.Guid .ToByteArray swapping first 4 bytes

    Question

  • Hello!

     

        While writing to both Oracle and SQL Server I've noticed that when I use a Guid and send it to Oracle via ToByteArray() that the actual array being sent has the first 4 bytes reversed in the 16 byte block. So when I have preloaded values in Oracle and I send this request, it swaps the Guid and does not return properly.

     

    Example:

     

    Guid sampleGuid = new Guid("11110000-0000-0000-0000-000000001111");
    
    // This will have [0][0][17][17] instead of [17][17][0][0]
    Byte[] bArray = sampleGuid.ToByteArray();
    

    Now, when passing this byte array into the Guid constructor, it returns fine (ie, swaps it back). 

    I was just wondering why this was as I cannot seem to figure it out.

    Thanks,
    Eric

     

    Thursday, June 17, 2010 4:13 PM

Answers

  • The first part of the guid is specified as a single 32 bit value (see uuid specs) now depending on the endianness of your processor this value will sit in memory (and thus in a byte array) in either [17][17][0][0] or as [0][0][17][17] given you are running on a little endian processor (x86 architecture is little, power pc for instance is big) it sits as [17][17][0][0] see the wikipedia page i linked for more information about the concept of endianness.
    Thursday, June 17, 2010 5:42 PM

All replies

  • The first part of the guid is specified as a single 32 bit value (see uuid specs) now depending on the endianness of your processor this value will sit in memory (and thus in a byte array) in either [17][17][0][0] or as [0][0][17][17] given you are running on a little endian processor (x86 architecture is little, power pc for instance is big) it sits as [17][17][0][0] see the wikipedia page i linked for more information about the concept of endianness.
    Thursday, June 17, 2010 5:42 PM
  • This is the reason, makes much more sense now.

     

    Now to account for the case of sending a raw value to Oracle for values preloaded, fun! :)

     

    Thanks again.

    Thursday, June 17, 2010 5:56 PM