[PATCH] ENOATTR and EDOOFUS

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[PATCH] ENOATTR and EDOOFUS

Robert Millan

Hi,

Please consider adding these error codes (needed for GNU/kFreeBSD):

2005-11-15  Robert Millan  <[hidden email]>

        * manual/errno.texi: Add ENOATTR and EDOOFUS (of BSD origin).
        * sysdeps/gnu/errlist.c: Regenerate.

--
Robert Millan

enoattr_edoofus.diff (937 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] ENOATTR and EDOOFUS

Roland McGrath
We endeavor to have a uniform API across variant GNU systems to the extent
possible.  This is one of the core purposes of glibc.  This may require
translating the kernel's native errno codes into the ones we expect in the
glibc interface, or perhaps just providing GNU-compatible names for new
error codes from other kernels.

How is EDOOFUS used in practice?  We have EGRATUITOUS, which is falsely
documented in the manual, and is actually used on the Hurd when internal
protocols are violated that indicate parts of the implementation are
broken.  Your description of EDOOFUS sounds like it might be used in cases
that should in fact be EINVAL.  

There is also EGREGIOUS, which is in fact never used.  Perhaps EDOOFUS
should be an alias for EGREGIOUS on your platform.

I gather from your description that ENOATTR is returned by getxattr et al
when the attribute name is not found.  Linux uses ENODATA for that.
Perhaps ENOATTR should be an alias for ENODATA.  (The manual unfortunately
does not say anything useful about ENODATA; fixing that would of course be
more than welcome.)


Thanks,
Roland
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] ENOATTR and EDOOFUS

Robert Millan
On Tue, Feb 21, 2006 at 07:07:06PM -0800, Roland McGrath wrote:

> We endeavor to have a uniform API across variant GNU systems to the extent
> possible.  This is one of the core purposes of glibc.  This may require
> translating the kernel's native errno codes into the ones we expect in the
> glibc interface, or perhaps just providing GNU-compatible names for new
> error codes from other kernels.
>
> How is EDOOFUS used in practice?  We have EGRATUITOUS, which is falsely
> documented in the manual, and is actually used on the Hurd when internal
> protocols are violated that indicate parts of the implementation are
> broken.  Your description of EDOOFUS sounds like it might be used in cases
> that should in fact be EINVAL.  
>
> There is also EGREGIOUS, which is in fact never used.  Perhaps EDOOFUS
> should be an alias for EGREGIOUS on your platform.
>
> I gather from your description that ENOATTR is returned by getxattr et al
> when the attribute name is not found.  Linux uses ENODATA for that.
> Perhaps ENOATTR should be an alias for ENODATA.  (The manual unfortunately
> does not say anything useful about ENODATA; fixing that would of course be
> more than welcome.)

Sure.  I'll investigate and send a new patch.

--
Robert Millan
Reply | Threaded
Open this post in threaded view
|

Re: [PATCH] ENOATTR and EDOOFUS

Robert Millan

Linux only knows ENODATA, and kFreeBSD only knows ENOATTR.  So I think it's no
big deal if we just define ENODATA as an alias for ENOATTR in our sysdeps.

EDOOFUS seems to be a funny way of telling the programmer that per did something
unsupported by the API.  There's a long discussion about this errno code pissing
off Apple Darwin developers which pretty much clarifies it:

  http://lists.freebsd.org/pipermail/freebsd-hackers/2003-May/000791.html

Looks like EGREGIOUS makes the fit:

  @comment errno.h
  @comment GNU: You really blew it this time
  @deftypevr Macro int EGREGIOUS
  @comment errno 103 @c DO NOT REMOVE
  You did @strong{what}?
  @end deftypevr

So I'll add it as an alias in our sysdeps, too.

Thanks for the tips!

--
Robert Millan