bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#40671: [DOC] modify literal objects


From: Paul Eggert
Subject: bug#40671: [DOC] modify literal objects
Date: Sun, 26 Apr 2020 16:13:53 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0

On 4/26/20 2:23 PM, Dmitry Gutov wrote:

> This just illustrates a weakness of type system in C/C++. The same way you 
> could
> pass a string into a function that expects an int.

Although it's a weakness, it's different from the char * vs int weakness. It's
well-defined in C that one can cast char * to char const * and back without
trouble. The same is not true for casting char * to int and back.

> is it undefined?

Yes, it's undefined. C11 section 6.7.3 paragraph 6 says, "If an attempt is made
to modify an object defined with a const-qualified type through use of an lvalue
with non-const-qualified type, the behavior is undefined."

> Do you have an example of a version of Emacs where this behavior was 
> different?

Emacs 26.

>> Unfortunately, the relevant code is hairy and any fixes certainly won't 
>> happen
>> before the Emacs 27 release. In the meantime it's better to warn users 
>> clearly
>> about the gotchas in this area, to help prevent some of the confusion
>> exemplified by Bug#40671.
> 
> Perhaps you meant some other bug report?

No, the original bug report that started this thread illustrates some of the
confusion in this area.

> In all of my experience, the term "constant" is usually applied to names
> (variables), or pointers. And it almost always means that you're not allowed 
> to
> change it. Or if you are, you can't do it by accident.

Unfortunately that experience does not apply to C and to other low-level
languages. Even Java once allowed programs to modify "constants" by using
reflection, though recent Java versions have fixed this.
> The previous term "literal objects", however, seems accurate enough

We could use any term we like, and if there's consensus for using the term
"literal object" instead of "constant" then we can redo the manual that way.
However, the problem can occur with strings that were never string literals in
any source-code Elisp program. And a Elisp string can begin its life as a
mutable string and then become a "constant" (or "literal object") later. So it's
not clear that the longer phrase is less confusing.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]