bilbo.niket@LOCUS.UCLA.EDU (Niket K. Patwardhan) (10/21/85)
It is particularly important when you are sharing data between machines with different integer models (ie. little endian vs. big endian). You then want "int16" to mean something very specific (16 bits in little endian format). I chose little endian because thats what most networks seem to use (as opposed to IBM or Motorola CPUs). Without being able to specify exactly how many bits you want to use, porting programs between machines with different ideas of what an int, long, short or char is can be real painful. NOTE even "char" is not sacred, KL10s can define them as any number of bits upto 36(!!) with 6, 8 and 9 being values that support various types of TOPS-10 (their OS) characters. What I would really like to see is that the bit-field semantics be changed a little. struct x { unsigned a:18; unsigned b:18; unsigned c:36; } should be packed together as close as possible, taking up 9 bytes (octets), rather than the 4+4+5 it takes up on a 16-bit word machine, or the 4+4+8 bytes it takes up on a 32-bit machine. If you wanted it to be the way it is today you would define it as struct x { struct { unsigned a:18; }; struct { unsigned b:18; }; struct { unsigned c:32; }; } In addition, there would be no harm done if unsigned a:13; were allowed as a declaration. BTW, can somebody give me the correct address to reach everybody in net.lang.c and std.c. I suspect the ones I am using reach only a small subset of the people in these groups.
bc@cyb-eng.UUCP (Bill Crews) (10/22/85)
> I chose little endian because thats what most networks seem to use (as > opposed to IBM or Motorola CPUs). The DARPA protocols (TCP/IP) are perhaps the most widely-used among Unix systems. Network byte order for these protocols is big-endian. -- - bc - ..!{seismo,topaz,gatech,nbires,ihnp4}!ut-sally!cyb-eng!bc (512) 835-2266
guy@sun.uucp (Guy Harris) (10/27/85)
> It is particularly important when you are sharing data between machines with > different integer models (ie. little endian vs. big endian). You then want > "int16" to mean something very specific (16 bits in little endian format). > I chose little endian because thats what most networks seem to use (as > opposed to IBM or Motorola CPUs). Aside from the fact that many networks don't use little-endian format (as has been pointed out already), it's not appropriate to build data types with specified byte orders into a programming language. Many libraries exist which put objects into a canonical byte order (the "ntoh" and "hton" routines in 4.2BSD, the Sun XDR library, etc.). These operations are only used when data is exported (to a network connection or a file) or imported; burdening the compiler with these data types, or burdening its object code with the responsibility of reordering them on each reference, is a mistake. Besides, there are other issues than just byte order - floating point format, padding between structure members, etc., etc.. If you want a language to specify this, consider putting it into something like a remote procedure call description language, not in a general programming language. > BTW, can somebody give me the correct address to reach everybody in > net.lang.c and std.c. I don't know whether any gateway exists between the ARPANET and "mod.std.c", but all mail to the INFO-C mailing list should get gatewayed to "net.lang.c". Guy Harris