Re: fixing compat_12 getdents

[David Holland <dholland-tech%netbsd.org@localhost>]

On Mon, Dec 10, 2012 at 08:09:19AM -0800, Chuck Silvers wrote:
 > the last problem I found with running the i386 1.0 "ls" on
 > i386/amd64 is that some of the compat wrappers for
 > getdents/getdirentries don't actually translate the data to the old
 > format.  the attached patch fixes that, but I'm wondering about one
 > aspect of the translation.  the current version of
 > compat_30_sys_getdents() returns EINVAL if the 64-bit inode number
 > doesn't fit in 32 bits, but if the name is too large to fit in the
 > old-format buffer it just truncates the name.  I changed it to
 > return EINVAL in this case as well, would anyone like to argue in
 > favor of keeping the truncation?

No, but keep in mind that owing to limitations in fts(3), the
consequences of errors happening underneath readdir() can be odd; the
right way forward is to fix fts, but it's possible that someone in the
past figured that success with partial information was better than
having the whole thing blow up.

 > also, EINVAL doesn't seem like a great error code for this condition.
 > it's not an input parameter that's causing the error, but rather that
 > the required output format cannot express the data to be returned.
 > I think solaris uses EOVERFLOW for this kind of situation, and ERANGE
 > doesn't seem too bad either.  any opinions on that?

Sounds fine to me. Using EINVAL as a catchall for "something bad
happened" is so linux :-)

-- 
David A. Holland
dholland%netbsd.org@localhost