| Issue |
173639
|
| Summary |
Volatile Deprecation
|
| Labels |
new issue
|
| Assignees |
|
| Reporter |
d3x0r
|
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 <tmiguelf_at_[hidden]> 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...
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
