http://enja.org/2010/04/09/the-day-the-data-stood-still/ casin' the joint since '85 Thu, 03 Mar 2016 20:39:33 +0000 hourly 1 https://wordpress.org/?v=4.4.5 http://enja.org/2010/04/09/the-day-the-data-stood-still/comment-page-1/#comment-31 Fri, 16 Apr 2010 05:15:32 +0000 http://enja.org/?p=127#comment-31 reading this reaffirmed that…i know nothing about programming…lol

]]> http://enja.org/2010/04/09/the-day-the-data-stood-still/comment-page-1/#comment-27 Fri, 09 Apr 2010 20:15:10 +0000 http://enja.org/?p=127#comment-27 You mention storing native formats in files. You didn’t mention byte ordering. For example, if you write a four-byte int out to a file on an x86 box, then transfer that file over to a PowerPC box, and read the int into a program, you’re going to be hosed unless you take special precautions. That’s because x86 stores integers as “little endian” that is, the four bytes that make up the integer are ordered so that the least significant byte is first, and the most significant last, or “little end first.” The PowerPC thinks that 4 byte integers are stored in the reverse order, with the first byte being the most significant, and the last byte being the least significant, or “big end first”, or, “big endian”. The same problem occurs with networking. The solution to this is to define the file format such that it specifies a byte order. Typically, big-endian (also known as “network byte order”) is used for external data formats. There are functions in the C library like ntohl and htonl — “net to host long” and “host to net long” for converting between “host” byte order (be that big or little endian or some weird mixture like DEC machines could do) and “network” byte order — typically big endian.

]]>