bug#52440: 28.0.50; [PATCH] Quis custodiet ipsos custodes (sqlite3)

[Eli Zaretskii <eliz@gnu.org>]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: 52440@debbugs.gnu.org, Eli Zaretskii <eliz@gnu.org>
> Date: Sun, 12 Dec 2021 07:12:16 +0100
> 
> > --- a/src/lisp.h
> > +++ b/src/lisp.h
> > @@ -2571,17 +2571,6 @@ xmint_pointer (Lisp_Object a)
> >    return XUNTAG (a, Lisp_Vectorlike, struct Lisp_Misc_Ptr)->pointer;
> >  }
> >  
> > -struct Lisp_Sqlite
> > -{
> > -  union vectorlike_header header;
> > -  void *db;
> > -  void *stmt;
> > -  char *name;
> > -  void (*finalizer) (void *);
> > -  bool eof;
> > -  bool is_statement;
> > -} GCALIGNED_STRUCT;
> 
> I thought including this in lisp.h instead of adding a separate .h and
> #ifdeffing all over the place was the most readable, but I have no
> strong opinion on that.  Eli, what do you think?

I don't like including other headers in lisp.h if those headers define
stuff important for the Lisp interpreter.  We did that with thread.h,
and I have a lot of bad memories from that experiment.  The main
problem is recursive dependencies between lisp.h and the included
header (which bite you if you move the place of the inclusion).  The
need to recompile everything when the included header changes (because
lisp.h is included by every source file) is also a nuisance.

However, the proof of the pudding is in eating: we do something like
the above with comp.h, for example (but also have HAVE_NATIVE_COMP
conditionals in lisp.h all over the place), so eventually it depends
on how many hoops we have to jump through to make the separation
happen.  If it's feasible to keep sqlite.h to a bare minimum, like
comp.h did, but without leaving a lot of sqlite stuff in lisp.h,
perhaps it's worthwhile?

OTOH, sqlite has (or should have) a relatively small impact on lisp.h,
as it basically defines a single data type.  The amount of sqlite
stuff in lisp.h is quite small, for that reason.  So I tend to think a
separate header is overkill.