GNU bug report logs - #40671
[DOC] modify literal objects

Previous Next

Full log

View this message in rfc822 format

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Dmitry Gutov <dgutov <at> yandex.ru>
Cc: Michael Heerdegen <michael_heerdegen <at> web.de>, Mattias Engdegård <mattiase <at> acm.org>, 40671 <at> debbugs.gnu.org, Richard Stallman <rms <at> gnu.org>, ke.vigouroux <at> laposte.net
Subject: bug#40671: [DOC] modify literal objects
Date: Sun, 26 Apr 2020 16:13:53 -0700

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.