* C90 header compatibility @ 2023-01-30 7:58 Florian Weimer 2023-01-30 12:26 ` Siddhesh Poyarekar 0 siblings, 1 reply; 5+ messages in thread From: Florian Weimer @ 2023-01-30 7:58 UTC (permalink / raw) To: libc-alpha; +Cc: Siddhesh Poyarekar We regressed compatibility with C90 compilers because <sys/cdefs.h> unconditionally uses variadic macros, a C99 feature, in the definition of __glibc_fortify and __glibc_fortify_n. This also impacts certain C++ compilers that do not have a C99-compatible preprocessor. Should we fix this? I think so. Previously, we worked around this by enclosing variable-length lists in (…), but it doesn't look like it might work here. We probably need to move the macros into a separate file, and include that file only if fortification is active. Thanks, Florian ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: C90 header compatibility 2023-01-30 7:58 C90 header compatibility Florian Weimer @ 2023-01-30 12:26 ` Siddhesh Poyarekar 2023-01-30 12:43 ` Florian Weimer 0 siblings, 1 reply; 5+ messages in thread From: Siddhesh Poyarekar @ 2023-01-30 12:26 UTC (permalink / raw) To: Florian Weimer; +Cc: libc-alpha On Mon, Jan 30, 2023 at 2:58 AM Florian Weimer <fweimer@redhat.com> wrote: > > We regressed compatibility with C90 compilers because <sys/cdefs.h> > unconditionally uses variadic macros, a C99 feature, in the definition > of __glibc_fortify and __glibc_fortify_n. > > This also impacts certain C++ compilers that do not have a > C99-compatible preprocessor. > > Should we fix this? I think so. > > Previously, we worked around this by enclosing variable-length lists in > (…), but it doesn't look like it might work here. We probably need to > move the macros into a separate file, and include that file only if > fortification is active. Wouldn't conditionalizing the macro defs in-place with #if __FORTIFY_LEVEL > 0 sufficient? __FORTIFY_LEVEL can be non-zero only for gcc 4.1 or newer. That is, do these older compilers complain if there's code they cannot recognize in a #if 0 block? Sid ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: C90 header compatibility 2023-01-30 12:26 ` Siddhesh Poyarekar @ 2023-01-30 12:43 ` Florian Weimer 2023-01-30 13:32 ` [PATCH] cdefs: Limit definition of fortification macros Siddhesh Poyarekar 0 siblings, 1 reply; 5+ messages in thread From: Florian Weimer @ 2023-01-30 12:43 UTC (permalink / raw) To: Siddhesh Poyarekar; +Cc: libc-alpha * Siddhesh Poyarekar: > On Mon, Jan 30, 2023 at 2:58 AM Florian Weimer <fweimer@redhat.com> wrote: >> >> We regressed compatibility with C90 compilers because <sys/cdefs.h> >> unconditionally uses variadic macros, a C99 feature, in the definition >> of __glibc_fortify and __glibc_fortify_n. >> >> This also impacts certain C++ compilers that do not have a >> C99-compatible preprocessor. >> >> Should we fix this? I think so. >> >> Previously, we worked around this by enclosing variable-length lists in >> (…), but it doesn't look like it might work here. We probably need to >> move the macros into a separate file, and include that file only if >> fortification is active. > > Wouldn't conditionalizing the macro defs in-place with #if > __FORTIFY_LEVEL > 0 sufficient? __FORTIFY_LEVEL can be non-zero only > for gcc 4.1 or newer. That is, do these older compilers complain if > there's code they cannot recognize in a #if 0 block? “#if” should work, based on a few quick tests. Thanks, Florian ^ permalink raw reply [flat|nested] 5+ messages in thread
* [PATCH] cdefs: Limit definition of fortification macros 2023-01-30 12:43 ` Florian Weimer @ 2023-01-30 13:32 ` Siddhesh Poyarekar 2023-02-01 17:48 ` Florian Weimer 0 siblings, 1 reply; 5+ messages in thread From: Siddhesh Poyarekar @ 2023-01-30 13:32 UTC (permalink / raw) To: libc-alpha; +Cc: fweimer Define the __glibc_fortify and other macros only when __FORTIFY_LEVEL > 0. This has the effect of not defining these macros on older C90 compilers that do not have support for variable length argument lists. Also trim off the trailing backslashes from the definition of __glibc_fortify and __glibc_fortify_n macros. Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org> --- Only tested for sanity. Florian, can you please verify that this resolves the original problem? misc/sys/cdefs.h | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/misc/sys/cdefs.h b/misc/sys/cdefs.h index 66d6702123..c37a3ff637 100644 --- a/misc/sys/cdefs.h +++ b/misc/sys/cdefs.h @@ -152,6 +152,7 @@ # define __glibc_objsize(__o) __bos (__o) #endif +#if __USE_FORTIFY_LEVEL > 0 /* Compile time conditions to choose between the regular, _chk and _chk_warn variants. These conditions should get evaluated to constant and optimized away. */ @@ -187,7 +188,7 @@ ? __ ## f ## _alias (__VA_ARGS__) \ : (__glibc_unsafe_len (__l, __s, __osz) \ ? __ ## f ## _chk_warn (__VA_ARGS__, __osz) \ - : __ ## f ## _chk (__VA_ARGS__, __osz))) \ + : __ ## f ## _chk (__VA_ARGS__, __osz))) /* Fortify function f, where object size argument passed to f is the number of elements and not total size. */ @@ -197,7 +198,8 @@ ? __ ## f ## _alias (__VA_ARGS__) \ : (__glibc_unsafe_len (__l, __s, __osz) \ ? __ ## f ## _chk_warn (__VA_ARGS__, (__osz) / (__s)) \ - : __ ## f ## _chk (__VA_ARGS__, (__osz) / (__s)))) \ + : __ ## f ## _chk (__VA_ARGS__, (__osz) / (__s)))) +#endif #if __GNUC_PREREQ (4,3) # define __warnattr(msg) __attribute__((__warning__ (msg))) -- 2.38.1 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] cdefs: Limit definition of fortification macros 2023-01-30 13:32 ` [PATCH] cdefs: Limit definition of fortification macros Siddhesh Poyarekar @ 2023-02-01 17:48 ` Florian Weimer 0 siblings, 0 replies; 5+ messages in thread From: Florian Weimer @ 2023-02-01 17:48 UTC (permalink / raw) To: Siddhesh Poyarekar; +Cc: libc-alpha * Siddhesh Poyarekar: > Define the __glibc_fortify and other macros only when __FORTIFY_LEVEL > > 0. This has the effect of not defining these macros on older C90 > compilers that do not have support for variable length argument lists. > > Also trim off the trailing backslashes from the definition of > __glibc_fortify and __glibc_fortify_n macros. > > Signed-off-by: Siddhesh Poyarekar <siddhesh@sourceware.org> > --- > > Only tested for sanity. Florian, can you please verify that this > resolves the original problem? > > misc/sys/cdefs.h | 6 ++++-- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/misc/sys/cdefs.h b/misc/sys/cdefs.h > index 66d6702123..c37a3ff637 100644 > --- a/misc/sys/cdefs.h > +++ b/misc/sys/cdefs.h > @@ -152,6 +152,7 @@ > # define __glibc_objsize(__o) __bos (__o) > #endif > > +#if __USE_FORTIFY_LEVEL > 0 > /* Compile time conditions to choose between the regular, _chk and _chk_warn > variants. These conditions should get evaluated to constant and optimized > away. */ > @@ -187,7 +188,7 @@ > ? __ ## f ## _alias (__VA_ARGS__) \ > : (__glibc_unsafe_len (__l, __s, __osz) \ > ? __ ## f ## _chk_warn (__VA_ARGS__, __osz) \ > - : __ ## f ## _chk (__VA_ARGS__, __osz))) \ > + : __ ## f ## _chk (__VA_ARGS__, __osz))) > > /* Fortify function f, where object size argument passed to f is the number of > elements and not total size. */ > @@ -197,7 +198,8 @@ > ? __ ## f ## _alias (__VA_ARGS__) \ > : (__glibc_unsafe_len (__l, __s, __osz) \ > ? __ ## f ## _chk_warn (__VA_ARGS__, (__osz) / (__s)) \ > - : __ ## f ## _chk (__VA_ARGS__, (__osz) / (__s)))) \ > + : __ ## f ## _chk (__VA_ARGS__, (__osz) / (__s)))) > +#endif > > #if __GNUC_PREREQ (4,3) > # define __warnattr(msg) __attribute__((__warning__ (msg))) Seems reasonable, thanks. I believe it works with those old compilers. Reviewed-by: Florian Weimer <fweimer@redhat.com> Florian ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2023-02-01 17:48 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2023-01-30 7:58 C90 header compatibility Florian Weimer 2023-01-30 12:26 ` Siddhesh Poyarekar 2023-01-30 12:43 ` Florian Weimer 2023-01-30 13:32 ` [PATCH] cdefs: Limit definition of fortification macros Siddhesh Poyarekar 2023-02-01 17:48 ` Florian Weimer
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).