[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: New platform independent problem
From: |
Eric Blake |
Subject: |
Re: New platform independent problem |
Date: |
Fri, 20 Jan 2006 06:59:01 -0700 |
User-agent: |
Mozilla Thunderbird 1.0.2 (Windows/20050317) |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
According to Corinna Vinschen on 1/20/2006 5:25 AM:
>
> I'm also having a problem right now building rcp and scp due to the
> missing d_ino. OTOH, the d_ino member is not required by POSIX, but
> only in X/Open compliant OSes, see
>
> http://www.opengroup.org/onlinepubs/009695399/basedefs/dirent.h.html
>
> http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap02.html#tag_02_01_04
>
> So, portable applications shouldn't rely on d_ino.
Is there a compromise here? Many applications that look at d_ino also
check whether the d_ino member is 0, in which case they fall back on
st_ino. For example, coreutils's pwd.c contains:
#define NOT_AN_INODE_NUMBER 0
#ifdef D_INO_IN_DIRENT
# define D_INO(dp)((dp)->d_ino)
#else
/* Some systems don't have inodes, so fake them to avoid lots of ifdefs. */
# define D_INO(dp) NOT_AN_INODE_NUMBER
#endif
Then later on, it can blindly do:
ino_t ino = D_INO(dp);
if (ino == NOT_AN_INODE_NUMBER)
{
if (lstat (dp->d_name, &ent_sb) < 0)
continue; /* Skip any entry we can't stat. */
ino = ent_sb.st_ino;
}
>
> Whether we should revert to using d_ino or not, I'm not sure. From a
> Windows perspective, it's a step in the right direction. From an
> application portability perspective, it should be ok to do it. From a
> Linux compatibility perspective, which we claim, it might be somewhat
> hazardous to drop d_ino, though.
This would allow cygwin to provide the d_ino member (but probably in a new
offset, rather than renaming __deprecated_d_ino back to d_ino, to avoid
breaking backwards compatibility with old cygwin apps that have come to
rely on the field at offset __deprecated_d_ino being a hash rather than an
inode value). Cygwin would then set it to 0 on WinNT and 2k (where it is
prohibitively expensive to determine a real value), set it to the hash on
Win9x and ME (since st_ino is also the hash on those platforms), and set
it to the actual st_ino value on WinXP and beyond (since the API exists).
It would just be a matter of educating apps that use d_ino that when
d_ino==0, fall back on st_ino instead. And based on the code in
coreutils, this is probably already the case for code that strives to be
portable, since it appears there are already existing Unix machines that
return d_ino == 0 when a real value is not available.
- --
Life is short - so eat dessert first!
Eric Blake address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFD0Oyk84KuGfSFAYARArXgAJ0aQu09wfK4ab0R+upRH7kLq6FlTACgluSD
Y8hqZD9P15tdhF6v2Rv2sXY=
=+rha
-----END PGP SIGNATURE-----
Re: New platform independent problem, Eli Zaretskii, 2006/01/27