From rmh@io.debian.net  Wed Feb 22 13:53:58 2006
Return-Path: <rmh@io.debian.net>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 398AC16A420
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 22 Feb 2006 13:53:58 +0000 (GMT)
	(envelope-from rmh@io.debian.net)
Received: from io.debian.net (io.ethz.ch [129.132.80.17])
	by mx1.FreeBSD.org (Postfix) with ESMTP id D99FC43D46
	for <FreeBSD-gnats-submit@freebsd.org>; Wed, 22 Feb 2006 13:53:57 +0000 (GMT)
	(envelope-from rmh@io.debian.net)
Received: from rmh by io.debian.net with local (Exim 4.60)
	(envelope-from <rmh@io.debian.net>)
	id 1FBuRI-000HwG-02; Wed, 22 Feb 2006 14:53:56 +0100
Message-Id: <E1FBuRI-000HwG-02@io.debian.net>
Date: Wed, 22 Feb 2006 14:53:56 +0100
From: Robert Millan <rmh@aybabtu.com>
Reply-To: Robert Millan <rmh@aybabtu.com>
To: FreeBSD-gnats-submit@freebsd.org
Cc: Jordan Hubbard <jkh@apple.com>
Subject: [patch] ENODATA and EGREGIOUS (for glibc compat)
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         93705
>Category:       kern
>Synopsis:       [headers] [patch] ENODATA and EGREGIOUS (for glibc compat)
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-standards
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Wed Feb 22 14:00:15 GMT 2006
>Closed-Date:    Sun Jan 16 23:27:44 UTC 2011
>Last-Modified:  Sun Jan 16 23:27:44 UTC 2011
>Originator:     Robert Millan
>Release:        
>Organization:
>Environment:
System: GNU/kFreeBSD io.debian.net 5.4-1-586 #0 Mon Dec 5 19:45:10 CET 2005 i586 i386 AMD-K6(tm) 3D processor GNU/kFreeBSD
Architecture: i586

>Description:
Please could you add ENODATA and EGREGIOUS errno codes for compatibility with
Glibc systems?

They have the same meaning as ENOATTR and EDOOFUS, respectively.

As a side benefit, in the case of EDOOFUS this might be of interest to the
Apple developers who complained about this macro name (i.e. they could use
EGREGIOUS in Darwin exclussively if they want).

>How-To-Repeat:
	
>Fix:

Index: sys/sys/errno.h
===================================================================
RCS file: /home/ncvs/src/sys/sys/errno.h,v
retrieving revision 1.28
diff -u -r1.28 errno.h
--- sys/sys/errno.h	2 Apr 2005 12:33:28 -0000	1.28
+++ sys/sys/errno.h	22 Feb 2006 13:51:20 -0000
@@ -164,8 +164,10 @@
 #define	ECANCELED	85		/* Operation canceled */
 #define	EILSEQ		86		/* Illegal byte sequence */
 #define	ENOATTR		87		/* Attribute not found */
+#define ENODATA		ENOATTR		/* Glibc compat */
 
 #define EDOOFUS		88		/* Programming error */
+#define EGREGIOUS	EDOOFUS		/* Glibc compat */
 #endif /* _POSIX_SOURCE */
 
 #define	EBADMSG		89		/* Bad message */
>Release-Note:
>Audit-Trail:
Adding to audit trail from misfiled PR kern/93766:

Date: Thu, 23 Feb 2006 12:16:38 -0800
From: "Jordan K. Hubbard" <jkh@apple.com>
 
 Thanks, but I think we're going to keep trying to keep our errnos  
 actually meaningful. :-)
 
 - Jordan
 
 On Feb 22, 2006, at 5:53 AM, Robert Millan wrote:
 
 > Please could you add ENODATA and EGREGIOUS errno codes for  
 > compatibility with
 > Glibc systems?
 >
 > They have the same meaning as ENOATTR and EDOOFUS, respectively.
 >
 > As a side benefit, in the case of EDOOFUS this might be of interest  
 > to the Apple
 > developers who complained about this macro name (i.e. they could  
 > use EGREGIOUS in
 > Darwin exclussively if they want).

Responsible-Changed-From-To: freebsd-bugs->freebsd-standards 
Responsible-Changed-By: glebius 
Responsible-Changed-When: Sun Feb 26 11:19:27 UTC 2006 
Responsible-Changed-Why:  
Pass to standards list review. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=93705 

