C90 header compatibility

C90 header compatibility

[Florian Weimer]

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

Re: C90 header compatibility

[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?

Sid

Re: C90 header compatibility

[Florian Weimer]

* 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

[PATCH] cdefs: Limit definition of fortification macros

[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)))
-- 
2.38.1

Re: [PATCH] cdefs: Limit definition of fortification macros

[Florian Weimer]

* 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