Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!aplcen!samsung!cs.utexas.edu!rice!uw-beaver!fluke!ssc-vax!bcsaic!paula
From: paula@bcsaic.UUCP (Paul Allen)
Newsgroups: comp.os.minix
Subject: Re: 1.5.0 upgrade: REPORT + BUGS + PATCHES
Message-ID: <18900@bcsaic.UUCP>
Date: 13 Jan 90 02:49:31 GMT
References: <1990Jan7.205429.5247@chinet.chi.il.us> <363@fwi.uva.nl>
Reply-To: paula@bcsaic.UUCP (Paul Allen)
Organization: Boeing Computer Services AI Center, Seattle
Lines: 29

In article <363@fwi.uva.nl> croes@fwi.uva.nl (Felix A. Croes) writes:
+In article <1990Jan7.205429.5247@chinet.chi.il.us> bill@chinet.chi.il.us (Bill Mitchell) writes:
+>
+>This is apparently due to some problem below readdir(), so dp->d_name 
+>isn't returned as expected.  Things got complicated pretty fast here.
+>Knowing nothing about POSIX stuff, I didn't feel qualified pursue it.
+>I did notice that /usr/include/dirent.h had struct dirent.d_name
+>declared as "char d_name[1]", which looked suspicious.
+		   ^^^^^^^*^
+
+I don't know about POSIX, but it should be at least 14. It was 14 in Minix 1.3,
+since file names in directories are 14 bytes long. However, using 14 will cause
+problems with numerous incorrect programs which assume that file names in
+directories always terminate in \0 (ever tried 1.3 tar?).
+
+The comment says: /* name of file plus a 0 byte */ , so perhaps 15 should be
+used? Does any POSIX wizard know?

Well, I'm not a POSIX wizard, but I have tried to figure out the
directory access stuff.  As I recall, dirent structs get malloc'd
with a size that depends on the length of the filename.  The 'd_name'
identifier is then used as a pointer constant.  I don't think the
declaration of dirent.d_name is a problem.  

Paul Allen
-- 
------------------------------------------------------------------------
Paul L. Allen                       | pallen@atc.boeing.com
Boeing Advanced Technology Center   | ...!uw-beaver!bcsaic!pallen