[prev] [thread] [next] [lurker] [Date index for 2005/04/25]
On Sun, Apr 24, 2005 at 05:37:15PM -0500, Peter da Silva wrote:
> > But if you insist on something that is
> > more intimately tied to Unix, try stat, which is even more hateful.
> Hmmm. All the objects defined in sys/stat.h are built up of primitive
> elements with specific bit sizes or structures defined in similar
> terms.
I got tired of hunting through a maze of twisty include files and C
pre-processor directives for the exact definitions on a Linux platform,
so just looked in K&R instead. There, struct stat is defined as:
struct stat
{
dev_t st_dev;
ino_t st_ino;
short st_mode;
short st_nlink;
short st_uid;
short st_gid;
dev_t st_rdev;
off_t st_size;
time_t at_atime;
time_t at_mtime;
time_t at_ctime;
};
Even without delving through that maze of twisty include files again to
find out what an off_t is, the very presence of those shorts means that
the structure is not properly defined. Again from K&R, ...
" Each compiler is free to choose appropriate sizes for its own
hardware, subject only to the the restriction that shorts and ints are
at least 16 bits, longs are at least 32 bits, and short is no longer
than int, which is no longer than long. "
> And they all land on properly aligned word boundaries.
Do they? There's *nothing* in the spec that tells me how those shorts
will be aligned. st_nlink may or may not have sixteen bits of empty
space between it and st_uid. Come to think of it, I don't think the
order of the members in memory is even guaranteed! I can easily imagine
a compiler where short == 16 bits and long == 32 bits taking something
like this ...
struct sillyexample {
short foo;
long bar;
short baz;
};
and optimising it to this ...
bits 0 - 15: foo
bits 16 - 31: baz
bits 32 - 63: bar
instead of ...
bits 0 - 15: foo
bits 16 - 31: [wasted because longs should be aligned on four byte
boundaries]
bits 32 - 63: bar
bits 64 - 79: baz
[and perhaps some more wasted space here]
> Seriously, I don't see that this is particularly bothersome let
> alone hateful.
If you can Hate BeOS's API because it is defined in terms of C++
objects, I can Hate Unix just as much because it is defined in terms of
C structs.
There are very good reasons why things like the IP header definition in
RFC 791 is laid out in terms of exactly what bit goes where - it ensures
that software written to the standard will Just Work, regardless of
language or platform. The same can't be said of the fuzzy Unix API
docs, or anything else that assumes All The World's A C Compiler.
--
David Cantrell | random organic glop and a metric fuckton of electricity
NANOG makes me want to unplug everything and hide under the bed
-- Brian D. Foy
There's stuff above here
Generated at 01:00 on 03 May 2005 by mariachi 0.52