6 ms·

> You're moving the goalposts. Nope, I am not moving the goalposts, as is perfectly clear to you already. You are well aware that I am completely correct and t

> You're moving the goalposts. Nope, I am not moving the goalposts, as is perfectly clear to you already. You are well aware that I am completely correct and that you are wrong. > Again, the fact that Rust can and will break backwards compatibility is not in dispute. It's specifically the claim that it's done "on a whim" that was the seed of this subthread. And you and the other Rust proponent's directly talking around it, as you again are doing here, only worsens the situation. > No need for a thought experiment. Straight from the GCC docs [0]: Technically correct, but outside of extensions that has to be enabled, more or less none of that breaks any backwards compatibility. A program written in pure C or C++ ought to behave exactly the same and compile exactly the same as in those default dialects. The default dialects amount to more or less just a strict superset that behaves the same, like adding support for C++ "//" comments, or backporting newer C standard changes to previous versions. The only extensions that change behavior significantly and are not only strict supersets with same behavior, require flags to be enabled. Thus, yet again, radically different from what the rustc developers did just last year. Overall, your posts and the posts of your fellow Rust proponents in this submission both worsen the situation for Rust and for software overall regarding compatibility, security and safety, as the bug of the submission indicates. Imagine being so brazen and doubling down on a path that arguably lead to a very public bug. I do not believe any responsible software company would want you anywhere near its code if it cared about safety and security.

