kern/93705: [patch] ENODATA and EGREGIOUS (for glibc compat)

Gleb Smirnoff glebius at FreeBSD.org
Sun Feb 26 23:50:06 PST 2006


The following reply was made to PR kern/93705; it has been noted by GNATS.

From: Gleb Smirnoff <glebius at FreeBSD.org>
To: Robert Millan <rmh at aybabtu.com>
Cc: FreeBSD-gnats-submit at FreeBSD.org, Jordan Hubbard <jkh at apple.com>
Subject: Re: kern/93705: [patch] ENODATA and EGREGIOUS (for glibc compat)
Date: Mon, 27 Feb 2006 10:43:54 +0300

 On Sun, Feb 26, 2006 at 07:36:17PM +0100, Robert Millan wrote:
 R> On Sun, Feb 26, 2006 at 02:35:48PM +0300, Gleb Smirnoff wrote:
 R> > On Wed, Feb 22, 2006 at 02:53:56PM +0100, Robert Millan wrote:
 R> > R> >Description:
 R> > R> Please could you add ENODATA and EGREGIOUS errno codes for compatibility with
 R> > R> Glibc systems?
 R> > R> 
 R> > R> They have the same meaning as ENOATTR and EDOOFUS, respectively.
 R> > R> 
 R> > R> As a side benefit, in the case of EDOOFUS this might be of interest to the Apple
 R> > R> developers who complained about this macro name (i.e. they could use EGREGIOUS in
 R> > R> Darwin exclussively if they want).
 R> > 
 R> > The ENODATA error code is standardized as a part of XSI streams:
 R> > 
 R> > http://www.opengroup.org/onlinepubs/000095399/basedefs/errno.h.html
 R> > 
 R> > I don't think we should hardcode it equal to ENOATTR, which is a BSD specific
 R> > code, afaik.
 R> 
 R> Linux uses ENODATA for no attribute errors, which afaik is the same as ENOATTR.
 R> 
 R> However since the XSI definition is more generic as you point out, perhaps it'd
 R> be better to rename ENOATTR to ENODATA and make ENOATTR an alias for ENODATA
 R> instead?
 
 Pardon, but I do not properly understand the meaning of ENODATA in XSI streams
 standard. That's why I am not sure, that ENODATA and ENOATTR can be made equal
 to each other.
 
 P.S. I'm just expressing my humble opinion. I hope freebsd-standards mailing
 list will make a decision.
 
 -- 
 Totus tuus, Glebius.
 GLEBIUS-RIPN GLEB-RIPE


More information about the freebsd-standards mailing list