From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Pip Cet Newsgroups: gmane.emacs.bugs Subject: bug#46988: 28.0.50; Documenting and verifying assumptions about C code not calling quit or GCing Date: Wed, 10 Mar 2021 19:09:29 +0000 Message-ID: References: <87a6ra7ti3.fsf@rfc20.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3362"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 46988@debbugs.gnu.org To: Matt Armstrong Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Mar 10 20:11:17 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 1lK4En-0000ip-EQ for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 10 Mar 2021 20:11:17 +0100 Original-Received: from localhost ([::1]:60382 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lK4Em-0006z4-DE for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 10 Mar 2021 14:11:16 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42712) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lK4EZ-0006xx-CL for bug-gnu-emacs@gnu.org; Wed, 10 Mar 2021 14:11:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:40317) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lK4EY-0006C7-Kg for bug-gnu-emacs@gnu.org; Wed, 10 Mar 2021 14:11:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1lK4EY-0005ZK-Fm for bug-gnu-emacs@gnu.org; Wed, 10 Mar 2021 14:11:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Pip Cet Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 10 Mar 2021 19:11:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 46988 X-GNU-PR-Package: emacs Original-Received: via spool by 46988-submit@debbugs.gnu.org id=B46988.161540341221347 (code B ref 46988); Wed, 10 Mar 2021 19:11:02 +0000 Original-Received: (at 46988) by debbugs.gnu.org; 10 Mar 2021 19:10:12 +0000 Original-Received: from localhost ([127.0.0.1]:51863 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lK4Dk-0005YF-3P for submit@debbugs.gnu.org; Wed, 10 Mar 2021 14:10:12 -0500 Original-Received: from mail-oi1-f171.google.com ([209.85.167.171]:34706) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lK4Di-0005Xx-PF for 46988@debbugs.gnu.org; Wed, 10 Mar 2021 14:10:11 -0500 Original-Received: by mail-oi1-f171.google.com with SMTP id x78so20339377oix.1 for <46988@debbugs.gnu.org>; Wed, 10 Mar 2021 11:10:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rN/EEtdD/7Y+1gqW8NfGJCwkKvULmoPBWWajBeMkznU=; b=rwKY8hsKBoV4P2NXHKBHMTq9uMmgoU1bsM986m9/azt9OJFsaFS+JPNiQM/CmiF7f6 4T37yIpbG4BnTTXz3bOnSudirLpVepn8dvHVy12RfbIewBr7jcwPJJd0tXh6ezcILJRG rJmGW51KbY+IGZEULvpTSqIcVlbcT4eCDW03K6toVcKhv1XI5pi90qUiA6ahjYIPTG5G wcblKC0rnLmF+6o2v6ck/1/afR8wjeRDEbYStaPRr0kkGdFQSOrPQO5mngtPPQacOwgs XalVyThDUts5s4qyt8IltvsSB1KJV8MJipSB8PVy3OEfP06a6owlHZ8CkfgmM90CjTYj gJ+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rN/EEtdD/7Y+1gqW8NfGJCwkKvULmoPBWWajBeMkznU=; b=HhvaomvAZgECdgimbIk0vEK7fyri5Cb0MiRuZiNPsRPqM2XrVIJ4742N9erbWSpFWB p/T0o4TFI3qyGNMrei6Vr9uP7YhbOl+lJF+rHhNpgj8ZiV3BCq29CmmwTEr3j74I3be6 EqvvmoGQ3NCMinIZyzZmJkW/v/MSYqGZwGb97lYTz+4Lvk+4erO3GHmqq8s7jdWGIj+c gIvZyJII4rf2nBMSzYGyP/eQtJ2bMLIrGDSDVdTTjsZgtoEc0UQb++IHeGFFP5Z4so7y Yejr0wIsaXQPcIviq3LF6dNBEzL3OVBzEIhuIiPqb56N4exPQ8yyCupTUis2jgEvjXut +TiA== X-Gm-Message-State: AOAM533OwAb023VFNrc5mn3RxdbO5fY6JOfp094HyTHpZViriovCO80s yDjQ6tbdLBJ9Cf5S++6L7mtqXa/S3kFQJqzykCYl1fSjGxI= X-Google-Smtp-Source: ABdhPJxKqe0QCfaKS2MhpxOAmBs3ejTeqUBt71yvG517jyQNMs1WznK3jDVVSkyV7ML2QpP8QnlUi3CXfMd6fs3Kqhg= X-Received: by 2002:a54:4196:: with SMTP id 22mr3396795oiy.30.1615403405074; Wed, 10 Mar 2021 11:10:05 -0800 (PST) In-Reply-To: <87a6ra7ti3.fsf@rfc20.org> 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:202029 Archived-At: On Wed, Mar 10, 2021 at 6:28 PM Matt Armstrong wrote: > Pip Cet writes: > > Hey Pip, just minor comments from me. Thanks (I'm responding to my email in a LIFO fashion after receiving a new computer)! > (I assume you already plan to put the use of the cleanup attribute > behind conditional macros for portability) Yes, absolutely. > Why a linked list/stack implementation? How about a global count var > that is incremented, decremented, and asserted zero? Emacs' specpdl implementation is independent of, and probably predates, the widespread availability of C exceptions. In fact, as it is written today, C exceptions will not work in Emacs C code (neither will C++ exceptions), because Emacs uses setjmp / longjmp instead, and unwinds the stack by itself. Since I was too lazy to fix it to use compatible unwinding routines on supported platforms, I simply created a linked list on the stack, unwinding it in unwind_to_catch. > You wrote that this impl depends on the stack direction, but I can't > figure out why. If it is indeed the case, add a comment explaining > this? The unwind_to_catch code checks how far up the stack it has to go by comparing the stack pointer to the address of a local variable. You're absolutely right about the comment. > As a macro name, I think something like ASSERT_NO_GC_IN_SCOPE would be > clearer. Thanks! You're quite right, I chose that as a placeholder, and explicitly mentioning the scope is a really good idea. > Signaling that this is a "magical" scope based construct is useful > because this sort of thing is so unusual in C. The first thing I looked > for was an "END_SCOPE" macro and started scratching my head. > > I'd also use a clear that indicates a debug time check (ASSERT, > CRASH_IF, etc.) > > "Don't allow" states an invariant but does not clearly indicate a > consequence or other intent. It could imply something as polite as "GC > is disabled for this scope". > > For the C level stuff, maybe call it gc_forbidden_scope? I like your proposed names! > > + /* Do not wrap into do { } while (0). */ > > Move the comment next to the #define. Ideally, don't issue a command > for the next programmer but instead explain why the code is the way is. Yes, you're right. It's impolite at best. I'll try to avoid that in future. Thanks again Pip