From: Gleb Smirnoff <glebius@FreeBSD.org>
To: Robert Millan <rmh@aybabtu.com>
Cc: FreeBSD-gnats-submit@FreeBSD.org, Jordan Hubbard <jkh@apple.com>
Subject: Re: kern/93705: [patch] ENODATA and EGREGIOUS (for glibc compat)
Date: Sun, 26 Feb 2006 14:35:48 +0300

 On Wed, Feb 22, 2006 at 02:53:56PM +0100, Robert Millan wrote:
 R> >Description:
 R> Please could you add ENODATA and EGREGIOUS errno codes for compatibility with
 R> Glibc systems?
 R> 
 R> They have the same meaning as ENOATTR and EDOOFUS, respectively.
 R> 
 R> As a side benefit, in the case of EDOOFUS this might be of interest to the Apple
 R> developers who complained about this macro name (i.e. they could use EGREGIOUS in
 R> Darwin exclussively if they want).
 
 The ENODATA error code is standardized as a part of XSI streams:
 
 http://www.opengroup.org/onlinepubs/000095399/basedefs/errno.h.html
 
 I don't think we should hardcode it equal to ENOATTR, which is a BSD specific
 code, afaik.
 
 P.S. My opinion isn't opinion of the project.
 
 -- 
 Totus tuus, Glebius.
 GLEBIUS-RIPN GLEB-RIPE

From: Robert Millan <rmh@aybabtu.com>
To: Gleb Smirnoff <glebius@FreeBSD.org>
Cc: FreeBSD-gnats-submit@FreeBSD.org, Jordan Hubbard <jkh@apple.com>
Subject: Re: kern/93705: [patch] ENODATA and EGREGIOUS (for glibc compat)
Date: Sun, 26 Feb 2006 19:36:17 +0100

 On Sun, Feb 26, 2006 at 02:35:48PM +0300, Gleb Smirnoff wrote:
 > On Wed, Feb 22, 2006 at 02:53:56PM +0100, Robert Millan wrote:
 > R> >Description:
 > R> Please could you add ENODATA and EGREGIOUS errno codes for compatibility with
 > R> Glibc systems?
 > R> 
 > R> They have the same meaning as ENOATTR and EDOOFUS, respectively.
 > R> 
 > R> As a side benefit, in the case of EDOOFUS this might be of interest to the Apple
 > R> developers who complained about this macro name (i.e. they could use EGREGIOUS in
 > R> Darwin exclussively if they want).
 > 
 > The ENODATA error code is standardized as a part of XSI streams:
 > 
 > http://www.opengroup.org/onlinepubs/000095399/basedefs/errno.h.html
 > 
 > I don't think we should hardcode it equal to ENOATTR, which is a BSD specific
 > code, afaik.
 
 Linux uses ENODATA for no attribute errors, which afaik is the same as ENOATTR.
 
 However since the XSI definition is more generic as you point out, perhaps it'd
 be better to rename ENOATTR to ENODATA and make ENOATTR an alias for ENODATA
 instead?
 
 -- 
 Robert Millan

From: Gleb Smirnoff <glebius@FreeBSD.org>
To: Robert Millan <rmh@aybabtu.com>
Cc: FreeBSD-gnats-submit@FreeBSD.org, Jordan Hubbard <jkh@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

From: Peter Pentchev <roam@ringlet.net>
To: Gleb Smirnoff <glebius@FreeBSD.org>
Cc: bug-followup@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@ringlet.net    roam@cnsys.bg    roam@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--

From: Garrett Cooper <gcooper@FreeBSD.org>
To: bug-followup@FreeBSD.org, rmh@aybabtu.com
Cc:  
Subject: Re: kern/93705: [headers] [patch] ENODATA and EGREGIOUS (for glibc compat)
Date: Sun, 16 Jan 2011 13:20:42 -0800

     For starters this should be listed under standards, not kern.
 Second off, FreeBSD hasn't made a real effort to implement XSI
 streams, so I don't think that this really should be `fixed', but
 instead glibc should be adapted to work without XSI streams on
 FreeBSD, because regardless of whether or not the data type is
 defined, if the libcall can't function properly when calling the
 kernel interfaces, having an additional set of datatypes is
 essentially superfluous support.
 Thanks,
 -Garrett
 
 PS Just like glebius@ I'm not representing the official opinion of the
 project :).

From: Garrett Cooper <gcooper@FreeBSD.org>
To: bug-followup@FreeBSD.org, rmh@aybabtu.com
Cc:  
Subject: Re: kern/93705: [headers] [patch] ENODATA and EGREGIOUS (for glibc compat)
Date: Sun, 16 Jan 2011 15:02:10 -0800

     My previous response was in regard to ENODATA, which is an
 obsolete XSI streams extension. EGREGIOUS wasn't present in Fedora
 13's glibc, so apparently it was removed (EDOOFUS isn't present either
 :)...).
 Thanks,
 -Garrett
State-Changed-From-To: open->closed 
State-Changed-By: linimon 
State-Changed-When: Sun Jan 16 23:27:06 UTC 2011 
State-Changed-Why:  
After some discussion, it seems that no one wants to implement these. 
Since submitter's email address now bounces, just close this one. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=93705 
>Unformatted:
