the one and only objection to C
Henry Spencer
henry at utzoo.UUCP
Sun Dec 30 10:39:24 AEST 1984
> 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.
Actually, the preferred approach is to simply read the fields one at a
time instead of being lazy and trying to read the whole structure in one
gulp. This would seem much simpler. It also will become necessary
the instant you hit byte-ordering or word-ordering problems. I hope you
don't think the compiler should "solve" them, too.
> 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?
You might (repeat, might) be able to accomplish this with bitfields.
If your compiler is feeling cooperative that day... Of course the
bitfield declarations will be machine-dependent. You can't win.
--
"Face Mecca and repeat three times: 'binary file formats are not portable'".
Henry Spencer @ U of Toronto Zoology
{allegra,ihnp4,linus,decvax}!utzoo!henry
More information about the Comp.lang.c
mailing list