C23 makes various standard library functions, that return a pointer into an input array, into macros that return a pointer to const when the relevant argument passed to the macro is a pointer to const. (The requirement is for macros, with the existing function types applying when macro expansion is suppressed. When a null pointer constant is passed, such as integer 0, that's the same as a pointer to non-const.) Implement this feature. This only applies to C, not C++, since such macros are not an appropriate way of doing this for C++ and all the affected functions other than bsearch have overloads to implement an equivalent feature for C++ anyway. Nothing is done to apply such a change to any non-C23 functions with the same property of returning a pointer into an input array. The feature is also disabled when _LIBC is defined, since there are various places in glibc that either redefine these identifiers as macros, or define the functions themselves, and would need changing to work in the presence of these macro definitions. A natural question is whether we should in fact change those places and not disable the macro definitions for _LIBC. If so, we'd need a solution for the places in glibc that define the macro *before* including the relevant header (in order in effect to disable the header declaration of the function by renaming that declaration). One testcase has #undef added to avoid conflicting with this feature and another has const added; -Wno-discarded-qualifiers is added for building zic (but could be removed once there's a new upstream tzcode release that's const-safe with this C23 change and glibc has updated to code from that new release). Probably other places in glibc proper would need const added if we remove the _LIBC conditionals. Another question would be whether some GCC extension should be added to support this feature better with macros that only expand each argument once (as well as reducing duplication of diagnostics for bad usages such as non-pointer and pointer-to-volatile-qualfied arguments). Tested for x86_64.
Reviewed-by: Collin Funk <collin.funk1@gmail.com>
According to the tcc (tiny C compiler) Changelog, tcc supports __attribute__ since 0.9.3. Looking at history of tcc at <https://repo.or.cz/tinycc.git>, __attribute__ support was added in commit 14658993425878be300aae2e879560698e0c6c4c on 2002-01-03, which also looks like the release of 0.9.3. While I'm unable to find release tags for tcc before 0.9.18 (2003-04-14), the next release (0.9.28) will include __attribute__((cleanup(func)) which I rely on. Reviewed-by: Collin Funk <collin.funk1@gmail.com>
This fixes build failures using GCC 7.5.0 against glibc headers, see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118194#c5. Followup to 013106ae677af9836614ace1a01d25b63fa555a7. Reported-by: vvinayag@arm.com
Since https://gcc.gnu.org/r11-959, the compiler emits -Wmaybe-uninitialized if a const pointer to an uninitialized buffer is passed. Tell the compiler we don't dereference the pointer to remove the false alarm. Link: https://gcc.gnu.org/PR118194 Signed-off-by: Xi Ruoyao <xry111@xry111.site> Reviewed-by: Sam James <sam@gentoo.org>
This supports common coding patterns. The GCC C front end before version 7 rejects the may_alias attribute on a struct definition if it was not present in a previous forward declaration, so this attribute can only be conditionally applied. This implements the spirit of the change in Austin Group issue 1641. Suggested-by: Marek Polacek <polacek@redhat.com> Suggested-by: Jakub Jelinek <jakub@redhat.com> Reviewed-by: Sam James <sam@gentoo.org> Reviewed-by: Carlos O'Donell <carlos@redhat.com>
It was raised on libc-help [1] that some Linux kernel interfaces expect the libc to define __USE_TIME_BITS64 to indicate the time_t size for the kABI. Different than defined by the initial y2038 design document [2], the __USE_TIME_BITS64 is only defined for ABIs that support more than one time_t size (by defining the _TIME_BITS for each module). The 64 bit time_t redirects are now enabled using a different internal define (__USE_TIME64_REDIRECTS). There is no expected change in semantic or code generation. Checked on x86_64-linux-gnu, i686-linux-gnu, aarch64-linux-gnu, and arm-linux-gnueabi [1] https://sourceware.org/pipermail/libc-help/2024-January/006557.html [2] https://sourceware.org/glibc/wiki/Y2038ProofnessDesign Reviewed-by: DJ Delorie <dj@redhat.com>
When passed a pointer to a zero-sized struct, the access attribute without the third argument misleads -Wstringop-overflow diagnostics to think that a function is writing 1 byte into the zero-sized structs. The attribute doesn't add that much value in this context, so drop it completely for _FORTIFY_SOURCE=3. Resolves: BZ #31383 Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
It improves open, open64, openat, and openat64. The compile and runtime checks have similar coverage as with GCC. Checked on aarch64, armhf, x86_64, and i686. Reviewed-by: Carlos O'Donell <carlos@redhat.com> Tested-by: Carlos O'Donell <carlos@redhat.com>