Add new EINTEGRITY errno

[dim]

Summary

https://reviews.freebsd.org/D18765 will introduce a new errno value
EINTEGRITY to FreeBSD's system headers. In that review, the author
has also modified two libc++ headers to match, which I would like to
incorporate in stock libc++.

[mclow.lists]

include/errno.h

34–35

This chunk of ifdefs more than tripled in size when we went from "two possible additions" to "three possible additions". What happens when someone adds a fourth?

"Not sustainable" is the kindest thing I can say about this.

[emaste]

include/errno.h

34–35

Any suggestion on a sensible approach?

[dim]

Now that I'm reading this header again, why do we even bother to define ELAST at all? On Linux, there is no such thing, while on BSDs and macOS, it is already provided by the regular errno.h.

I also don't see why we would define EOWNERDEAD, ENOTRECOVERABLE and so on in this difficult way, if they are not defined by the system's errno.h. Could we just not use the same system as further down below, where we assign hopefully unique integer values over 9000?

[dim]

Get rid of the ELAST trickery, which is hard to maintain, and does not
appear to serve any purpose. There is no mention of ELAST in the C or
C++ standards, as far as I know.

Then, simply add the new EINTEGRITY define at the end with a unique
value, if it does not yet exist.

[dim]

N.B., EOWNERDEAD and ENOTRECOVERABLE are already defined on lines 158 and line 170, respectively.

[dim]

Ping :)

[dim]

Another attempt to grab your attention :)

[xbolva00]

cem == dim?

[dim]

In D56398#1742899, @xbolva00 wrote:

cem == dim?

No, cem is Conrad Meyer <[e-mail]>, while I'm Dimitry Andric ([e-mail] or alternatively, [e-mail]).

[xbolva00]

Aha, okay, but it would be better to get more “LGTM”s.

Maybe @jfb could take a look?

[ldionne]

Sorry if this is a basic question, but why are we trying to provide EINTEGRITY in libc++'s errno.h header at all? I don't see this being part of the C or C++ Standard.

If systems want to provide this macro, they can in their own errno.h header -- that's why we have a #include_next. I'd like to understand that before this proceeds. I do love removing the ELAST logic if we don't need it, though.

[dim]

In D56398#1744265, @ldionne wrote:

Sorry if this is a basic question, but why are we trying to provide EINTEGRITY in libc++'s errno.h header at all? I don't see this being part of the C or C++ Standard.

That is a very good question, this review has been sitting for so long that the reason also slipped my mind. :) @emaste any idea? As far as I remember, this "new" errno value was added by Kirk McKusick after he added integrity checks to the BSD FFS file system, and I suspect he just went through all headers that referred to file system specific errno values to extend them.

That said, doesn't libc++'s errno.h also provide lots of errno values that are not standardized anywhere? (I'm not even sure if there *is* a standardized list of "must support" errno values...)

If systems want to provide this macro, they can in their own errno.h header -- that's why we have a #include_next. I'd like to understand that before this proceeds. I do love removing the ELAST logic if we don't need it, though.

Yes, I could not really figure out the rationale for the ELAST logic was there, since it was there from the start. Maybe @howard.hinnant remembers.

[howard.hinnant]

I don't recall exactly what ELAST was for either. Though something like this is typically used to see if an enum/integral value is within the range of the declared enums.

I recommend looking at https://github.com/llvm-mirror/libcxx/blob/master/src/include/config_elast.h (which I don't recall writing) for clues about which platform needs ELAST and which don't. And for those that do need it, why.

[ldionne]

In D56398#1744453, @dim wrote:

In D56398#1744265, @ldionne wrote:

Sorry if this is a basic question, but why are we trying to provide EINTEGRITY in libc++'s errno.h header at all? I don't see this being part of the C or C++ Standard.

That is a very good question, this review has been sitting for so long that the reason also slipped my mind. :) @emaste any idea? As far as I remember, this "new" errno value was added by Kirk McKusick after he added integrity checks to the BSD FFS file system, and I suspect he just went through all headers that referred to file system specific errno values to extend them.

