Volatile Deprecation

This is in the C++ compiler, the C compiler doesn't seem to issue this.

https://developercommunity.visualstudio.com/t/Clang-cl-C-volatile-function-parameter/11018406

I started a discussion on this here.... which has many of the issues....
https://lists.isocpp.org/std-discussion/2024/11/2729.php

later I got a response that was encouraging
https://lists.isocpp.org/std-discussion/2024/11/2741.php

```
On Sun, Nov 24, 2024 at 10:27 PM Tiago Freire wrote:
> Well, I have good news for you.
>
> Volatile isn’t deprecated anymore, they went back on that decision.
>
Do you have a reference/link to that? I dug through github paper issues
and found this...(regarding original paper though?)
https://github.com/cplusplus/papers/issues/138#issuecomment-524453355
:"Adopted 2019-07
```

Though in parallel....

```
> Volatile isn’t deprecated anymore, they went back on that decision.

Only for selected operations. See

https://wg21.link/P2866 (somewhere in this long paper...)
```

But I find that I'm still getting a lot of deprecated `volatile` warnings.... I don't know how anyone fell into 'oh that seems like a good idea'.

In short, I have a few data types `PLIST`, `PLINKQUEUE`, `PDATASTACK` which are `volatile`, because where they are used, they are often accessed from different threads, so their content may change outside of the current execution unit, so always read this, don't count on 'oh I could read this once, and it won't change so it's a constant, and this while loop now goes forever'.

Volatile has nothing to do with atomics; other than often being used in the same area. I also see there's a deprecation of `volatile` `--` operator - why? Can I not just subtract one from a counter that other threads have read-always access to?

Since these types are often used, the `volatile` attribute became part of the typedef, so now, factory functions that return a `volatile` list can't return a `struct list volatile *volatile` ; even though the type it's going into is a `struct list volatile *volatile`. So now I have to have two different types, one that I use to declare the function's return, and the one to actually receive the value... but now, there's a chance of picking the non-`volatile` version, and not get the expected behavior, since any sort of code completion/intellisense would use the return type of the function; and I can't just overload functions by return type.

I'm surprised to somehow be unique in having an issue with this change...

No source file, test, compiler version, or reproducible case is named. Start by reviewing the linked WG21 P2866 discussion and the reported C++ volatile diagnostics, then establish which operations should still warn and how the typedef and function-return examples behave. Done should be a confirmed standard-aligned compiler behavior with a focused reproduction or a precise implementation target.

Written by the indexing model from the issue text.