Re: incorrect use of 'pure' attribute

Paul Eggert <[email protected]> writes:

> On 8/8/26 05:38, Sam James wrote:
>> The comment simply isn't right and it makes an assertion that doesn't
>> reflect reality. It is not validly const if it uses global memory to
>> affect what it returns, even if later calls are OK.
>
> But __eloop_threshold doesn't use global memory to affect what it returns. It
> always returns the same value, every time. So, even though __eloop_threshold
> uses static storage (I assume that's what you mean by "global memory"), its use
> of that static storage doesn't affect what it returns.
>
> In this sense I guess __eloop_threshold differs from a common C++ idiom, in
> which even though the function always returns the same value, that value is
> affected by what's already in memory. __eloop_threshold does not have that
> property.
>
> If my understanding is incorrect I'd appreciate a clarification, e.g., an
> example of an optimization that GCC might apply that would be invalid for
> __eloop_threshold.

I'm not certain that [[gnu::const]] is correct (FWIW, I can't think of
how it'd go wrong, but anyway), but I am certain this is a race
condition in linkat etc due to this condition.  ;)

Those should be atomic accesses.
-- 
Arsen Arsenović

-----BEGIN PGP SIGNATURE-----

iKoEARYKAFIWIQT+4rPRE/wAoxYtYGFSwpQwHqLEkwUCanelwRsUgAAAAAAEAA5t
YW51MiwyLjUrMS4xMiwyLDIYHGFhcnNlbm92aWNAYmF5bGlicmUuY29tAAoJEFLC
lDAeosSTWnMA+gNoyLlYu527fvCgFVMRBWtIftfxNuCpdajERH7zJNg0AQCvw24j
rEkpVt3LX6MMbc176IH+xnj1dqKll1mpR+/QBw==
=JiN4
-----END PGP SIGNATURE-----