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.devel Subject: Re: master d582356: * src/fns.c (Frandom): Handle bignum `limit`s Date: Sun, 7 Mar 2021 13:27:01 +0000 Message-ID: References: <20210305170955.27732.27579@vcs0.savannah.gnu.org> <20210305170957.AF99920E1B@vcs0.savannah.gnu.org> <83sg58wu0v.fsf@gnu.org> <83k0qkwnwt.fsf@gnu.org> <838s70wdb5.fsf@gnu.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="17315"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Stefan Monnier , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Mar 07 14:29:17 2021 Return-path: Envelope-to: ged-emacs-devel@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 1lItTB-0004PK-KF for ged-emacs-devel@m.gmane-mx.org; Sun, 07 Mar 2021 14:29:17 +0100 Original-Received: from localhost ([::1]:40524 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lItTA-0001bw-Kf for ged-emacs-devel@m.gmane-mx.org; Sun, 07 Mar 2021 08:29:16 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52000) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lItRc-0001Bx-Ck for emacs-devel@gnu.org; Sun, 07 Mar 2021 08:27:40 -0500 Original-Received: from mail-ot1-x32f.google.com ([2607:f8b0:4864:20::32f]:46628) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lItRa-0003qx-N9; Sun, 07 Mar 2021 08:27:40 -0500 Original-Received: by mail-ot1-x32f.google.com with SMTP id 97so6548930otf.13; Sun, 07 Mar 2021 05:27:37 -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=+ZLASayfmndgkcch3BzofL0KHczGpDtLfWDnsERRXMg=; b=ajnHqAOvbXNzyR3TaNbD2NP2y5sUFa02aKnxq3JqQjgjaOFuycV/ehsN2hTggyGeRg 9AMU0U7UuDJrZWEcp1/6StHnSQD5l1VlLkcQA5gaYt1Sz0TvpXEIEvHMmUXIWJz5Iozq H1LugF8izLIxLJfX3e2vMKJZzKxr7gudjECilMYc2PQ6vSrgiHNU8vPF2DM6nrjEc1tz bjyvjbQxS5yAG1Kp9iUj2ZW5W3oIG/cIhI3MKewnN68BLIJbGdtJRovl1q4Dw/oJEJHY Qh5wNS+eyFSvd2plrXFJC+T+p0h2IjkR+tBWGx4knGjFkKhT/7IiE772V3TO/9x9AK/E RK5Q== 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=+ZLASayfmndgkcch3BzofL0KHczGpDtLfWDnsERRXMg=; b=WLy4aYmoX9fbiAJEB72XrYYaUVKul3ZCFqPOfwJw7Xy6QB5li08dsr+QWFoE3No36g GP3dz9IvNgbjZ1OfXM+ZIT8hHhC8Tav7eAtr5da7yvbANy4uHTD5leOkHRVG56PfH14h +IRxUg2mp1AA7znr3IMutb6g12tCTAzUTAyiXuSeu3Az3z95PGXsbguY6dH1Bod7H7sK AXPs5aPLPnPRQxQUpC1lQyZe53ch9gpOjXr4aSNwATyBkJzYR8n2nSR+WqWtaa+hzqlg PabzwldLXKUFZ/E6xCznuoezHGa9W8nTG9x7tU4V1BVuPlw6s2bXtDuZOGx/XNvCIklJ hLZw== X-Gm-Message-State: AOAM5315dG1gasexb/I81Vke5ntcZer6/z08gdRroLd8ECQqJmqvzwGc Aw76YvSbhC0RUxtPltfGNhw/6ZBPbory15AII0oa3wkZpeo= X-Google-Smtp-Source: ABdhPJwwzZ8HIPVFxGo+p8dZ7J9NSTKfAzYLdNfs0XZ9ZGKP7RiswEYlRXlf7cFr7bfP3ncp1r1Kk5zq5PPFiSOFSvI= X-Received: by 2002:a05:6830:1e51:: with SMTP id e17mr15785770otj.292.1615123657260; Sun, 07 Mar 2021 05:27:37 -0800 (PST) In-Reply-To: <838s70wdb5.fsf@gnu.org> Received-SPF: pass client-ip=2607:f8b0:4864:20::32f; envelope-from=pipcet@gmail.com; helo=mail-ot1-x32f.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:266124 Archived-At: On Sat, Mar 6, 2021 at 2:46 PM Eli Zaretskii wrote: > > From: Pip Cet > > Date: Sat, 6 Mar 2021 13:22:10 +0000 > > Cc: Stefan Monnier , emacs-devel@gnu.org > > > > > > So I'm not sure whether code_conversion_save is allowed to call Lisp. > > > > > I'd rather it didn't, for more than one reason. But we can side-step > > > this by making Fgenerate_new_buffer_name use random-fixnum, which is > > > still a pure-C implementation. > > > > Here's a patch which makes it use get_random() directly. > > Thanks, maybe add a comment explaining the need for the do-while loop > in generate-new-buffer-name. I received some very intelligent suggestions on how to improve the code, will follow up with a better patch (unless the anonymous benefactor beats me to it, of course :-) ). > > Actually, I think it would be best to have these restrictions > > represented in the code. I see two ways of doing that: > > > > 1. Have FUNCTION_MAY_GC etc. translate into a GCC attribute in debug > > builds so we can statically check that a function that says it never > > calls GC doesn't call a function that says it may call GC. > > 2. Have a statement at the beginning of non-GCing functions which sets > > a flag that is then checked by garbage-collecting functions, so that > > we may dynamically check this. > > > > (1) seems easy to implement, but has a high rate of false negatives as "Seems". If you have a computer fast enough and enough RAM to actually compile emacs with -flto -fanalyzer -fdump-analyzer-json. I don't. > > many functions are safe to call from non-GCing functions as long as > > the arguments are correct. > > (2) is difficult to implement, and would only trigger at runtime. > > > > So I say we should do (1) in preference to (2), but maybe we should do both. > > I don't think I understand how will we know which function says it > never calls GC. By tagging it in the source code? > And the FUNCTION_MAY_GC attribute, even if applied to > the lowest-level functions that actually call maybe_gc, would be a > maintenance headache because we do change this from time to time. So > we'd need something that checks the attribute's accuracy at compile > time, otherwise the attribute will bitrot. Indeed. We should walk the call graph and determine which basic blocks end up (potentially) calling GC, which is what I set out to do with -fanalyzer but can't continue working on because it's too slow for Emacs... > For the same reasons, I don't see how (2) can be done in practice. Sorry, I don't understand. We'd have void f (void) { DONT_CALL_GC (); g(); } void g (void) { maybe_gc (); } and that would throw a runtime error because maybe_gc checks the flag set by DONT_CALL_GC. I don't think that would be too hard to maintain; would it? (It would, alas, throw the error only at runtime (or -fanalyzer time, potentially), and implementing it wouldn't be entirely trivial because of stack unwinds, but doable). What I'd like to know is whether something like this is worth pursuing at all, and that mostly depends on whether people are willing to build with --enable-checking=nogc once in a while and fix any assertion errors that pop up. Pip