Paul Eggert <[email protected]> writes: > On 8/7/26 19:36, Sam James wrote: >> __eloop_threshold isn't const and a comment >> acknowledges this. > > Actually, the comment says that __eloop_threshold is validly marked > 'const' even though it uses memory and calls a function, because its > return value is unaffected by the memory use and the function call. > > If the comment is incorrect it'd be interesting to know why.
I'd attempted to explain that already: the attribute doesn't promise that a function is idempotent or has 'call_once' semantics. It promises beyond that, that it can't read global meomry in a way that affects what it returns. In the case of Mesa, it was actually the return which mattered, but the same thing as true anyway per the GCC bug. 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. I gave some examples of two projects where this broke already and it may well break in future too. Both of those had a fat comment saying exactly the same thing as gnulib does for this. thanks, sam
signature.asc
Description: PGP signature
