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

[Peter Pentchev]

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

From: Peter Pentchev <roam at ringlet.net>
To: Gleb Smirnoff <glebius at FreeBSD.org>
Cc: bug-followup at FreeBSD.org
Subject: Re: kern/93705: [patch] ENODATA and EGREGIOUS (for glibc compat)
Date: Tue, 7 Mar 2006 12:18:49 +0200

 --FCuugMFkClbJLl1L
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 Content-Transfer-Encoding: quoted-printable
 
 On Mon, Feb 27, 2006 at 07:50:05AM +0000, Gleb Smirnoff wrote:
 >  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 compa=
 tibility with
 >  R> > R> Glibc systems?
 >  R> > R>=20
 >  R> > R> They have the same meaning as ENOATTR and EDOOFUS, respectively.
 >  R> > R>=20
 >  R> > R> As a side benefit, in the case of EDOOFUS this might be of inter=
 est 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> >=20
 >  R> > The ENODATA error code is standardized as a part of XSI streams:
 >  R> >=20
 >  R> > http://www.opengroup.org/onlinepubs/000095399/basedefs/errno.h.html
 >  R> >=20
 >  R> > I don't think we should hardcode it equal to ENOATTR, which is a BS=
 D specific
 >  R> > code, afaik.
 >  R>=20
 >  R> Linux uses ENODATA for no attribute errors, which afaik is the same a=
 s ENOATTR.
 >  R>=20
 >  R> However since the XSI definition is more generic as you point out, pe=
 rhaps it'd
 >  R> be better to rename ENOATTR to ENODATA and make ENOATTR an alias for =
 ENODATA
 >  R> instead?
 > =20
 >  Pardon, but I do not properly understand the meaning of ENODATA in XSI s=
 treams
 >  standard. That's why I am not sure, that ENODATA and ENOATTR can be made=
  equal
 >  to each other.
 > =20
 >  P.S. I'm just expressing my humble opinion. I hope freebsd-standards mai=
 ling
 >  list will make a decision.
 
 Okay, I could be *very* far off here, but... a couple of points
 natheless :)
 
 First, I wonder if the XSI STREAMS part of any standards actually apply
 to us - AFAIK, FreeBSD does not really implement STREAMS in any way,
 shape, or form.
 
 Second, ISTR that ENOATTR and ENODATA actually came into FreeBSD as part
 of the KAME project integration a long time ago, and then - not so long
 ago - ENODATA was *removed* since it was declared obsolete by the
 upstream KAME project.  At least, that's the impression I got when it
 had to be removed or ifdef'd out of a couple of my ports :)
 
 Okay, so maybe that was not quite correct - I can't seem to find ENODATA
 mentioned anywhere in the src/sys/sys/errno.h CVS history, nor in the
 history of the ftp/curl or security/stunnel ports... so either this is
 all a whole lot of hot air due to my memory being jumbled beyond any
 hope, or I'm not remembering it exactly correct.  Or maybe it was that
 ENODATA was never really defined in FreeBSD, because it was obsoleted by
 KAME at some point... or something...
 
 G'luck,
 Peter
 
 --=20
 Peter Pentchev	roam at ringlet.net    roam at cnsys.bg    roam at FreeBSD.org
 PGP key:	http://people.FreeBSD.org/~roam/roam.key.asc
 Key fingerprint	FDBA FD79 C26F 3C51 C95E  DF9E ED18 B68D 1619 4553
 This sentence contradicts itself - or rather - well, no, actually it doesn'=
 t!
 
 --FCuugMFkClbJLl1L
 Content-Type: application/pgp-signature
 Content-Disposition: inline
 
 -----BEGIN PGP SIGNATURE-----
 Version: GnuPG v1.4.2.1 (FreeBSD)
 
 iD8DBQFEDV4J7Ri2jRYZRVMRAs4oAKCcKtEG5a0Q23nhCoIWVAOx7xpw9QCePG1B
 jQTNuy0wJrKw71TTrFTOkEo=
 =URZX
 -----END PGP SIGNATURE-----
 
 --FCuugMFkClbJLl1L--