[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: current coreutils on MacOS X
From: |
Bruno Haible |
Subject: |
Re: current coreutils on MacOS X |
Date: |
Fri, 1 Sep 2006 14:40:09 +0200 |
User-agent: |
KMail/1.9.1 |
Andreas Schwab wrote:
> > --- 404,422 ----
> >
> > case 'i':
> > {
> > ! uintmax_t fsid;
> > ! /* On many BSD systems, fsd.f_fsid is of type fsid_t which is a
> > ! struct type:
> > ! struct { int32_t val[2]; }
> > ! or struct { int32_t __val[2]; }
> > ! or struct { int32_t __fsid_val[2]; }. */
> > ! memcpy ((char *) &fsid, &statfsbuf->f_fsid,
> > ! sizeof (statfsbuf->f_fsid) < sizeof (fsid)
> > ! ? sizeof (statfsbuf->f_fsid)
> > ! : sizeof (fsid));
> > ! if (sizeof (statfsbuf->f_fsid) < sizeof (fsid))
> > ! memset ((char *) &fsid + sizeof (statfsbuf->f_fsid), 0,
> > ! sizeof (fsid) - sizeof (statfsbuf->f_fsid));
>
> This does not handle endianess correctly if sizeof fsid != sizeof f_fsid.
It does not need to. An fsid is just 8 bytes of data. Whether you print
it in little-endian or big-endian way does not matter, since the 'stat'
program is the only tool to print it at all. (The tune2fs program prints
a "Filesystem UUID" instead.)
Anyway, there is already a disagreement between the endianness handling
in the current code in stat.c
uintmax_t val0 = statfsbuf->f_fsid.__val[0];
uintmax_t val1 = statfsbuf->f_fsid.__val[1];
uintmax_t fsid =
(val1
+ (sizeof statfsbuf->f_fsid.__val[1] < sizeof fsid
? val0 << (CHAR_BIT * sizeof statfsbuf->f_fsid.__val[1])
: 0));
and the one in glibc (internal_statvfs.c), which reads:
buf->f_fsid = (fsbuf->f_fsid.__val[0]
| ((unsigned long int) fsbuf->f_fsid.__val[1]
<< (8 * (sizeof (buf->f_fsid)
- sizeof (fsbuf->f_fsid.__val[0])))));
Bruno