possible opendir bug?

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

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		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B