|Summary:||Patch to add ENODATA to errno.h|
|Product:||Base System||Reporter:||Willem Jan Withagen <wjw>|
|Component:||bin||Assignee:||freebsd-bugs mailing list <bugs>|
|Severity:||Affects Some People||CC:||emaste|
Description Willem Jan Withagen 2016-11-22 11:51:11 UTC
For porting Ceph to FreeBSD I'm in dire need of ENODATA as the equivalent of ENOATTR. The text of the opengroup on this is included at the end, in an excerpt of Email on hackers@ This would require the following patch. *** /usr/include/errno.h Mon Oct 3 02:05:43 2016 --- /usr/srcs/head/src/sys/sys/errno.h Sun Aug 21 18:25:05 2016 *************** *** 164,170 **** #define ECANCELED 85 /* Operation canceled */ #define EILSEQ 86 /* Illegal byte sequence */ #define ENOATTR 87 /* Attribute not found */ - #define ENODATA 87 /* Attribute not found */ #define EDOOFUS 88 /* Programming error */ #endif /* _POSIX_SOURCE */ --- 164,169 ---- > According the standard is ENODATA an extention of errno.h defines... > > http://pubs.opengroup.org/onlinepubs/9699919799/ > > The Open Group Base Specifications Issue 7 > IEEE Std 1003.1, 2013 Edition > > [ENODATA] > [OB XSR] [Option Start] > No message available. No message is available on the STREAM head > read queue. [Option End] > > [XSR] [Option Start] XSI STREAMS [Option End] > The functionality described is optional. The functionality described is > also an extension to the ISO C standard. > > Where applicable, functions are marked with the XSR margin legend in the > SYNOPSIS section. Where additional semantics apply to a function, the > material is identified by use of the XSR margin legend. > > [OB] [Option Start] Obsolescent [Option End] > The functionality described may be removed in a future version of this > volume of POSIX.1-2008. Strictly Conforming POSIX Applications and > Strictly Conforming XSI Applications shall not use obsolescent features. > > Where applicable, the material is identified by use of the OB margin legend. > ---- > > The OB part makes a bit strange to ask for definition, but would it be > possible to add ENODATA to our headers? > The alternative question is: why would we not? Well, it's defined for STREAMS and FreeBSD (and BSDs in general) don't implement STREAMS. OTOH, if Ceph has (ab)used it for their own internal errors then we could perhaps add our own ENODATA. Do you want to make a patch to do so?