#4027 errno_t not exactly portable?
Opened 8 months ago by jhein. Modified 7 months ago

If you want to use errno_t, you should define __STDC_WANT_LIB_EXT1__ (as I understand the issue - see [1])

Or you could just use int.

[1] https://stackoverflow.com/questions/24206989/error-use-of-undeclared-identifier-errno-t

Metadata Update from @jhrozek:
- Issue close_status updated to: Invalid
- Issue status updated to: Closed (was: Open)

8 months ago

Metadata Update from @jhein:
- Issue status updated to: Open (was: Closed)

8 months ago

On the platform I was using (FreeBSD), sssd's configure detects errno_t okay (and defines HAVE_ERRNO_T in config.h). But after Python.h (from python3.6) is included, _POSIX_C_SOURCE is defined (to 200809). This turns off Annex K extensions (of which errno_t is a part) unless you specify you want them (by defining __STDC_WANT_LIB_EXT1__).

Thus most of the sssd code that references errno_t compiles fine, but src/python/pysss.c fails because it includes Python.h which sets a knob that disables the Annex K extensions. Maybe this is a header pollution bug in python - perhaps it should not export _POSIX_C_SOURCE to users of its public API header (Python.h).

But the result now is that if __STDC_WANT_LIB_EXT1__ is not defined, the following errors occur when building pysss.c :

In file included from src/python/pysss.c:27:
In file included from ./src/util/util.h:51:
./src/util/util_errors.h:130:26: error: unknown type name 'errno_t'

It seems to me that HAVE_ERRNO_T is not enough in config.h perhaps - it could also define __STDC_WANT_LIB_EXT1__.

Here is a patch to add __STDC_WANT_LIB_EXT1__ if errno_t is detected:

--- configure.ac.orig   2019-06-13 20:22:59 UTC
+++ configure.ac
@@ -45,6 +45,7 @@
 AC_CHECK_HEADERS(stdint.h dlfcn.h)

 AC_CHECK_TYPES([errno_t], [], [], [[#include <errno.h>]])
+AM_CONDITIONAL([HAVE_ERRNO_T], [test "$ac_cv_type_errno_t" = yes])

--- Makefile.am.orig    2019-06-13 20:22:59 UTC
+++ Makefile.am
@@ -123,6 +123,9 @@
                  -fno-strict-aliasing \

 pkgconfig_DATA =

Just using int instead of errno_tis probably more portable and certainly simpler. But the above fixes the case where errno_t is detected at configure time, and the Python.h header pollution turns on portability feature settings (e.g., _POSIX_C_SOURCE) that could disable the definition of errno_t in system headers.

I admit I can't tell if using this extra -D__STDC_WANT_LIB_EXT1__. My C/POSIX/standards knowledge is just not that deep. I would be wary of clashing with some of the GNU extensions or such.

All in all, isn't it better to keep the patch in freebsd tree as a downstream patch?

Login to comment on this ticket.