aw1621107 11mo ago
> Nope, I am not moving the goalposts, as is perfectly clear to you already. You are well aware that I am completely correct and that you are wrong. Turns out you have more than once. I wish I didn't have to spell this out for you, but here goes one last attempt... The original part of awesome_dude's comment that started this subthread: > Rust still has a very "Ready to make breaking changes on a whim" reputation Note the existence and wording of the qualifier here. The claim here is not "Ready to make breaking changes", but "Ready to make breaking changes on a whim". The relevant response from umanwizard: > What breaking changes has Rust made "on a whim"? Again, note the existence and wording of the qualifier. The question here is not "What breaking changes has Rust made", but "What breaking changes has Rust made 'on a whim' Your first response: > I don't know about "on a whim", but this isn't far off in regards to breaking compatibility. This is the first goalpost move. You're not claiming to have an example of a breaking change "on a whim" (in fact, you explicitly distance yourself from such a claim), but instead you say you have an example of a breaking change that "isn't far off" of being "on a whim". Note that this is not the same unadorned "on a whim" qualifier, as it uses the (slightly) weakening and more vague "isn't far off". How far off and in what way is it not far off? You fail to elaborate on both counts. Your next response: > Your post strongly reinforces Rust's reputation as a language whose language designers are willing to break compatibility on a whim. A second goalpost move. You're not using the "isn't far off" qualifier any more, and are instead using the unadorned "on a whim". Again, you fail to elaborate further on this. And finally: > closer to "on a whim" than many like A third goalpost move, with "on a whim" having grown two qualifiers, neither of which have previously appeared in this subthread! Now it's neither "on a whim" nor "isn't far off" "on a whim", but it's now "closer to" "on a whim" "than many like". How close is "closer to"? Who falls under "many"? How do these describe the example you provide? Who knows! > And you and the other Rust proponent's directly talking around it, as you again are doing here, only worsens the situation. It's not clear to me why it's so hard to understand what this subthread was originally about, nor why you seem so insistent on refusing to actually discuss the original topic. > Technically correct, but outside of extensions that has to be enabled, more or less none of that breaks any backwards compatibility. This is moving the goalposts yet again. We go from what is in effect "C/C++ compilers would never break backwards compatibility by adding language extensions!" to "You're correct in that they have done it, but it's mostly not a problem". > The default dialects amount to more or less just a strict superset that behaves the same, like adding support for C++ "//" comments, or backporting newer C standard changes to previous versions. The only extensions that change behavior significantly and are not only strict supersets with same behavior, require flags to be enabled. Not only does this claim contradict the snippets I quoted earlier, it also contradicts this other snippet from the docs (emphasis added) [0]: > On the other hand, when a GNU dialect of a standard is specified, all features supported by the compiler are enabled, even when those features change the meaning of the base standard. And given that GCC defaults to said GNU dialects, that means that non-strict-superset features are enabled by default. [0]: https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html
- 1718627440 11mo ago
  > This is moving the goalposts yet again. We go from what is in effect "C/C++ compilers would never break backwards compatibility by adding language extensions!" to "You're correct in that they have done it, but it's mostly not a problem". Do you consider old program now compiles, that previously didn't to be a serious break in backward compatibility? I think they do not, and so do I.
  - aw1621107 11mo ago
    If I'm understanding you correctly, I don't, but I interpreted the GCC docs to indicate the opposite. To me, the docs indicate that it's possible (albeit unlikely) for a program that compiles under -std=c* to fail to compile under -std=gnu* due to one of those extensions that "conflict with the [C/C++] standard" and/or "change the meaning of the base standard".
    - rustdebacletime 11mo ago
      But that would imply a change of flags. And the extensions by the default gnu* look very mild, more or less strict supersets.
    - 1718627440 11mo ago
      > To me, the docs indicate that it's possible (albeit unlikely) for a program that compiles under -std=c* to fail to compile under -std=gnu* due to one of those extensions that "conflict with the [C/C++] standard" and/or "change the meaning of the base standard". That's correct. There are not much of those, but they do exist. These generally mean that the GNU dialect gave syntax a meaning, back when it was still forbidden in standard C. Then standard C adopted that feature due to it being implemented in a compiler (that's how language evolution should work), but gave it slightly different semantics. Now GCC has the choice between breaking old existing programs, or not exposing standard semantics by default. They solve that by letting the user choose the language version. An example of that are arrays of size 0 at the end of a structure. This used to be used for specifying arrays whose size can be arbitrary large, but became obsolete with the introduction of flexible array members in C99. Now if GCC would only implement standard C, then the correct semantics for any array with a declared size that is accessed with an index larger than that size, would be undefined behaviour, but since GCC gave that the semantics, that now flexible array members have, before flexible array members existed, it chooses to implement these semantics instead, unless you tell it, which C standard you want to use. Actually due to the use in popular codebases, such as the Linux kernel, this semantic is even assigned (based on a heuristic) with array sizes larger than zero. From https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html : > In the absence of the zero-length array extension, in ISO C90 the contents array in the example above would typically be declared to have a single element. Unlike a zero-length array which only contributes to the size of the enclosing structure for the purposes of alignment, a one-element array always occupies at least as much space as a single object of the type. Although using one-element arrays this way is discouraged, GCC handles accesses to trailing one-element array members analogously to zero-length arrays. (With GNU projects when you have questions, the best source are the official docs themself. They are stellar and are even completely available offline on your computer in the interactive documentation system Info.) The other extensions are in the sibling chapters, e.g. https://gcc.gnu.org/onlinedocs/gcc/Syntax-Extensions.html https://gcc.gnu.org/onlinedocs/gcc/Syntax-Extensions.html or https://gcc.gnu.org/onlinedocs/gcc/Semantic-Extensions.html https://gcc.gnu.org/onlinedocs/gcc/Semantic-Extensions.html . A one that I quite like is https://gcc.gnu.org/onlinedocs/gcc/Unnamed-Fields.html https://gcc.gnu.org/onlinedocs/gcc/Unnamed-Fields.html .

aw1621107 11mo ago

> Nope, I am not moving the goalposts, as is perfectly clear to you already. You are well aware that I am completely correct and that you are wrong. Turns out you have more than once. I wish I didn't have to spell this out for you, but here goes one last attempt... The original part of awesome_dude's comment that started this subthread: > Rust still has a very "Ready to make breaking changes on a whim" reputation Note the existence and wording of the qualifier here. The claim here is not "Ready to make breaking changes", but "Ready to make breaking changes on a whim". The relevant response from umanwizard: > What breaking changes has Rust made "on a whim"? Again, note the existence and wording of the qualifier. The question here is not "What breaking changes has Rust made", but "What breaking changes has Rust made 'on a whim' Your first response: > I don't know about "on a whim", but this isn't far off in regards to breaking compatibility. This is the first goalpost move. You're not claiming to have an example of a breaking change "on a whim" (in fact, you explicitly distance yourself from such a claim), but instead you say you have an example of a breaking change that "isn't far off" of being "on a whim". Note that this is not the same unadorned "on a whim" qualifier, as it uses the (slightly) weakening and more vague "isn't far off". How far off and in what way is it not far off? You fail to elaborate on both counts. Your next response: > Your post strongly reinforces Rust's reputation as a language whose language designers are willing to break compatibility on a whim. A second goalpost move. You're not using the "isn't far off" qualifier any more, and are instead using the unadorned "on a whim". Again, you fail to elaborate further on this. And finally: > closer to "on a whim" than many like A third goalpost move, with "on a whim" having grown two qualifiers, neither of which have previously appeared in this subthread! Now it's neither "on a whim" nor "isn't far off" "on a whim", but it's now "closer to" "on a whim" "than many like". How close is "closer to"? Who falls under "many"? How do these describe the example you provide? Who knows! > And you and the other Rust proponent's directly talking around it, as you again are doing here, only worsens the situation. It's not clear to me why it's so hard to understand what this subthread was originally about, nor why you seem so insistent on refusing to actually discuss the original topic. > Technically correct, but outside of extensions that has to be enabled, more or less none of that breaks any backwards compatibility. This is moving the goalposts yet again. We go from what is in effect "C/C++ compilers would never break backwards compatibility by adding language extensions!" to "You're correct in that they have done it, but it's mostly not a problem". > The default dialects amount to more or less just a strict superset that behaves the same, like adding support for C++ "//" comments, or backporting newer C standard changes to previous versions. The only extensions that change behavior significantly and are not only strict supersets with same behavior, require flags to be enabled. Not only does this claim contradict the snippets I quoted earlier, it also contradicts this other snippet from the docs (emphasis added) [0]: > On the other hand, when a GNU dialect of a standard is specified, all features supported by the compiler are enabled, even when those features change the meaning of the base standard. And given that GCC defaults to said GNU dialects, that means that non-strict-superset features are enabled by default. [0]: https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html https://gcc.gnu.org/onlinedocs/gcc/C-Dialect-Options.html

1718627440 11mo ago
> This is moving the goalposts yet again. We go from what is in effect "C/C++ compilers would never break backwards compatibility by adding language extensions!" to "You're correct in that they have done it, but it's mostly not a problem". Do you consider old program now compiles, that previously didn't to be a serious break in backward compatibility? I think they do not, and so do I.
- aw1621107 11mo ago
  If I'm understanding you correctly, I don't, but I interpreted the GCC docs to indicate the opposite. To me, the docs indicate that it's possible (albeit unlikely) for a program that compiles under -std=c* to fail to compile under -std=gnu* due to one of those extensions that "conflict with the [C/C++] standard" and/or "change the meaning of the base standard".
  - rustdebacletime 11mo ago
    But that would imply a change of flags. And the extensions by the default gnu* look very mild, more or less strict supersets.
  - 1718627440 11mo ago
    > To me, the docs indicate that it's possible (albeit unlikely) for a program that compiles under -std=c* to fail to compile under -std=gnu* due to one of those extensions that "conflict with the [C/C++] standard" and/or "change the meaning of the base standard". That's correct. There are not much of those, but they do exist. These generally mean that the GNU dialect gave syntax a meaning, back when it was still forbidden in standard C. Then standard C adopted that feature due to it being implemented in a compiler (that's how language evolution should work), but gave it slightly different semantics. Now GCC has the choice between breaking old existing programs, or not exposing standard semantics by default. They solve that by letting the user choose the language version. An example of that are arrays of size 0 at the end of a structure. This used to be used for specifying arrays whose size can be arbitrary large, but became obsolete with the introduction of flexible array members in C99. Now if GCC would only implement standard C, then the correct semantics for any array with a declared size that is accessed with an index larger than that size, would be undefined behaviour, but since GCC gave that the semantics, that now flexible array members have, before flexible array members existed, it chooses to implement these semantics instead, unless you tell it, which C standard you want to use. Actually due to the use in popular codebases, such as the Linux kernel, this semantic is even assigned (based on a heuristic) with array sizes larger than zero. From https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html https://gcc.gnu.org/onlinedocs/gcc/Zero-Length.html : > In the absence of the zero-length array extension, in ISO C90 the contents array in the example above would typically be declared to have a single element. Unlike a zero-length array which only contributes to the size of the enclosing structure for the purposes of alignment, a one-element array always occupies at least as much space as a single object of the type. Although using one-element arrays this way is discouraged, GCC handles accesses to trailing one-element array members analogously to zero-length arrays. (With GNU projects when you have questions, the best source are the official docs themself. They are stellar and are even completely available offline on your computer in the interactive documentation system Info.) The other extensions are in the sibling chapters, e.g. https://gcc.gnu.org/onlinedocs/gcc/Syntax-Extensions.html https://gcc.gnu.org/onlinedocs/gcc/Syntax-Extensions.html or https://gcc.gnu.org/onlinedocs/gcc/Semantic-Extensions.html https://gcc.gnu.org/onlinedocs/gcc/Semantic-Extensions.html . A one that I quite like is https://gcc.gnu.org/onlinedocs/gcc/Unnamed-Fields.html https://gcc.gnu.org/onlinedocs/gcc/Unnamed-Fields.html .