aboutsummaryrefslogtreecommitdiff
path: root/include/bits
AgeCommit message (Collapse)AuthorFilesLines
2019-03-01ldbl-opt: Add error and error_at_line (bug 23984)Gabriel F. T. Gomes1-0/+1
On platforms where long double may have the same format as double (-mlong-double-64), error and error_at_line do not take that into account and might produce wrong output if a long double conversion is requested by the format string ('%Lf'). This patch adds compatibility functions for this situation and redirects calls via header magic. Tested for powerpc, powerpc64 and powerpc64le.
2019-03-01ldbl-opt: Add err, errx, verr, verrx, warn, warnx, vwarn, and vwarnx (bug 23984)Gabriel F. T. Gomes1-0/+1
When support for long double format with 128-bits (-mlong-double-128) was added for platforms where long double had the same format as double, such as powerpc, compatibility versions for the functions listed in the commit title were missed. Since the older format of long double can still be used (with -mlong-double-64), using these functions with a format string that requests the printing of long double variables will produce wrong outputs. This patch adds the missing compatibility functions and header magic to redirect calls to them when -mlong-double-64 is in use. Tested for powerpc, powerpc64 and powerpc64le.
2019-03-01ldbl-opt: Add argp_error and argp_failure (bug 23983)Gabriel F. T. Gomes1-0/+1
The functions argp_error and argp_failure are missing support for printing long double values when long double has the same format as double. This patch adds the new functions __nldbl_argp_error and __nldbl_argp_failure, as well as header magic to redirect calls to them when -mlong-double-64 is in use. Tested for powerpc, powerpc64 and powerpc64le.
2019-02-16Add missing header wrappers under include/Florian Weimer3-0/+3
With a complete set of wrapper headers, it will be possible to check for automatically for new installed headers which lack such wrappers. Reviewed-by: Carlos O'Donell <carlos@redhat.com>
2019-02-08Provide <bits/unistd_ext.h> as a sysdeps header exclusivelyFlorian Weimer1-1/+0
Non-sysdeps headers cannot be overriden by sysdeps headers across the entire build, so it is necessary to turn such extension headers into sysdeps headers themselves. The approach here follows the existing <bits/shm.h> header (although it uses sysdeps/gnu instead of sysdeps/generic). Fixes commit 1d0fc213824eaa2a8f8c4385daaa698ee8fb7c92 ("Linux: Add gettid system call wrapper [BZ #6399]") and commit 8f89ab216f205c2ffd90d1fc8454efdfc0b01dee ("posix: Fix missing wrapper header for <bits/unistd_ext.h>").
2019-02-08posix: Fix missing wrapper header for <bits/unistd_ext.h>Florian Weimer1-0/+1
Fixes commit 1d0fc213824eaa2a8f8c4385daaa698ee8fb7c92 ("Linux: Add gettid system call wrapper [BZ #6399]"). Reviewed-by: Carlos O'Donell <carlos@redhat.com>
2019-01-01Update copyright dates with scripts/update-copyrights.Joseph Myers1-1/+1
* All files with FSF copyright notices: Update copyright dates using scripts/update-copyrights. * locale/programs/charmap-kw.h: Regenerated. * locale/programs/locfile-kw.h: Likewise.
2018-12-11Add *-ldbl.h headers to include/bitsGabriel F. T. Gomes6-0/+6
On some platforms, long double may have either the same format as double or another, wider format, such as the Quadruple IEC 60559 long double format or the IBM Extended Precision format (both 128-bits wide). Selecting between the available formats is done by using one of the following compiler switches: -mlong-double-128, for the wider format, or -mlong-double-64, for the narrower. On all platforms that provide this choice, the wider format is the default. When the non-default format is selected by user code (i.e.: when building with -mlong-double-64) calls to functions that take long double parameters or return a long double type (e.g.: strfroml) are redirected to a compat function, via assembler redirection, by headers such as bits/stdlib-ldbl.h or bits/misc-ldbl.h. In glibc builds, however, these headers are currently being read from the system directories (/usr/include/bits) rather than from the source directory. Although this works correctly today, it raises reproducibility concerns. Besides that, builds for powerpc64le will need these files from the source directory, because on powerpc64le, the new redirections for long double with IEEE binary128 format will be implemented in these headers. Tested for powerpc64 and powerpc64le.
2018-07-10Add the statx functionFlorian Weimer1-0/+1
2018-02-09Add build infrastructure for narrowing libm functions.Joseph Myers1-0/+1
TS 18661-1 defines libm functions that carry out an operation (+ - * / sqrt fma) on their arguments and return a result rounded to a (usually) narrower type, as if the original result were computed to infinite precision and then rounded directly to the result type without any intermediate rounding to the argument type. For example, fadd, faddl and daddl for addition. These are the last remaining TS 18661-1 functions left to be added to glibc. TS 18661-3 extends this to corresponding functions for _FloatN and _FloatNx types. As functions parametrized by two rather than one varying floating-point types, these functions require infrastructure in glibc that was not required for previous libm functions. This patch provides such infrastructure - excluding test support, and actual function implementations, which will be in subsequent patches. Declaring the functions uses a header bits/mathcalls-narrow.h, which is included many times, for each relevant pair of types. This will end up containing macro calls of the form __MATHCALL_NARROW (__MATHCALL_NAME (add), __MATHCALL_REDIR_NAME (add), 2); for each family of narrowing functions. (The structure of this macro call, with the calls to __MATHCALL_NAME and __MATHCALL_REDIR_NAME there rather than in the definition of __MATHCALL_NARROW, arises from the names such as "add" *not* themselves being reserved identifiers - meaning it's necessary to avoid any indirection that would result in a user-defined "add" macro being expanded.) Whereas for existing functions declaring long double functions is disabled if _LIBC in the case where they alias double functions, to facilitate defining the long double functions as aliases of the double ones, there is no such logic for the narrowing functions in this patch. Rather, the files defining such functions are expected to use #define to hide the original declarations of the alias names, to avoid errors about defining aliases with incompatible types. math/Makefile support is added for building the functions (listed in libm-narrow-fns, currently empty) for all relevant pairs of types. An internal header math-narrow.h is added for macros shared between multiple function implementations - currently a ROUND_TO_ODD macro to facilitate writing functions using the round-to-odd implementation approach, and alias macros to create all the required function aliases. libc_feholdexcept_setroundf128 and libc_feupdateenv_testf128 are added for use when required (only for x86_64). float128_private.h support is added for ldbl-128 narrowing functions to be used for _Float128. Certain things are specifically omitted from this patch and the immediate followups. tgmath.h support is deferred; there remain unresolved questions about how the type-generic macros for these functions are supposed to work, especially in the case of arguments of integer type. The math.h / bits/mathcalls-narrow.h logic, and the logic for determining what functions / aliases to define, will need some adjustments to support the sqrt and fma functions, where e.g. f32xsqrtf64 can just be an alias for sqrt rather than a separate function. TS 18661-1 defines FP_FAST_* macros but no support is included for defining them (they won't in general be true without architecture-specific optimized function versions). For each of the function groups (add sub mul div sqrt fma) there are always six functions present (e.g. fadd, faddl, daddl, f32addf64, f32addf32x, f32xaddf64). When _Float64x and _Float128 are supported, there are seven more (e.g. f32addf64x, f32addf128, f64addf64x, f64addf128, f32xaddf64x, f32xaddf128, f64xaddf128). In addition, in the ldbl-opt case there are function names such as __nldbl_daddl (an alias for f32xaddf64, which is not a reserved name in TS 18661-1, only in TS 18661-3), for calls to daddl to be mapped to in the -mlong-double-64 case. (Calls to faddl just get mapped to fadd, and for sqrt and fma there won't be __nldbl_* functions because dsqrtl and dfmal can just be mapped to sqrt and fma with -mlong-double-64.) While there are six or thirteen functions present in each group (plus __nldbl_* names only as an ABI, not an API), not all are distinct; they fall in various groups of aliases. There are two distinct versions built if long double has the same format as double; four if they have distinct formats but there is no _Float64x or _Float128 support; five if long double has binary128 format; seven when _Float128 is distinct from long double. Architecture-specific optimized versions are possible, but not included in my patches. For example, IA64 generally supports narrowing the result of most floating-point instructions; Power ISA 2.07 (POWER8) supports double values as arguments to float instructions, with the results narrowed as expected; Power ISA 3 (POWER9) supports round-to-odd for float128 instructions, so meaning that approach can be used without needing to set and restore the rounding mode and test "inexact". I intend to leave any such optimized versions to the architecture maintainers. Generally in such cases it would also make sense for calls to these functions to be expanded inline (given -fno-math-errno); I put a suggestion for TS 18661-1 built-in functions at <https://gcc.gnu.org/wiki/SummerOfCode>. Tested for x86_64 (this patch in isolation, as well as testing for various configurations in conjunction with further patches). * math/bits/mathcalls-narrow.h: New file. * include/bits/mathcalls-narrow.h: Likewise. * math/math-narrow.h: Likewise. * math/math.h (__MATHCALL_NARROW_ARGS_1): New macro. (__MATHCALL_NARROW_ARGS_2): Likewise. (__MATHCALL_NARROW_ARGS_3): Likewise. (__MATHCALL_NARROW_NORMAL): Likewise. (__MATHCALL_NARROW_REDIR): Likewise. (__MATHCALL_NARROW): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT)]: Repeatedly include <bits/mathcalls-narrow.h> with _Mret_, _Marg_ and __MATHCALL_NAME defined. [__GLIBC_USE (IEC_60559_TYPES_EXT)]: Likewise. * math/Makefile (headers): Add bits/mathcalls-narrow.h. (libm-narrow-fns): New variable. (libm-narrow-types-basic): Likewise. (libm-narrow-types-ldouble-yes): Likewise. (libm-narrow-types-float128-yes): Likewise. (libm-narrow-types-float128-alias-yes): Likewise. (libm-narrow-types): Likewise. (libm-routines): Add narrowing functions. * sysdeps/i386/fpu/fenv_private.h [__x86_64__] (libc_feholdexcept_setroundf128): New macro. [__x86_64__] (libc_feupdateenv_testf128): Likewise. * sysdeps/ieee754/float128/float128_private.h: Include <math/math-narrow.h>. [libc_feholdexcept_setroundf128] (libc_feholdexcept_setroundl): Undefine and redefine. [libc_feupdateenv_testf128] (libc_feupdateenv_testl): Likewise. (libm_alias_float_ldouble): Undefine and redefine. (libm_alias_double_ldouble): Likewise.
2018-02-07Post-cleanup 1: move libio.h back out of bits/.Zack Weinberg1-45/+0
We can't go very far with libio cleanups as long as we still have _IO_MTSAFE_IO, and I am not tackling that in this patch series, but we can at least make the maze of stdio-related headers a little less complicated. In this patch, libio.h moves back out of bits/ into the top level of the libio subdirectory, and is merged with libio/bits/libio-ldbl.h (which also used to be installed) and include/libio.h. Since almost no files include libio.h directly, this is quite straightforward. libio.h is now always used with _LIBC defined, so all of the _LIBC || _GLIBCPP_USE_WCHAR_T conditionals are unnecessary. Similarly, the ifdef nest surrounding the definition of _IO_fwide_maybe_incompatible can collapse down to a single SHLIB_COMPAT check. I also took the opportunity to add some checks for configuration botches to libio.h. Installed stripped libraries are unchanged by this patch. * libio/bits/libio.h: Move back to libio/libio.h and adjust multiple-include guard to match. Merge contents of libio/bits/libio-ldbl.h and include/libio.h into this file. Remove preprocessor conditionals that are always true and/or redundant to other preprocessor conditionals in the same nest. Include shlib-compat.h unconditionally. Error out if _LIBC is not defined, or if _ISOMAC is defined, or if _IO_MTSAFE_IO is defined but _IO_lock_t_defined is not defined after including stdio.h. Use __BEGIN_DECLS/__END_DECLS. * libio/bits/libio-ldbl.h, include/bits/libio.h: Delete file. * include/stdio.h, libio/iolibio.h, libio/libioP.h: Include libio.h as <libio/libio.h> rather than as <bits/libio.h>.
2018-02-07Don't install libio.h or _G_config.h.Zack Weinberg4-0/+4
We shipped 2.27 with libio.h and _G_config.h still installed but issuing warnings when used. Let's stop installing them early in 2.28 so that we have plenty of time to think of another plan if there are problems. The public stdio.h had a genuine dependency on libio.h for the complete definitions of FILE and cookie_io_functions_t, and a genuine dependency on _G_config.h for the complete definitions of fpos_t and fpos64_t; these are moved to single-type headers. bits/types/struct_FILE.h also provides a handful of accessor and bitflags macros so that code is not duplicated between bits/stdio.h and libio.h. All the other _IO_ and _G_ names used by the public stdio.h can be replaced with either public names or __-names. In order to minimize the risk of breaking our own compatibility code, bits/types/struct_FILE.h preserves the _IO_USE_OLD_IO_FILE mechanism exactly as it was in libio.h, but you have to define _LIBC to use it, or it'll error out. Similarly, _IO_lock_t_defined is preserved exactly, but will error out if used without defining _LIBC. Internally, include/stdio.h continues to include libio.h, and libio.h scrupulously provides every _IO_* and _G_* name that it always did, perhaps now defined in terms of the public names. This is how this patch avoids touching dozens of files throughout glibc and becoming entangled with the _IO_MTSAFE_IO mess. The remaining patches in this series eliminate most of the _G_ names. Tested on x86_64-linux; in addition to the test suite, I installed the library in a sysroot and verified that a simple program that uses stdio.h could be compiled against the installed library, and I also verified that installed stripped libraries are unchanged. * libio/bits/types/__fpos_t.h, libio/bits/types/__fpos64_t.h: New single-type headers split from _G_config.h. * libio/bits/types/cookie_io_functions_t.h * libio/bits/types/struct_FILE.h New single-type headers split from libio.h. * libio/Makefile: Install the above new headers. Don't install libio.h, _G_config.h, bits/libio.h, bits/_G_config.h, or bits/libio-ldbl.h. * libio/_G_config.h, libio/libio.h: Delete file. * libio/bits/libio.h: Remove improper-inclusion guard. Include stdio.h and don't repeat anything that it does. Define _IO_fpos_t as __fpos_t, _IO_fpos64_t as __fpos64_t, _IO_BUFSIZ as BUFSIZ, _IO_va_list as __gnuc_va_list, __io_read_fn as cookie_read_function_t, __io_write_fn as cookie_write_function_t, __io_seek_fn as cookie_seek_function_t, __io_close_fn as cookie_close_function_t, and _IO_cookie_io_functions_t as cookie_io_functions_t. Define _STDIO_USES_IOSTREAM, __HAVE_COLUMN, and _IO_file_flags here, in the "compatibility defines" section. Remove an #if 0 block. Use the "body" macros from bits/types/struct_FILE.h to define _IO_getc_unlocked, _IO_putc_unlocked, _IO_feof_unlocked, and _IO_ferror_unlocked. Move prototypes of __uflow and __overflow... * libio/stdio.h: ...here. Don't include bits/libio.h. Don't define _STDIO_USES_IOSTREAM. Get __gnuc_va_list directly from stdarg.h. Include bits/types/__fpos_t.h, bits/types/__fpos64_t.h, bits/types/struct_FILE.h, and, when __USE_GNU, bits/types/cookie_io_functions_t.h. Use __gnuc_va_list, not _G_va_list; __fpos_t, not _G_fpos_t; __fpos64_t, not _G_fpos64_t; FILE, not struct _IO_FILE; cookie_io_functions_t, not _IO_cookie_io_functions_t; __ssize_t, not _IO_ssize_t. Unconditionally define BUFSIZ as 8192 and EOF as (-1). * libio/bits/stdio.h: Add multiple-include guard. Use the "body" macros from bits/types/struct_FILE.h instead of _IO_* macros from libio.h; use __gnuc_va_list instead of va_list and __ssize_t instead of _IO_ssize_t. * libio/bits/stdio2.h: Similarly. * libio/iolibio.h: Add multiple-include guard. Include bits/libio.h after stdio.h. * libio/libioP.h: Add multiple-include guard. Include stdio.h and bits/libio.h before iolibio.h. * include/bits/types/__fpos_t.h, include/bits/types/__fpos64_t.h * include/bits/types/cookie_io_functions_t.h * include/bits/types/struct_FILE.h: New wrappers. * bits/_G_config.h, sysdeps/unix/sysv/linux/_G_config.h: Get definitions of _G_fpos_t and _G_fpos64_t from bits/types/__fpos_t.h and bits/types/__fpos64_t.h respectively. Remove improper-inclusion guards. * conform/data/stdio.h-data: Update expectations of va_list. * scripts/check-installed-headers.sh: Remove special case for libio.h and _G_config.h.
2018-01-01Update copyright dates with scripts/update-copyrights.Joseph Myers1-1/+1
* All files with FSF copyright notices: Update copyright dates using scripts/update-copyrights. * locale/programs/charmap-kw.h: Regenerated. * locale/programs/locfile-kw.h: Likewise.
2017-12-24Deprecate external use of libio.h and _G_config.h.Zack Weinberg1-0/+45
libio.h was originally the header for a set of supported GNU extensions, but they have not been maintained as such in many years, they are now standing in the way of improvements to stdio, and we don't think there are any remaining external users. _G_config.h was never intended for public use, but predates the bits convention. Move both of these headers into the bits directory and provide stubs at top level which issue deprecation warnings. The contents of (bits/)libio.h and (bits/)_G_config.h are still exposed to external software via stdio.h; changing that requires more complex surgery than I have time to attempt right now. * libio/libio.h, libio/_G_config.h: New stub headers which issue a deprecation warning and then include <bits/libio.h>, <bits/_G_config.h> respectively. * libio/libio.h: Rename the original version of this file to libio/bits/libio.h. Error out if not included by stdio.h or the stub libio.h. * include/libio.h: Move to include/bits. Forward to libio/bits/libio.h. * sysdeps/generic/_G_config.h: Move to top-level bits/. Error out if not included by bits/libio.h or the stub _G_config.h. * sysdeps/unix/sysv/linux/_G_config.h: Move to sysdeps/unix/sysv/linux/bits. Error out if not included by bits/libio.h or the stub _G_config.h. * libio/stdio.h: Include bits/libio.h, not libio.h. * libio/Makefile: Install bits/libio.h and bits/_G_config.h as well as libio.h and _G_config.h. * csu/init.c, libio/fmemopen.c, libio/iolibio.h, libio/oldfmemopen.c * libio/strfile.h, stdio-common/vfscanf.c * sysdeps/pthread/flockfile.c, sysdeps/pthread/funlockfile.c Include stdio.h, not _G_config.h nor libio.h. * libio/iofgetpos.c: Also rename fgetpos64 out of the way. * libio/iofsetpos.c: Also rename fsetpos64 out of the way. * scripts/check-installed-headers.sh: Skip libio.h and _G_config.h.
2017-08-16Fix sigval namespace (bug 21944).Joseph Myers1-0/+1
XPG4.2 defines the siginfo_t type, but not union sigval or its contents (which were added in the 1993 edition of POSIX.1), resulting in namespace violations for sigval, sival_int and sival_ptr for signal.h and sys/wait.h for that standard because those headers incorrectly expose those names in that case. This patch fixes this problem. The public type in this case is union sigval, but various places in the headers use the sigval_t name for it; direct uses of union sigval are already properly guarded or in headers not in XPG4.2. Now, sigval_t, although not a standard name, does seem to be widely used outside glibc. The approach taken by this patch is to make installed headers use the name __sigval_t instead. __sigval_t is then defined to either union sigval or union __sigval (where union __sigval has __-prefixed member names as well), depending on whether there are any namespace issues with the union sigval name and its members. In the case where union __sigval is used, sigval_t is not defined at all, to avoid the problem of sigval_t having a C++ mangled name that depends on feature test macros. sigval_t is still defined by signal.h if __USE_MISC (reflecting the nonstandard nature of that name). Tested for x86_64. [BZ #21944] * signal/bits/types/__sigval_t.h: New file. * signal/Makefile (headers): Add bits/types/__sigval_t.h. * signal/bits/types/sigval_t.h: Include <bits/types/__sigval_t.h> and define sigval_t using __sigval_t. * include/bits/types/__sigval_t.h: New file. * bits/types/sigevent_t.h: Include <bits/types/__sigval_t.h> instead of <bits/types/__sigval_t.h>. (struct sigevent): Use __sigval_t instead of sigval_t. * bits/types/siginfo_t.h: Include <bits/types/__sigval_t.h> instead of <bits/types/__sigval_t.h>. (siginfo_t): Use __sigval_t instead of sigval_t. * sysdeps/unix/sysv/linux/bits/types/sigevent_t.h: Include <bits/types/__sigval_t.h> instead of <bits/types/__sigval_t.h>. (struct sigevent): Use __sigval_t instead of sigval_t. * sysdeps/unix/sysv/linux/bits/types/siginfo_t.h: Include <bits/types/__sigval_t.h> instead of <bits/types/__sigval_t.h>. (siginfo_t): Use __sigval_t instead of sigval_t. * signal/signal.h [__USE_MISC]: Include <bits/types/sigval_t.h>.
2017-06-20Rename xlocale.h to bits/types/__locale_t.h.Zack Weinberg2-0/+2
xlocale.h is already a single-type micro-header, defining struct __locale_struct and the typedefs __locale_t and locale_t. This patch brings it into the bits/types/ scheme: there are now bits/types/__locale_t.h which defines only __locale_struct and __locale_t, and bits/types/locale_t.h which defines locale_t as well as the other two. None of *our* headers need __locale_t.h, but it appears to me that libstdc++ could make use of it. There are a lot of external uses of xlocale.h, but all the uses I checked had an autoconf test or equivalent for its existence. It has never been available from other C libraries, and it has always contained a comment reading "This file is not standardized, don't rely on it, it can go away without warning" so I think dropping it is pretty safe. I also took the opportunity to clean up comments in various public header files that still talk about the *_l interfaces as though they were completely nonstandard. There are a few of them, notably the strtoX_l and wcstoX_l families, that haven't been standardized, but the bulk are in POSIX.1-2008. * locale/xlocale.h: Rename to... * locale/bits/types/__locale_t.h: ...here. Adjust commentary. Only define struct __locale_struct and __locale_t, not locale_t. * locale/bits/types/locale_t.h: New file; define locale_t here. * locale/Makefile (headers): Update to match. * include/xlocale.h: Delete wrapper. * include/bits/types/__locale_t.h: New wrapper. * include/bits/types/locale_t.h: New wrapper. * ctype/ctype.h, include/printf.h, include/time.h * locale/langinfo.h, locale/locale.h, stdlib/monetary.h * stdlib/stdlib.h, string/string.h, string/strings.h, time/time.h * wcsmbs/wchar.h, wctype/wctype.h: Use bits/types/locale_t.h. Correct outdated comments regarding the standardization status of the functions that take locale_t arguments. * stdlib/strtod_l.c, stdlib/strtof_l.c, stdlib/strtol_l.c * stdlib/strtold_l.c, stdlib/strtoul_l.c, stdlib/strtoull_l.c * sysdeps/ieee754/ldbl-128ibm/strtold_l.c * sysdeps/ieee754/ldbl-64-128/strtold_l.c * wcsmbs/wcstod.c, wcsmbs/wcstod_l.c, wcsmbs/wcstof.c * wcsmbs/wcstof_l.c, wcsmbs/wcstold.c, wcsmbs/wcstold_l.c: Don't include xlocale.h. If necessary, include locale.h instead. * stdlib/strtold_l.c: Unconditionally include wchar.h.
2017-06-20Remove bits/string.h.Zack Weinberg2-1/+1
These machine-dependent inline string functions have never been on by default, and even if they were a good idea at the time they were introduced, they haven't really been touched in ten to fifteen years and probably aren't a good idea on current-gen processors. Current thinking is that this class of optimization is best left to the compiler. * bits/string.h, string/bits/string.h * sysdeps/aarch64/bits/string.h * sysdeps/m68k/m680x0/m68020/bits/string.h * sysdeps/s390/bits/string.h, sysdeps/sparc/bits/string.h * sysdeps/x86/bits/string.h: Delete file. * string/string.h: Don't include bits/string.h. * string/bits/string3.h: Rename to bits/string_fortified.h. No need to undef various symbols that the removed headers might have defined as macros. * string/Makefile (headers): Remove bits/string.h, change bits/string3.h to bits/string_fortified.h. * string/string-inlines.c: Update commentary. Remove definitions of various macros that nothing looks at anymore. Don't directly include bits/string.h. Set _STRING_INLINE_unaligned here, based on compiler-predefined macros. * string/strncat.c: If STRNCAT is not defined, or STRNCAT_PRIMARY _is_ defined, provide internal hidden alias __strncat. * include/string.h: Declare internal hidden alias __strncat. Only forward __stpcpy to __builtin_stpcpy if __NO_STRING_INLINES is not defined. * include/bits/string3.h: Rename to bits/string_fortified.h, update to match above. * sysdeps/i386/string-inlines.c: Define compat symbols for everything formerly defined by sysdeps/x86/bits/string.h. Make existing definitions into compat symbols as well. Remove some no-longer-necessary messing around with macros. * sysdeps/powerpc/powerpc32/power4/multiarch/mempcpy.c * sysdeps/powerpc/powerpc64/multiarch/mempcpy.c * sysdeps/powerpc/powerpc64/multiarch/stpcpy.c * sysdeps/s390/multiarch/mempcpy.c No need to define _HAVE_STRING_ARCH_mempcpy. Do define __NO_STRING_INLINES and NO_MEMPCPY_STPCPY_REDIRECT. * sysdeps/i386/i686/multiarch/strncat-c.c * sysdeps/s390/multiarch/strncat-c.c * sysdeps/x86_64/multiarch/strncat-c.c Define STRNCAT_PRIMARY. Don't change definition of libc_hidden_def.
2017-06-19Define struct rusage in sys/wait.h when required (bug 21575).Joseph Myers1-0/+1
Some older standards (XPG4.2 through POSIX.1:2001, XSI only) require sys/wait.h to include the definition of struct rusage. This is missing in glibc. This patch adds the required definition. struct rusage is moved to a new header bits/types/struct_rusage.h to avoid bringing in the whole of sys/resource.h (although the standards in question do allow the whole of sys/resource.h to be brought in). In the five bits/resource.h headers, the only variation between the definitions of struct rusage is that the sysdeps/unix/sysv/linux version is prepared for x32 (by having anonymous unions with __syscall_slong_t fields) and the others are not. Thus, this version is suitable for use generically (everything other than x32 simply has __syscall_slong_t the same as long int, so there are no API or ABI changes involved, and anonymous unions are already a required language feature for glibc headers elsewhere), and this patch uses it as a base for the single implementation of bits/types/struct_rusage.h. Tested for x86_64, and with build-many-glibcs.py. [BZ #21575] * resource/bits/types/struct_rusage.h: New file. * include/bits/types/struct_rusage.h: Likewise. * bits/resource.h (struct rusage): Include <bits/types/struct_rusage.h> instead of defining here. * sysdeps/unix/sysv/linux/bits/resource.h (struct rusage): Likewise. * sysdeps/unix/sysv/linux/alpha/bits/resource.h (struct rusage): Likewise. * sysdeps/unix/sysv/linux/mips/bits/resource.h (struct rusage): Likewise. * sysdeps/unix/sysv/linux/sparc/bits/resource.h (struct rusage): Likewise. * resource/Makefile (headers): Add bits/types/struct_rusage.h. * posix/sys/wait.h [__USE_XOPEN_EXTENDED && !__USE_XOPEN2K8]: Include <bits/types/struct_rusage.h>
2017-06-14Remove __need_IOV_MAX and __need_FOPEN_MAX.Zack Weinberg1-5/+8
__need_FOPEN_MAX wasn't being used anywhere. __need_IOV_MAX was more complicated; the basic deal is that sys/uio.h wants to define a constant named UIO_MAXIOV and bits/xopen_lim.h wants to define a constant named IOV_MAX, with the same meaning. For no apparent reason this was being handled via bits/stdio_lim.h -- stdio.h is NOT supposed to define IOV_MAX -- and some mess in Makerules. Also, bits/uio.h on Linux was being used as a dumping ground for extension functions. So now we have bits/uio_lim.h, which defines __IOV_MAX. bits/xopen_lim.h and sys/uio.h use that to define their respective constants. We also now have bits/uio-ext.h, which is the official Proper Home for extensions to sys/uio.h. bits/uio.h is removed, and stdio_lim.h doesn't define IOV_MAX at all. * bits/uio_lim.h, sysdeps/unix/sysv/linux/bits/uio_lim.h * bits/uio-ext.h, sysdeps/unix/sysv/linux/bits/uio-ext.h: New file. * bits/uio.h, sysdeps/unix/sysv/linux/bits/uio.h: Delete file. * include/bits/xopen_lim.h: Use bits/uio_lim.h to get the value for IOV_MAX. * misc/Makefile: Install bits/uio-ext.h and bits/uio_lim.h. Don't install bits/uio.h. * misc/sys/uio.h: Don't include bits/uio.h. Do include bits/types/struct_iovec.h and bits/uio_lim.h. Set UIO_MAXIOV based on __IOV_MAX. Under __USE_GNU, also include bits/uio-ext.h. * stdio-common/stdio_lim.h.in: Remove logic for __need_FOPEN_MAX and __need_IOV_MAX. Don't define IOV_MAX at all. * Makerules (stdio_lim.h): Remove logic for setting IOV_MAX. * sysdeps/unix/sysv/linux/bits/fcntl-linux.h: Include bits/types/struct_iovec.h, not bits/uio.h. Use __ssize_t, not ssize_t, in function prototypes. Don't use hard TAB for double space after period in comments.
2017-06-12Remove __need_schedparam and __cpu_set_t_defined.Zack Weinberg1-0/+1
bits/sched.h has logic to expose only an impl-namespace variant of struct sched_param (i.e. struct __sched_param), but nothing uses it, and the only header that includes bits/sched.h is sched.h. The __need_schedparam logic can therefore be removed. bits/sched.h also has a great deal of code relating to cpu_set_t objects that was *almost* the same between the two versions of bits/sched.h in the tree; a little spelunking indicated that this is because some bug fixes got applied to the Linux-specific bits/sched.h but not the generic one. Introduce a new header, bits/cpu-set.h, containing the version of that code with the bugfixes, have sched.h include it directly, and delete all of the code from both versions of bits/sched.h. Also remove the unnecessary name mangling in the definition of struct sched_param -- POSIX specifies a field 'sched_priority', so there is no reason to define it as '__sched_priority' and then paper over that with a macro. (Just in case someone was using the internal name, 'sched_priority' remains a macro defined to expand to itself, and '__sched_priority' now expands to 'sched_priority'.) Finally, as long as I'm touching these files anyway, merge new constants from linux/sched.h into the Linux bits/sched.h. * bits/sched.h: Remove __need_schedparam logic and replace with a normal multiple-include guard. Change field name in struct sched_param from __sched_priority to sched_priority. Delete everything under #ifndef __cpu_set_t_defined. * sysdeps/unix/sysv/linux/bits/sched.h: Likewise. Also sync with kernel sched.h, adding SCHED_ISO and SCHED_DEADLINE constants. * posix/sched.h: Include bits/cpu-set.h as well as bits/sched.h. For compatibility, #define sched_priority to itself, and #define __sched_priority as sched_priority. * posix/bits/cpu-set.h: New file containing, verbatim, the code that was under #ifndef __cpu_set_t_defined in sysdeps/unix/sysv/linux/bits/sched.h. * include/bits/cpu-set.h: New wrapper. * posix/Makefile: Install bits/cpu-set.h.
2017-06-08Remove __need macros from stdio.h and wchar.h.Zack Weinberg6-0/+6
wint_t is a little finicky because it might be defined by stddef.h, which belongs to the compiler. In addition to the _types_, a bunch of other declarations shared between wctype.h and wchar.h are factored out to their own header. * libio/bits/types/FILE.h, libio/bits/types/__FILE.h * wcsmbs/bits/types/mbstate_t.h, wcsmbs/bits/types/__mbstate_t.h * wcsmbs/bits/types/wint_t.h: New single-type definition files. * wctype/bits/wctype-wchar.h: New file holding declarations shared between wctype.h and wchar.h. * libio/Makefile, wcsmbs/Makefile, wctype/Makefile: Install them. * include/bits/types/FILE.h, include/bits/types/__FILE.h * include/bits/types/mbstate_t.h, include/bits/types/__mbstate_t.h * include/bits/types/wint_t.h, include/bits/wcsmbs-wchar.h: New wrappers. * include/stdio.h, include/wchar.h, include/wctype.h: No need to handle __need macros. * grp/grp.h, gshadow/gshadow.h, hurd/hurd.h, iconv/gconv.h * libio/stdio.h, mach/mach.h, misc/mntent.h, pwd/pwd.h * shadow/shadow.h, stdio-common/printf.h, wcsmbs/uchar.h * wcsmbs/wchar.h, wctype/wctype.h * sysdeps/generic/_G_config.h, sysdeps/unix/sysv/linux/_G_config.h Use the new files instead of __need macros.
2017-06-07Fix include paths in include/bits/types/*.h.</