-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 According to Bruno Haible on 9/22/2008 6:15 PM: > But fopen() on a directory? Who does that? If no-one needs that, I would be > satisfied with mentioning the problem under "Portability problems not fixed by > Gnulib" in the doc.
The use case where I discovered this bug was with m4 1.4.11. Compare: mingw$ m4 . m4.exe: .: Permission denied Linux$ m4 . m4:/:1: Read error OpenBSD$ m4 . && echo done done EMX$ m4 . <starts trying to interpret struct dirent records as m4 input> In an effort to unify this behavior, I was considering making m4 1.4.12 pre-reject directories with EISDIR (POSIX allows this, since directories are not text files, and m4 is only required to operate on text files), while remembering that doing stat() prior to fopen() is racy. For most systems, the inadvertent selection of a directory by fopen (usually with a name less obvious than '.') can then be detected with fstat(fileno(f)), but with mingw, the fopen never succeeded in the first place. So it boils down to a question of making the m4 test suite accommodate two different errno values (doable, but not trivial in the current test setup), or work around the mingw discrepancy so that the fopen always succeeds on a readable directory (trivial for m4, but more complex in gnulib). But either way, the end result is that any attempt to make m4 read a directory will uniformly result in an error (I really don't like the fact that BSD treats reads of a directory as an empty file, and gives a 0 exit status, and the EMX behavior of reading binary contents isn't much better). - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkjYS4EACgkQ84KuGfSFAYDnHQCfed8uvPCVYsLiWt+HKwZjrJul sJIAn1brFTq9xIim/tALqM6EaIEKed8c =E8fe -----END PGP SIGNATURE-----
