the one and only objection to C

John Chambers jc at mit-athena.ARPA
Thu Dec 27 05:44:16 AEST 1984


Yet another objection to alignment.  I have had the fun (:-) of
porting code that had to deal with "structured" files.  In particular,
I have brought up several C compilers as cross compilers.  Alignment
is the biggest single pain in doing this.

Suppose you're trying to read a file which starts with a 16-bit field,
followed by a 32-bit field, then another 16-bit field.  Or suppose
you're trying to handle an archive file, which has a 14-char array
followed by an int of some sort.  The turkey compiler on your 32-bit
machine insists on aligning things "properly" on 4-byte boundaries.
(This would be fine if it would also transform all the files involved,
but it isn't that smart!)

So what do you do?  You dig in to the code, changing the 32-bit fields
to pairs of 16-bit fields.  Then, wherever the fields were mentioned,
you modify the code to extract the two little fields and combine them.

This is a royal pain in the *ss!!!

The trouble is that if you are handed data that is misaligned, someone
has to do the dirty work of unpacking, shifting, masking, etc.  Why 
does it have to be me?  That's why compilers were invented.  I don't
particularly care if the poor little compiler has to do some extra work.

Arguing that the code is inefficient doesn't impress me.  The "efficient"
code doesn't work right.  It doesn't read the data that's there.  Granted,
the data should have been better formatted.  If I had written the programs
to create the data, everything would have been nicely aligned.  That's not 
much consolation when I'm stuck with writing the program to try to read 
someone else's funny file formats.

It would be much nicer if C compilers would accept the fact that some
fields are misaligned and generate the code to handle it.  This would
save me a lot of work, and isn't that why high-level languages exist?
Or am I being overly naive to think such thoughts?

Of course, it would be nice if I could get warned about such ineficiencies;
preferably by lint, though, and not by the compiler.

				John Chambers (mit-athena)



More information about the Comp.lang.c mailing list