3 ms·

From the standard [6.5.4][String literals]: "If the program attempts to modify such an array, the behavior is undefined." Hence there is no requirement to seg

by sfk 16y ago

From the standard [6.5.4][String literals]: "If the program attempts to modify such an array, the behavior is undefined." Hence there is no requirement to segfault.

tptacek 16y ago
This is just message board geekery. Nobody could reasonably argue that the requirement is to "segfault"; C runs in many places where there's no such concept. Jacques point was that C string literals are immutable. Stop bickering with him; he's right.
- sfk 16y ago
  I appreciate your confidence, but you are wrong: OpenSolaris/suncc, Jacques' program: $ cat immutable.c #include <stdio.h> int main() { char * s = "abc"; *s = 'c'; printf("%s\n", s); return 0; } $ cc -o immutable immutable.c $ ./immutable cbc EDIT: I can't reply to you, so I have to take this route. I also think that this behavior is not desirable. However, I do not see the passage in the the standard that forbids writable strings. On the contrary, in Annex J writable string literals are explicitly allowed as an extension, and I don't see any indication that the presence of writable strings make an implementation non-conforming. Perhaps you could point to the passage in the standard that requires string literals to be immutable (your words, not mine) or that requires a compiler to issue a warning if a string literal is modified. If you still wonder why I'm arguing this: It is not for the sake of nitpicking, but to support kabdib's post.
  - tptacek 16y ago
    That Sun's CC does something goofy here has nothing to do with the argument. Code written to depend on that weird behavior is unreasonable. Why are you arguing this point? I don't get what you think you're proving here. There are plenty of platforms that C runs on that are incapable of making anything immutable, including program text itself. That doesn't make C strings less immutable. Why isn't your compiler yelling at you for doing that? I think it's broken!

by sfk 16y ago

From the standard [6.5.4][String literals]: "If the program attempts to modify such an array, the behavior is undefined." Hence there is no requirement to segfault.

tptacek 16y ago

This is just message board geekery. Nobody could reasonably argue that the requirement is to "segfault"; C runs in many places where there's no such concept. Jacques point was that C string literals are immutable. Stop bickering with him; he's right.

sfk 16y ago
I appreciate your confidence, but you are wrong: OpenSolaris/suncc, Jacques' program: $ cat immutable.c #include <stdio.h> int main() { char * s = "abc"; *s = 'c'; printf("%s\n", s); return 0; } $ cc -o immutable immutable.c $ ./immutable cbc EDIT: I can't reply to you, so I have to take this route. I also think that this behavior is not desirable. However, I do not see the passage in the the standard that forbids writable strings. On the contrary, in Annex J writable string literals are explicitly allowed as an extension, and I don't see any indication that the presence of writable strings make an implementation non-conforming. Perhaps you could point to the passage in the standard that requires string literals to be immutable (your words, not mine) or that requires a compiler to issue a warning if a string literal is modified. If you still wonder why I'm arguing this: It is not for the sake of nitpicking, but to support kabdib's post.
- tptacek 16y ago
  That Sun's CC does something goofy here has nothing to do with the argument. Code written to depend on that weird behavior is unreasonable. Why are you arguing this point? I don't get what you think you're proving here. There are plenty of platforms that C runs on that are incapable of making anything immutable, including program text itself. That doesn't make C strings less immutable. Why isn't your compiler yelling at you for doing that? I think it's broken!