bug#31676: 27.0.50; More helpful error message for unescaped character literals

[Philipp Stephani]

Am Fr., 19. Apr. 2019 um 17:53 Uhr schrieb Philipp Stephani
<p.stephani2@gmail.com>:
>
> Am Fr., 19. Apr. 2019 um 13:43 Uhr schrieb Noam Postavsky 
> <npostavs@gmail.com>:
> >
> > Philipp Stephani <p.stephani2@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.

Thinking about this a bit more, I think the overhead of your approach
for most uninterned symbols (a static variable + staticpro) is small
enough to not warrant further complex DEF* macros, so I'll switch the
existing uses to that.