GNU bug report logs - #31676
27.0.50; More helpful error message for unescaped character literals

Previous Next

Full log

View this message in rfc822 format

From: Philipp Stephani <p.stephani2 <at> gmail.com>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, Lars Ingebrigtsen <larsi <at> gnus.org>, 31676 <at> debbugs.gnu.org
Subject: bug#31676: 27.0.50; More helpful error message for unescaped character literals
Date: Fri, 19 Apr 2019 17:53:50 +0200

Am Fr., 19. Apr. 2019 um 13:43 Uhr schrieb Noam Postavsky <npostavs <at> gmail.com>:
>
> Philipp Stephani <p.stephani2 <at> gmail.com> writes:
>
> >> > The function uses an uninterned variable, so it has to be in C. I think that's slightly better than interning the
> >> > variable and having some Lisp function access it (the latter would have one additional internal symbol).
>
> >> Why does it need an uninterned variable?
> >
> > It doesn't need to be uninterned, but it's cleaner that way because no
> > other code can access the variable.
> >
> >>  And if it does, why cannot
> >> it create a symbol that is not in obarray?
> >
> > That's what the patch does.
>
> The patch uninterns a symbol after it's interned in the obarray.  I
> think the question is, why put the symbol in the obarray in the first
> place?  Just a C static variable would do (although this would require
> an additional (trivial) C function, to use with record_unwind_protect
> instead of specbind).  See for example Vloads_in_progress.
>

Ah, I see. There's no specific reason for this specific
implementation, it's just the simplest one.
Since we have a few cases where we need uninterned variables/functions
(I see 6 existing calls to unintern in the C source code), how about
extending DEFVAR/defsubr to allow uninterned symbols? That would make
the implementation of these cases more obvious.

Previous Next

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