This looks to me like a bug, but it's currently concealed; I'm not sure to what extent NetBSD considers such things bugs.
I noticed this in 1.4T, but, on reading the source, it looks to me as though 9.1 has the same issue. (I got my SPARC emulator to the point where it can do valgrind-style tracking of undefined data; it caught this and I just finished tracking it down in the source.) Here's what I see happening: opendir() (via _initdir() in 9.1) sets dd_size only in the __DTF_READALL case. But the first thing readdir() (_readdir_unlocked in 9.1) does is to compare dd_loc against dd_size - at which point dd_size still holds the trash it got from malloc back when the DIR was first allocated. Looking at the logic, I think this is _probably_ not causing trouble because, in the non-__DTF_READALL case (which is the only way dd_size can be unset), it doesn't matter whether that comparison succeeds or not when dd_loc is already 0 (which it will be the first time in). And, the next if block will set dd_size if dd_loc is zero and __DTF_READALL is not set. I'm not sure to what extent use of uninitialized memory is considered a bug when, as here, the code is correct regardless of what value it contains. It does strike me as a relatively fragile piece of logic and therefore a bug waiting to happen. I'm going to be fixing this in my own trees, if only to avoid upsetting my uninitialized-memory detector; if anyone thinks it worth doing, I can file a PR for this, or anyone else who cares to is welcome to do it instead. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
