On Wed, 19 Aug 1998, Nathan E Norman wrote: > On Tue, 18 Aug 1998, Stephen J. Carpenter wrote: > > : On Wed, Aug 19, 1998 at 10:54:52AM +1000, Hamish Moffatt wrote: > : > On Tue, Aug 18, 1998 at 08:46:20AM -0400, Stephen J. Carpenter wrote: > : > > currently xfstt bombs out if it gets a connection of a differnt > : > > "endianess" than the system it is on...I have been meaning to fix that > but > : > > maybe the PowerPC may have an easier fix... > : > > nah...ill just look into fixing it "right" > : > > : > Ouch.. use htons(), htonl(), ntohs(), ntohl() to convert; you don't > : > have to know what endianness the machine is you're using, you rely > : > on libc knowing and implementing those functions appropriately. > : > : well... > : thats the problem... > : htons et al are empty functions on big-endian systems and thge situation > : actually requires they perform the swap because in this case endian-ness > : matters and sending it in "Network order" is NOT apropriate unless > : "Network Order" is the same as host order on the client. > : > : see teh problem? > : if the other side doesn't ntoh the data then it doesn't work ;) > > I'm coming into this late, and perhaps under-armed ... but no, I don't > understand. Network order == big-endian ... so on little-endian > machines htons(), htonl() et. do actually perform a conversion. On a > big-endian system, no conversion is necessary because network order == > host order on these machines. > > This way, every host is transferring information in network order, so > everyone's happy. > > Am I missing something? >
No, you have correctly stated the network byte order rules. But, there is a more subtle point here. As Hamish Moffatt pointed out a couple of msgs previously in this thread, good software engineering practice is to use the endian conversion routines regardless of the CPU architecture and depend upon the development environment to perform the conversion or be null or whatever. This is the source of simple (but deadly) bugs that are just unnecessary. Among other things, I write networking protocol software for 68K CPUs, SPARC CPUs, PowerPC CPUs, and Intel CPUs (and who knows what CPU in the future). We do a lot of socket-based communications and I want to write reuseable code that is as architecture independent as possible. I don't want to worry about which CPU a particular piece of code is for and I want to minimize as much as possible the amount of code that is necessary to account for CPU architecture differences. We can't afford the time (or frustration) of tracking down a bug that is as silly as getting the network byte order wrong. The htons(), htonl(), etc. routines should ALWAYS be used regardless of whether they are needed (little endian) or not (big endian). This is just good software engineering practice. Anyone making this kind of mistake will not be looked upon favorably by the other members of their software development team are will likely receive a sharp retort.
