From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#52440: 28.0.50; [PATCH] Quis custodiet ipsos custodes (sqlite3) Date: Sun, 12 Dec 2021 09:52:20 +0200 Message-ID: <83ee6ip8ej.fsf@gnu.org> References: <87wnkazv3i.fsf@dick> <87r1aie4hr.fsf@gnus.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35442"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 52440@debbugs.gnu.org, dick.r.chiang@gmail.com To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Dec 12 08:53:15 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mwJfV-000924-Ke for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 12 Dec 2021 08:53:13 +0100 Original-Received: from localhost ([::1]:44152 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mwJfU-00068N-Fm for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 12 Dec 2021 02:53:12 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:41506) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mwJfK-000680-OO for bug-gnu-emacs@gnu.org; Sun, 12 Dec 2021 02:53:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39054) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mwJfK-0000Np-GV for bug-gnu-emacs@gnu.org; Sun, 12 Dec 2021 02:53:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mwJfK-0003j8-FR for bug-gnu-emacs@gnu.org; Sun, 12 Dec 2021 02:53:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 12 Dec 2021 07:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 52440 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo patch Original-Received: via spool by 52440-submit@debbugs.gnu.org id=B52440.163929555514293 (code B ref 52440); Sun, 12 Dec 2021 07:53:02 +0000 Original-Received: (at 52440) by debbugs.gnu.org; 12 Dec 2021 07:52:35 +0000 Original-Received: from localhost ([127.0.0.1]:50600 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mwJet-0003iT-IU for submit@debbugs.gnu.org; Sun, 12 Dec 2021 02:52:35 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:40722) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mwJes-0003iG-Kd for 52440@debbugs.gnu.org; Sun, 12 Dec 2021 02:52:34 -0500 Original-Received: from [2001:470:142:3::e] (port=53500 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mwJen-00005P-BV; Sun, 12 Dec 2021 02:52:29 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=yaoBis1lk09MnGbvvnbms6fRyCUUuoqCTulm/V8LskU=; b=TAqUaCk81WwW w295S0mwIN+fL3DK5rsCph8Y7e+j8MyFTs+s1TF3dSkbXUz4ofhmUhmqGT1t0LFGIgwSssWxuFfMm yAsM8tBH6aUh4KFdkyz9NhZvPw7ZYLYuEd+maVcg3kLHPYG4vXld/j8QConrrhMPA8J0ZDzIr9SL6 8qa5Dkkm7DQkjEfpUO+eted4xUYzLZs6kWWakWkc9NDZOdQpf/7Re8DT4Tsl3lUwBH56VFn/CgZ0y JLvPAuEvTe+sx8rBdn0J0Qij4HPvGW8Wewre0VKaGrwkLcAL7jg6lNcHFtujuUYPSI5aWayJsUQQ6 fg7QrIKjl/fezCu2i0QKNA==; Original-Received: from [87.69.77.57] (port=2612 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mwJen-0007Mf-62; Sun, 12 Dec 2021 02:52:29 -0500 In-Reply-To: <87r1aie4hr.fsf@gnus.org> (message from Lars Ingebrigtsen on Sun, 12 Dec 2021 07:12:16 +0100) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:222186 Archived-At: > From: Lars Ingebrigtsen > Cc: 52440@debbugs.gnu.org, Eli Zaretskii > 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.