On 26/05/17 12:46, Steve D'Aprano wrote:
On Thu, 25 May 2017 11:26 am, Chris Angelico wrote:
On Thu, May 25, 2017 at 9:34 AM, bartc<b...@freeuk.com> wrote:
That was quite likely with older Fortrans, where subroutines only used
pass-by-reference, but which didn't stop you passing references to
constants that the subroutine could then modify.
I doubt that's still the case. With C, however, I tried this today:
"abcdef"[3] = 'z';
puts("abcdef");
Some versions crashed; some printed 'abczef', and some 'abcdef'. (The
language says this is undefined, but it doesn't try too hard to stop you
doing it.)
And why should they try to stop you? The whole point of undefined
behaviour is that you shouldn't be doing this, so if you do, the
interpreter's allowed to do anything.
Does the C specification actually refer to this as undefined? I'm not a C
expert, but it seems to me that it is defined as an error.
The C99 standard (the one I happen to have beside me) says:
Section 6.4.5 (String Literals) Para 6
"It is unspecified whether these arrays are distinct provided their
elements have the appropriate values. If the program attempts to modify
such an array, the behavior is undefined."
The equivalent section in the rationale is a bit clearer if less
definitive: "String literals are not required to be modifiable. This
specification allows implementations to share copies of strings with
identical text, to place string literals in read-only memory, and to
perform certain optimisations." It also observes that some members of
the C89 committee insisted that string literals be modifiable.
In other words it's not an error but it won't always work, which is what
the standard generally means by "undefined". Anyone doing
cross-platform work should avoid it like the plague it will become to them.
--
Rhodri James *-* Kynesim Ltd
--
https://mail.python.org/mailman/listinfo/python-list
