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

Previous Next

Full log

Message #207 received at 40671 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Paul Eggert <eggert <at> cs.ucla.edu>
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: Re: bug#40671: [DOC] modify literal objects
Date: Mon, 27 Apr 2020 00:23:44 +0300

On 26.04.2020 21:57, Paul Eggert wrote:
> On 4/26/20 7:03 AM, Dmitry Gutov wrote:
>> g++ string_const.c++
> 
> Ah, my example was C-only. Here is an example for both C and C++:
> 
> #include <string.h>
> int main (void) {
>    union { char const *cp; char *p; } u = { "a" };
>    return !strcpy (u.p, "b");
> }
> 
> This has undefined behavior, and might dump core or might not depending on the
> implementation. Neither gcc nor g++ issue any warnings in default compilation.

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.

> Undefined behavior is undesirable and it's not a good thing that Emacs Lisp also
> has areas that behave like this.

But is it undefined? I think it's well-defined and predictable, though 
it's harder to make sense of that we would like.

> Somebody should pry free time to look into
> fixing them, but that won't be trivial. It appears that portable dumping and
> other changes have broken some of Emacs's runtime checking in this area.

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

> 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? This is the one we're 
commenting on.

My concern here is the terms. I worry that someday someone will come 
report a problem, and we respond with "this syntax creates constant 
values, please take care not to modify them". Then that someone will go 
away with very low opinion of our mental faculties.

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.

The closest term that applies to values, I think, is "immutable". But 
those are definitely protected from modification.

For our situation, the term "constant reference" comes to mind, but I 
don't know exactly how to rephrase the manual best.

The previous term "literal objects", however, seems accurate enough, and 
if the "constant-ness" is going to live only in the manual anyway, 
perhaps we should just say "please don't modify literal objects [unless 
you really know what you're doing]".

Previous Next

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