Re: incorrect use of 'pure' attribute

Paul Eggert <[email protected]> writes:

> This variable is 'long', not 'int'.
>
> Come to think of it, though, on GNU/Hurd aren't we in a bit of trouble here?
> One thread might be writing -1 while another is reading, and a torn read might
> cause the latter to see "65535" instead of -1.
>
> We needn't go to atomic accesses to fix this, I'd think, just to a volatile
> bool saying whether the long int is initialized, along with rejiggering the
> accesses to the long int.

I'm not sure you can rely on the volatile bool write sequencing with a
read of a long.

I don't see the point of avoiding atomics here.  It is a cheap and
simple case of it: a single relaxed load and single relaxed store should
cover it just fine:

  static _Atomic (long int) sysconf_symloop_max_memo;
  long int sysconf_symloop_max = (atomic_load_explicit
				  (&sysconf_symloop_max_memo,
				   memory_order_relaxed));
  if (sysconf_symloop_max == 0)
    atomic_store_explicit (&sysconf_symloop_max_memo,
			   sysconf_symloop_max = __sysconf (_SC_SYMLOOP_MAX),
			   memory_order_relaxed);

... or such (untested, not even compiled).
-- 
Arsen Arsenović

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

iQECBAEWCgCqFiEE/uKz0RP8AKMWLWBhUsKUMB6ixJMFAmp4ajYbFIAAAAAABAAO
bWFudTIsMi41KzEuMTIsMiwyXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25z
Lm9wZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRUUyQjNEMTEzRkMwMEEzMTYyRDYw
NjE1MkMyOTQzMDFFQTJDNDkzEBxhcnNlbkBhYXJzZW4ubWUACgkQUsKUMB6ixJMf
cgEA+QX2LaUDQRi/wyA4bMls7iidSouWYk/OuJfdNs6GTmcBAOUv5HrgrQvieb5u
2IrAXcONJdtNmZYk7maoZCxIk7sI
=Jhej
-----END PGP SIGNATURE-----