Re: fixing compat_12 getdents

[David Laight <david%l8s.co.uk@localhost>]

On Mon, Dec 10, 2012 at 09:53:46PM +0200, Alan Barrett wrote:
> >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?
> 
> There's also E2BIG, but I don't think it fits.  ERANGE is 
> documented in terms of "the available space", while EOVERFLOW is 
> documented in terms of "a numeric result".  So perhaps EOVERFLOW 
> for "integer is too large to fit in N bits", and ERANGE for 
> "string is too long to fit in N bytes"?  Or vice versa?
> 
> Somebody(TM) should go through the errno(2) documentation and make 
> the descriptions more generic, and add guidance for choosing which 
> code to return.
> 

Then people get upset because they say "function foo() isn't allowed
to set errno to 'bar'".
It is rather a shame that posix tries to list all errno a function
can return, not just those for explicit 'likely' (ie normal)
non-success returns froma function.

For the inode number, it is a slight shame that a 'fake' value
can't be returned - maybe 0xffffffff - since a lot of the
code won't really care.

More likely to be an issue for the stat() functions - but not much code
really cares.
Well not much that you are really going to run compat versions of.

There are issues getting unique dev/inode pairs anyway for some
filesystems (and things like union mounts).

        David

-- 
David Laight: david%l8s.co.uk@localhost