Verifiably better, validated Enum for Python

[Rhodri James]

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<bc at 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