probable omission in SYS_getdents or in libc-5.2.3

Marc Lehmann (
Tue, 5 Sep 1995 00:22:33 +0200 (MET DST)

I just compiled Linux 1.3.23 today, switching from 1.2.13 to the
1.3 series, as I heard now it stabilizes, and, as Linus said,
1.2 is getting boring, so stable is it :)

When I rebooted with 1.3 I entered the linux-source-dir changed
something and typed make. It didn't work, same binary as under 1.2!

After tracking the whole stuff down, I now think I isolated the problem.

Under 1.3, the libc-5.2.3 uses the new SYS_getdents call,
instead of SYS_readdir. I have no documentation (:) on that,
but I think SYS_getdents involves less overhead.

The thing that let make go mad was a definition at the top of dir.c:

#define D_NAMLEN(d) ((d)->d_namlen)

i.e., make used the d_namlen field for the length of the filename.

the following printf at some strategic point reveals the problem:

printf("RD: (%d,%d,%d) %s\n",d->d_namlen,len,strlen(d->d_name),d->d_name);/*D*/

generates (many limes omitted):

RD: (20,20,7) vpath.o
RD: (20,20,9) version.o
RD: (16,16,4) ar.o
RD: (20,20,8) arscan.o
^ ^ d_namlen
^ strlen

that is, then d_namlen field is garbage, only the strlen-version works.

I dont know if this problem is due to library code munging wrong
d_namlen fields while using the SYS_getdents call, or is
found in the Linux kernel, but I reported it here.

Anything here is in ELF.

If any information is missing here, just contact me. I hope it helped a bit!

----==-- _
---==---(_)__ __ ____ __ Marc Lehmann
--==---/ / _ \/ // /\ \/ /
-=====/_/_//_/\_,_/ /_/\_\
The choice of a GNU generation Fax.: (49)/(0)721/685610