That said, doesn't libc++'s errno.h also provide lots of errno values that are not standardized anywhere? (I'm not even sure if there *is* a standardized list of "must support" errno values...)

I'd ask the same question. Actually, more generally, why does libc++ even provide errno.h? Shouldn't we simply assume the C Standard library implementation to provide one? I have the impression that this sort of header cleverness just provides us with a blessed location to insert platform-specific hacks, instead of actually making those platforms conforming. But I don't really understand the context, so I might be wrong and maybe <errno.h> is important in libc++.

[ldionne]

Since we should pick up FreeBSD's EINTEGRITY via include_next, I don't see why we need this patch. Can we abandon?

[dim]

In D56398#2038621, @ldionne wrote:

Since we should pick up FreeBSD's EINTEGRITY via include_next, I don't see why we need this patch. Can we abandon?

I guess so. But maybe the whole ELAST logic could be ripped out, as it does not seem to serve any purpose anymore? The whole difficult #ifdef stuff is only to define some "really last" error number, and it's only used to define the EOWNERDEAD and ENOTRECOVERABLE values, which for some reason are 'special'. But just a few lines below, a bunch of EXXX values just get defined to self-chosen values...

Let's indeed abandon this, and I'll come up with a diff to get rid of this whole first block.

[ldionne]

In D56398#2038671, @dim wrote:

I guess so. But maybe the whole ELAST logic could be ripped out, as it does not seem to serve any purpose anymore? The whole difficult #ifdef stuff is only to define some "really last" error number, and it's only used to define the EOWNERDEAD and ENOTRECOVERABLE values, which for some reason are 'special'. But just a few lines below, a bunch of EXXX values just get defined to self-chosen values...

Let's indeed abandon this, and I'll come up with a diff to get rid of this whole first block.

Thank you, cleaning that up would be great!

include/errno.h

 
 #if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
 #pragma GCC system_header
 #endif
 
 #include_next <errno.h>
 
 #ifdef __cplusplus
 
-#if !defined(EOWNERDEAD) || !defined(ENOTRECOVERABLE)
-
-#ifdef ELAST
-
-static const int __elast1 = ELAST+1;
-static const int __elast2 = ELAST+2;
-
-#else
-
-static const int __elast1 = 104;
-static const int __elast2 = 105;
-
-#endif
-
-#ifdef ENOTRECOVERABLE
-
-#define EOWNERDEAD __elast1
-
-#ifdef ELAST
-#undef ELAST
-#define ELAST EOWNERDEAD
-#endif
-
-#elif defined(EOWNERDEAD)
-
-#define ENOTRECOVERABLE __elast1
-#ifdef ELAST
-#undef ELAST
-#define ELAST ENOTRECOVERABLE
-#endif
-
-#else  // defined(EOWNERDEAD)
-
-#define EOWNERDEAD __elast1
-#define ENOTRECOVERABLE __elast2
-#ifdef ELAST
-#undef ELAST
-#define ELAST ENOTRECOVERABLE
-#endif
-
-#endif  // defined(EOWNERDEAD)
-
-#endif  // !defined(EOWNERDEAD) || !defined(ENOTRECOVERABLE)
-
 //  supply errno values likely to be missing, particularly on Windows
 
 #ifndef EAFNOSUPPORT
 #define EAFNOSUPPORT 9901
 #endif
 
 #ifndef EADDRINUSE
 #define EADDRINUSE 9902
 #endif

 #ifndef EMFILE
 #define EMFILE 9978
 #endif
 
 #ifndef EMLINK
 #define EMLINK 9979
 #endif
 
-#endif // __cplusplus
+#ifndef EINTEGRITY
+#define EINTEGRITY 9980
+#endif
 
 #endif  // _LIBCPP_ERRNO_H