Re: svn commit: r1936828 - in apr/apr-util/branches/1.6.x: . crypto

On Sun, Aug 9, 2026 at 3:13 PM Rainer Jung <[email protected]> wrote:
>
> Hi Eric and all,
>
> Am 03.08.26 um 15:45 schrieb [email protected]:
> > Author: covener
> > Date: Mon Aug  3 13:45:25 2026
> > New Revision: 1936828
> >
> > Log:
> > Merge r1936827 from aprutil 1.7.x:
> >
> > hide __has_attribute on traditional xlc platforms
> >
> > The backport of 1917748 omitted this in apr.h on purpose,
> > but this is a new/narrow usage and not in a header
> > where it would taint anyones use of __has_attribute.
> >
> > Modified:
> >     apr/apr-util/branches/1.6.x/   (props changed)
> >     apr/apr-util/branches/1.6.x/crypto/   (props changed)
> >     apr/apr-util/branches/1.6.x/crypto/apr_passwd.c
> >
> > Modified: apr/apr-util/branches/1.6.x/crypto/apr_passwd.c
> > ==============================================================================
> > --- apr/apr-util/branches/1.6.x/crypto/apr_passwd.c   Mon Aug  3 13:44:19 2026        (r1936827)
> > +++ apr/apr-util/branches/1.6.x/crypto/apr_passwd.c   Mon Aug  3 13:45:25 2026        (r1936828)
> > @@ -64,6 +64,12 @@ static volatile const apr_uint32_t optbl
> >    * Paper:
> >    *   https://cr.yp.to/papers/cryptoint-20250424.pdf
> >    */
> > +#if (defined(__xlc__) && !defined(__GNUC__))
> > +#ifndef __has_attribute
> > +#define __has_attribute(__x)    0
> > +#endif
> > +#endif
> > +
> >   #if __has_attribute(always_inline)
> >   __attribute__((always_inline))
> >   #endif
> I also get compilation errors due to __has_attribute() when compiling
> with older gcc compilers. Due to
>
> https://gcc.gnu.org/onlinedocs/cpp/_005f_005fhas_005fattribute.html
>
> I would suggest a more general check like this:
>
> --- crypto/apr_passwd.c 2026-08-03 15:45:25.000000000 +0200
> +++ crypto/apr_passwd.c 2026-08-09 20:56:18.478871355 +0200
> ...
> -#if (defined(__xlc__) && !defined(__GNUC__))
>   #ifndef __has_attribute
>   #define __has_attribute(__x)    0
>   #endif
> -#endif
>   ...
>
>
> Would that be OK for your xlc environment as well?
>
> I would then also apply this to crypto/apr_crypto.c which contains
> another copy of test_nonzero_timingsafe() and thus also uses
> __has_attribute().

No issue for me expanding it, but even on xlc I read that
__attribute__((always_inline)) was supported just with no way to check
(outside of autoconf in advance)