Timeline for Benefit of non-volatile access to volatile objects being undefined?
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jan 30, 2016 at 1:32 | comment | added | Cort Ammon | @supercat If you believe you are better at spec writing than the entire C and C++ spec writing teams of experts, please write a competing language, or convince the experts to change the spec. Announcing what you wish the spec writers would have done in every place where someone explains what they actually did will not create your dream language for you. If you believe you can do better, go out and do it! At worst, you may learn why the spec writers chose to do things a certain way. | |
| Jan 30, 2016 at 0:47 | comment | added | supercat | The problem isn't with the language that people actually use--it's with the failure of the standard to acknowledge reality. If some particular platform has a weird hardware reason why a non-qualified access to a volatile variable should have some consequence beyond being unsequenced relative to other volatile accesses, I see no reason such a platform shouldn't be allowed to have a conforming C compiler if that quirk is documented, but there's a huge gap between that and saying that compilers can do whatever they want without having to document anything. | |
| Jan 30, 2016 at 0:30 | comment | added | Cort Ammon | @supercat I suppose I could put a disclaimer on every answer that I write which you comment on, that if you're willing to rely on compiler specific behaviors, you can get away with things which the spec does not always allow you to do. However, generally speaking, I assume that people who ask questions about the spec are actually interested in answers about the spec, rather than what one might wish the spec had been, had they been in charge. After all, we are all free to write our own language to respond to C's apparent deficiencies. If its better than C, it may even take off. | |
| Jan 30, 2016 at 0:18 | comment | added | supercat | Unfortunately, the authors of the Standard are often extremely loath to say what compilers "should" do, with the consequence that even in cases where programmers and compiler writers would historically have agreed that certain behaviors should be defined when practical, and where the vast majority compilers for non-weird platforms have historically defined them absolutely consistently, some modern compiler writers feel no obligation to abide by such behaviors. | |
| Jan 30, 2016 at 0:15 | comment | added | Cort Ammon | @supercat Yes, when the specification does not impose any requirements on something, compiler writers can do what they want.... | |
| Jan 29, 2016 at 23:56 | comment | added | supercat | Some compiler writers don't need a particular "reason" to take advantage of Undefined Behavior. If they can determine that the Standard imposes no requirements on the behavior of a certain code path, they'll assume it cannot occur, regardless of whether there would otherwise be any real difficulty executing the code on that path. | |
| Nov 24, 2015 at 9:20 | history | answered | Cort Ammon | CC BY-SA 3.0 |