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

[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.