From unknown Tue Jun 17 01:43:53 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#75521 <75521@debbugs.gnu.org> To: bug#75521 <75521@debbugs.gnu.org> Subject: Status: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX Reply-To: bug#75521 <75521@debbugs.gnu.org> Date: Tue, 17 Jun 2025 08:43:53 +0000 retitle 75521 scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX reassign 75521 emacs submitter 75521 Stefan Kangas severity 75521 wishlist thanks From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 12 12:55:54 2025 Received: (at submit) by debbugs.gnu.org; 12 Jan 2025 17:55:54 +0000 Received: from localhost ([127.0.0.1]:48994 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tX2Bl-0002Hh-Q0 for submit@debbugs.gnu.org; Sun, 12 Jan 2025 12:55:54 -0500 Received: from lists.gnu.org ([2001:470:142::17]:42662) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tX2Bj-0002HN-UU for submit@debbugs.gnu.org; Sun, 12 Jan 2025 12:55:52 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tX2Bd-00045n-MP for bug-gnu-emacs@gnu.org; Sun, 12 Jan 2025 12:55:45 -0500 Received: from mail-ej1-x634.google.com ([2a00:1450:4864:20::634]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tX2Bc-0002bO-3d for bug-gnu-emacs@gnu.org; Sun, 12 Jan 2025 12:55:45 -0500 Received: by mail-ej1-x634.google.com with SMTP id a640c23a62f3a-aaeec07b705so586977366b.2 for ; Sun, 12 Jan 2025 09:55:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736704542; x=1737309342; darn=gnu.org; h=to:subject:message-id:date:mime-version:from:from:to:cc:subject :date:message-id:reply-to; bh=frRoAkUg73rm4vxOb0qoICAy75a4BLr3sk82fudmVQ4=; b=WTqJFS45bcTYXtwPkO5aJA9+S+Fd90NFjsos87oPAxj1TF2dUDiplw1FVdJyzKkDq+ CYMOxh/+ft9WANvkZP+1g4JYf4L9U1h5ddmcTB5u7fjMm2yyBQiisezsSk4IifauL1VR kB5QdieWEfIxGqN1z34LnZju8YEOy4yYWFiLSwu+s9XDrZLyvLxgmEQwVkj26cyoQvFp 1Fs84jQul6LbSMr+wboVsJBBfiaTxh6Esktfyhrquxwa7r+iqWENUcDKefUq+3IaNt/r HfxvpBdVp4F900eDkQjquCtTe3SHaKDQQxN6neBZa6JNihEvDTE1Y+xjL9ew3/qPLuny WrIA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736704542; x=1737309342; h=to:subject:message-id:date:mime-version:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=frRoAkUg73rm4vxOb0qoICAy75a4BLr3sk82fudmVQ4=; b=TaSfml/AP8TvN+QWgQOZzRXH/yXT1Z5S2RX0+JKvSHCiiHlryVJM27U4l01UTHxAJf MS84VwafiJh/R2gyTH1+M0o9yx0PVr3/eknguS8TL0VWYXVKzXLpXbKIbKBE7RwZVLPA WxVUZakkjwdzMDdYUlCoigW8PobOVnerb+4aqB/ebpg43FmDpfbQvCNu3iiQ+JsOUVCJ mhu1BgMnxSwy2fFwsnV/4g+0M1u6m69sJSds3z0DcZPEfvqkJHJwBgmTCZwXNRpus06E vGWp46GCSVkwnDqDUXyZCy9sXQ4qZ2+EzPsJxV/EMr3TtA3oFvsDz1WaEA8IYrzeBxwB 530Q== X-Gm-Message-State: AOJu0YyYpTRHYF2lADoFsHfABisRuswvo/z+R6Xosib8NR/va9+I2EcI crKKIw2LMkRKxZ/pMXtdI4kzp9k8WYUBOgi0r+UmzdXL/oWUxMaUbzb7FO+UNSwN0+jKc8Z74fj D4WduyoRkFNR88spxxJJkRaVlhFpyfg== X-Gm-Gg: ASbGnctI7a3RXRpT61mVZBCyp1FytCgWdruLM2fqzz8BkMPJv0IgaXBy62grXWGDCUj CqeJOHFpQeg0bPhspOP7oB4Los1jSnvy2JPZzN002 X-Google-Smtp-Source: AGHT+IGJjDao+kC3/zf8buOpG5qFCsx+er9Ox3z1XOhf/YjjxbzQIntkCJ9SnVc3notd3Ic9h5b9SGOfWti1vtRTZ/g= X-Received: by 2002:a17:907:96a0:b0:aa6:87e8:1d08 with SMTP id a640c23a62f3a-ab2ab6bffc3mr1322207666b.8.1736704541804; Sun, 12 Jan 2025 09:55:41 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Sun, 12 Jan 2025 17:55:40 +0000 From: Stefan Kangas X-Debbugs-CC: gerd@gnu.org MIME-Version: 1.0 Date: Sun, 12 Jan 2025 17:55:40 +0000 X-Gm-Features: AbW1kvaH-m1xnRHRO9IyJivKuPWWBtP_DEUeCtzK8HKTLdeWUkdJMFV9j6ot_Io Message-ID: Subject: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX To: bug-gnu-emacs@gnu.org Content-Type: multipart/mixed; boundary="0000000000004b8c04062b86094f" Received-SPF: pass client-ip=2a00:1450:4864:20::634; envelope-from=stefankangas@gmail.com; helo=mail-ej1-x634.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-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) --0000000000004b8c04062b86094f Content-Type: text/plain; charset="UTF-8" Severity: wishlist Can we delete the unused macro DEFVAR_LISP_NOPROX? We can always resurrect it again if it turns out that we need it. --0000000000004b8c04062b86094f Content-Type: text/x-patch; charset="US-ASCII"; name="0001-Delete-unused-macro-DEFVAR_LISP_NOPROX.patch" Content-Disposition: attachment; filename="0001-Delete-unused-macro-DEFVAR_LISP_NOPROX.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: 51361e2aeaf29c31_0.1 RnJvbSA3MWY1YWMyMzU3NDY1OTY2NGEzZGQ2MmFlMTQxMmQwMTVlZGJjZDUzIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBTdGVmYW4gS2FuZ2FzIDxzdGVmYW5rYW5nYXNAZ21haWwuY29t PgpEYXRlOiBTdW4sIDEyIEphbiAyMDI1IDE4OjUzOjQxICswMTAwClN1YmplY3Q6IFtQQVRDSF0g RGVsZXRlIHVudXNlZCBtYWNybyBERUZWQVJfTElTUF9OT1BST1gKCiogc3JjL2xpc3AuaCAoREVG VkFSX0xJU1BfTk9QUk9YKTogRGVsZXRlIHVudXNlZCBtYWNyby4KLS0tCiBzcmMvbGlzcC5oIHwg MTIgLS0tLS0tLS0tLS0tCiAxIGZpbGUgY2hhbmdlZCwgMTIgZGVsZXRpb25zKC0pCgpkaWZmIC0t Z2l0IGEvc3JjL2xpc3AuaCBiL3NyYy9saXNwLmgKaW5kZXggMTAxY2JjNjQxN2YuLmNjNDU3Zjg0 ZjI4IDEwMDY0NAotLS0gYS9zcmMvbGlzcC5oCisrKyBiL3NyYy9saXNwLmgKQEAgLTM4MjEsMTIg KzM4MjEsNiBAQCAjZGVmaW5lIERFRlZBUl9MSVNQX05PUFJPKGxuYW1lLCB2bmFtZSwgZG9jKQkJ XAogICAgICAgPSB7TGlzcF9Gd2RfT2JqLCAudS5vYmp2YXIgPSAmZ2xvYmFscy5mXyMjdm5hbWV9 OwlcCiAgICAgZGVmdmFyX2xpc3AgKCZvX2Z3ZCwgbG5hbWUpOwkJCVwKICAgfSB3aGlsZSAoZmFs c2UpCi0jZGVmaW5lIERFRlZBUl9MSVNQX05PUFJPWChsbmFtZSwgdm5hbWUsIGRvYykJCVwKLSAg ZG8gewkJCQkJCQlcCi0gICAgc3RhdGljIHN0cnVjdCBMaXNwX0Z3ZCBjb25zdCBvX2Z3ZAkJCVwK LSAgICAgID0ge0xpc3BfRndkX09iaiwgLnUub2JqdmFyID0gJmdsb2JhbHMuZl8jI3ZuYW1lfTsJ XAotICAgIGRlZnZhcl9saXNwX25vcHJvICgmb19md2QsIGxuYW1lKTsJCQlcCi0gIH0gd2hpbGUg KGZhbHNlKQogI2Vsc2UKICNkZWZpbmUgREVGVkFSX0xJU1BfTk9QUk8obG5hbWUsIHZuYW1lLCBk b2MpCQlcCiAgIGRvIHsJCQkJCQkJXApAQCAtMzgzNCwxMiArMzgyOCw2IEBAICNkZWZpbmUgREVG VkFSX0xJU1BfTk9QUk8obG5hbWUsIHZuYW1lLCBkb2MpCQlcCiAgICAgICA9IHtMaXNwX0Z3ZF9P YmosIC51Lm9ianZhciA9ICZnbG9iYWxzLmZfIyN2bmFtZX07CVwKICAgICBkZWZ2YXJfbGlzcF9u b3BybyAoJm9fZndkLCBsbmFtZSk7CQkJXAogICB9IHdoaWxlIChmYWxzZSkKLSNkZWZpbmUgREVG VkFSX0xJU1BfTk9QUk9YKGxuYW1lLCB2bmFtZSwgZG9jKQkJXAotICBkbyB7CQkJCQkJCVwKLSAg ICBzdGF0aWMgc3RydWN0IExpc3BfRndkIGNvbnN0IG9fZndkCQkJXAotICAgICAgPSB7TGlzcF9G d2RfT2JqLCAudS5vYmp2YXIgPSAmZ2xvYmFscy5mXyMjdm5hbWV9OwlcCi0gICAgZGVmdmFyX2xp c3Bfbm9wcm8gKCZvX2Z3ZCwgbG5hbWUpOwkJCVwKLSAgfSB3aGlsZSAoZmFsc2UpCiAjZW5kaWYK ICNkZWZpbmUgREVGVkFSX0JPT0wobG5hbWUsIHZuYW1lLCBkb2MpCQkJCVwKICAgZG8gewkJCQkJ CQkJXAotLSAKMi40OC4wCgo= --0000000000004b8c04062b86094f-- From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 12 13:07:20 2025 Received: (at 75521) by debbugs.gnu.org; 12 Jan 2025 18:07:20 +0000 Received: from localhost ([127.0.0.1]:49010 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tX2Mp-0005vQ-Ms for submit@debbugs.gnu.org; Sun, 12 Jan 2025 13:07:19 -0500 Received: from mail-wr1-x430.google.com ([2a00:1450:4864:20::430]:45410) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tX2Mn-0005v4-Dz for 75521@debbugs.gnu.org; Sun, 12 Jan 2025 13:07:17 -0500 Received: by mail-wr1-x430.google.com with SMTP id ffacd0b85a97d-38637614567so1740669f8f.3 for <75521@debbugs.gnu.org>; Sun, 12 Jan 2025 10:07:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736705231; x=1737310031; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=dRDIoA5whF5S59FQ7bCPxvbWHzTYGIG2QVe9lOQmvlc=; b=gnisNR9+GcFGEEL6xR283x+ZHQCRMhgiY+oRTZFnFC+rV94MrSRz1E6LISHxh3Hsc/ kmu88LIQ/J8bEtbxoEmKGz1Xl0hnwLcy2dpMXfHmuiI8Fej/kcjuJ//DI+AFqACo1DlT bOY13LQIpZbNH7y8iZliOJJrytCYsuTruhHPib/3f/4qG1KkNmqXCAyEVMOUsOvnG9px Viz8SO+E82uxUleUDR7wSrTfc10mrynGSkORlqFZbzwEn1gqgccEangVSoEEuLXHfonU GTa/uI3yUrvN7EbEIGiTSRUxNuW1Q0J8y+OFn+J7D5kfgdxbsnUGqLr4HW7EelPLHpY2 eROA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736705231; x=1737310031; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=dRDIoA5whF5S59FQ7bCPxvbWHzTYGIG2QVe9lOQmvlc=; b=n2trG9hA80DBD+z8mbjDhJ39UG4mhYY6mj3h0ZWfND13W/AtyKwQv5hdqymZwg9oi1 TyA0HkMOfshpFJ4P7shKqEw0mwkigh44e+THzcH81Z+PnxaJ38c+2fJWxTFgnKzr/7m7 W1Zck1Gr+IOj9wYK2WYvfJYmKH7P4kZa5lD39fq7hwZNHzC2RlhCFjLdCQeVqCivXIfQ qcmXGZodBmI1HJry+LD6XcB0sQwcNtQbRHQrSvATD9tuOyq7MchrjFmyO8O6mnVzdimB I5obyq+yJFPB5gddfrD1usWtsuCM0JpawlJa3NK1XVfAi7gnv7DC3eS9imvL6FNhHDcL gx/w== X-Gm-Message-State: AOJu0YyrEGcF5x9Ul3y8pOJqotV1IXWzTjLbjddq2jL74Qz7yb8aoDw7 SZ43jYaEBqQ1sApfpAtgHYMrS01wFGVKco1diE+m+cBzHIOoSK9s X-Gm-Gg: ASbGnctJKjN1wOhEpKHIbEyd8j58nkl6waPZ8dbQ9SVn9nZ95n+qQGAoVMSyzHe0se8 Y8XTsmnOzpvgWl6jsZ17aQeWykCqO+uUvDSHU6vyWY4dROjL0dpoLl+hxWbbR97hIDETSaF08LY llAu//5WPF4TWqK4ydXvmpvF7vyf2+E8r+OeClgJJ8nJo3I3Ksgj3tqZEwHkrlWr5rIWzBsU3JU FKD3OX4Sa6a4mM66/TyqrWDm4tincs+ADXsQizk9BKuPuRbaQJ7IId0w+pKRMHIV5UNxiba1/Ps XZP6YqO8Gcsx+amePjkerEA4Ot7I2ofAgy8PeT6QI09RJZo0CCIMxICu+jlQs33F X-Google-Smtp-Source: AGHT+IFhZzlh5S3rn0JiAOqQtklIuEpago/d3aZ2YgYstO+IKMep59DJUC0yE0Hyb5Omq2E16gD50g== X-Received: by 2002:a5d:47a6:0:b0:385:d7a7:ad60 with SMTP id ffacd0b85a97d-38a872f6a32mr15354983f8f.3.1736705230967; Sun, 12 Jan 2025 10:07:10 -0800 (PST) Received: from pro2 (p200300e0b713dd00084feaa395e7e441.dip0.t-ipconnect.de. [2003:e0:b713:dd00:84f:eaa3:95e7:e441]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-436ed48f4b2sm105045575e9.24.2025.01.12.10.07.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 12 Jan 2025 10:07:10 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Stefan Kangas Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX In-Reply-To: (Stefan Kangas's message of "Sun, 12 Jan 2025 17:55:40 +0000") References: Date: Sun, 12 Jan 2025 19:07:09 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75521 Cc: 75521@debbugs.gnu.org, gerd@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stefan Kangas writes: > Severity: wishlist > > Can we delete the unused macro DEFVAR_LISP_NOPROX? +1 From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 12 13:19:11 2025 Received: (at 75521-done) by debbugs.gnu.org; 12 Jan 2025 18:19:11 +0000 Received: from localhost ([127.0.0.1]:49025 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tX2YJ-0006Y6-Et for submit@debbugs.gnu.org; Sun, 12 Jan 2025 13:19:11 -0500 Received: from mail-ed1-x535.google.com ([2a00:1450:4864:20::535]:56438) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tX2YH-0006Xr-Dx for 75521-done@debbugs.gnu.org; Sun, 12 Jan 2025 13:19:10 -0500 Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-5d3f65844deso5866237a12.0 for <75521-done@debbugs.gnu.org>; Sun, 12 Jan 2025 10:19:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736705943; x=1737310743; darn=debbugs.gnu.org; h=content-transfer-encoding:cc:to:subject:message-id:date :mime-version:references:in-reply-to:from:from:to:cc:subject:date :message-id:reply-to; bh=LRkFOJ0L/nGZVHIHVRD65eAEURDNfLtSjthMf30e8q8=; b=LRSkb6f0BESfmqOMamx9exgSrSvc1D4f3lDZIOZ2p7LSWD4U3VYXeSd2kE7KbyjCOU eS3k4sBPNaNUmFmNKoAY9NgHCxezV6gWc/yJiXmnPdJ4Cnwmaxh1Qy/B/IncCQwXYAA1 PoYy5srFNVhKCr9Fg3tlEluYO8xhL19mzN0WSsomv+H93kiaebdfbn02VcIkgWcM5jes VrPZ+sC4fN0NWQuizOfIajKysubGFQzSEM/06a8bEm2EIA0Y6AAehsFZOpP5eJx1013B Q4/pYJYSv5B28PLc2sNw5Gf4KVdIlCFNeKE/71gJKYsmGAcQukadRDBghkmYLbu/PfYZ Vq6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736705943; x=1737310743; h=content-transfer-encoding:cc:to:subject:message-id:date :mime-version:references:in-reply-to:from:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=LRkFOJ0L/nGZVHIHVRD65eAEURDNfLtSjthMf30e8q8=; b=rr8wZJLO4RD3ByTxK3yKcetZvLWYlm6O8qjuQTUmcHaOYMa6SKKOGiLpvfRHDBZ/+m VWaMdf39rr4D6Wu4nhS0/Ca0FGYObRkbnwJ2gSdQPHkzlJoOOOSuQFn5LCbhyNIUPNXo DFYeZMxtx+TpZxoP3B3zwJg4Hg2vnLCtMMyEZ9/AZw602aXCPW6BTAdyvW+ReV399dtV m7HD5Q2otwz0aoI4dbYMhd0cOQYiTOoeKmQLqfe4n8AhOnjYxM+DlFb62OcGGq77sHnT L9SxEfTWWNPJAcH7XgXQqq2a5iG5jj/lPst9XocukK32NNU2n2BvfQjiSDXwQn1tEROm W7Hw== X-Gm-Message-State: AOJu0YxTSbfLMpult6pSYWrVShC6bZ21yAqSsnLWeKaSvh/ZXny2H75o vrrYR9L1PUj1WZxeBx1sTPQ5Pw9KeewESWt1CKVwm7+nj8JHTnOAAfMnmT9+75MZJBVF7rPjgg+ gxaPoe3toZq4c/ijtHRQ0daSD6W8= X-Gm-Gg: ASbGncuVejtIcpMKaZVHDvQMIlDor4RwbFkT1U+LCuSO+gZQsm7iopRBy0TeDb4kr6V UYERlb4K/hPnDHuaLfp8RtFwzLxZfR2Jqzy08iV1i X-Google-Smtp-Source: AGHT+IHdk4pwa5LIchPulBbJ1ya8eIpAqLiIfv8aVslxJZmai1wNGi1putTfi05h6DQrT5p10AZBLCmpbjar4+kVrJA= X-Received: by 2002:a05:6402:360c:b0:5d0:e826:f0da with SMTP id 4fb4d7f45d1cf-5d972e1683fmr17603923a12.16.1736705942936; Sun, 12 Jan 2025 10:19:02 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Sun, 12 Jan 2025 18:19:02 +0000 From: Stefan Kangas In-Reply-To: References: MIME-Version: 1.0 Date: Sun, 12 Jan 2025 18:19:02 +0000 X-Gm-Features: AbW1kvbUEcqglC3LSaqMmNVDU1Lelnfg4jFEWok9q3jC1uHMEeky1IcKILG775c Message-ID: Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX To: =?UTF-8?Q?Gerd_M=C3=B6llmann?= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75521-done Cc: 75521-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Gerd M=C3=B6llmann writes: > Stefan Kangas writes: > >> Severity: wishlist >> >> Can we delete the unused macro DEFVAR_LISP_NOPROX? > > +1 Thanks, done, closing. From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 12 17:36:27 2025 Received: (at 75521) by debbugs.gnu.org; 12 Jan 2025 22:36:27 +0000 Received: from localhost ([127.0.0.1]:49403 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tX6ZH-0005ok-HT for submit@debbugs.gnu.org; Sun, 12 Jan 2025 17:36:27 -0500 Received: from mail-4316.protonmail.ch ([185.70.43.16]:37575) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tX6ZE-0005oV-Ij for 75521@debbugs.gnu.org; Sun, 12 Jan 2025 17:36:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1736721378; x=1736980578; bh=y8cKkANkyu99sncUyZckSi0Tuboku6kCdKEzwCvOpbg=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=FtV1DsR8dbQYyO2kDvNyZpCBtA3XBYjPzuE9uIudtPOjN3Pi2YHruCBHO9N2qkl+M raAm9TpgLHKMtNsIvfNc30/aQz0nO4cZGftKtN3jirjyxB74dRYNYg3SXQCzbDYAKx Ahf8RZJDVcuPbzbEYX0bI8W3KOZD6738bEc70JPlLWuwm4n8BnPd1r36RUDq8MHdAW XCiRKTvENPX+rgCNbEwVmcygdQW8Ud0o9jOw4phowB6a/lq2hCIo9xqbwQ9Lwg8U+r 45Cc/KyEz54OxIijnqARkwHkaIO3bynHmfAf7ajs7sGxWrlPOKbXEwJLLlw5TXN0R0 JQXc8SlYQ4ftQ== Date: Sun, 12 Jan 2025 22:36:12 +0000 To: 75521@debbugs.gnu.org From: Pip Cet Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX Message-ID: <87v7uju0bu.fsf@protonmail.com> In-Reply-To: References: Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 8b604910ba944f0dbb984c895e488ff226465db4 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75521 Cc: stefankangas@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) "Stefan Kangas" writes: > Gerd M=C3=B6llmann writes: > >> Stefan Kangas writes: >> >>> Severity: wishlist >>> >>> Can we delete the unused macro DEFVAR_LISP_NOPROX? >> >> +1 > > Thanks, done, closing. Thanks! On master, this comment might need revising (staticpro now easserts that the same variable isn't added twice): /* Similar but define a variable whose value is the Lisp Object stored at address. Two versions: with and without gc-marking of the C variable. The nopro version is used when that variable will be gc-marked for some other reason, since marking the same slot twice can cause trouble with strings. */ void defvar_lisp_nopro (struct Lisp_Fwd const *o_fwd, char const *namestring) { eassert (o_fwd->type =3D=3D Lisp_Fwd_Obj); Lisp_Object sym =3D intern_c_string (namestring); XBARE_SYMBOL (sym)->u.s.declared_special =3D true; XBARE_SYMBOL (sym)->u.s.redirect =3D SYMBOL_FORWARDED; SET_SYMBOL_FWD (XBARE_SYMBOL (sym), o_fwd); } Also on master, the single user of DEFVAR_LISP_NOPRO is questionable: font.c doesn't staticpro Vfont_weight_table because it appears in font_style_table, but then font_style_table is sometimes modified so it points to a new vector, and I don't see how Vfont_weight_table is protected then. GDB experiment seems to indicate it's not protected at all, but it's in the dump so it isn't freed either. When --enable-checking is in use, however, pdumper.c will abort the next time it sees an object that wasn't marked during a previous GC run. Pip From debbugs-submit-bounces@debbugs.gnu.org Sun Jan 12 17:53:29 2025 Received: (at 75521) by debbugs.gnu.org; 12 Jan 2025 22:53:29 +0000 Received: from localhost ([127.0.0.1]:49417 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tX6pl-0006Va-1e for submit@debbugs.gnu.org; Sun, 12 Jan 2025 17:53:29 -0500 Received: from mail-4322.protonmail.ch ([185.70.43.22]:51663) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tX6pi-0006VJ-31 for 75521@debbugs.gnu.org; Sun, 12 Jan 2025 17:53:27 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1736722399; x=1736981599; bh=qawCpiaO7wXHAlyqHl4anz4iu2vB211SaJ4tJP/w7rM=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=MNFMGzqzeqVpQkSogz4s/mGObHgtPaXzHgWl3542EoB+BsfzXpN0feVVmP366pDqZ cirO7rzhv+BFt5WYluUzWA77EgGHE+6MjHHDAXjrF3mJf55AYzXYV++IK6FZTF3+Fk YgOQxVCpPYraFQOAXJUkzBILC7DZJWnDHSQT4uaPfagozlMwoNRfzLH8ingYk4wdAX wv+JfMpQx6Qffj/cE9EFRI7CC4tWM4yACNtPFvUCI6N5+luv4E0e0QpZiMbS1EA6iK 4Yi5KjXJnrmRA+ib0Gt72K0aCjltaAFsmD2mEE3vyv76E0QYpXnLMJACRSpzTEs8oz NfbqlmIr7Ooug== Date: Sun, 12 Jan 2025 22:53:15 +0000 To: 75521@debbugs.gnu.org From: Pip Cet Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX Message-ID: <87r057tzjg.fsf@protonmail.com> In-Reply-To: References: Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 21abd2265bcfca51d6bf2a8120b91c21b9516ea8 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75521 Cc: stefankangas@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Pip Cet writes: > "Stefan Kangas" writes: > >> Gerd M=C3=B6llmann writes: >> >>> Stefan Kangas writes: >>> >>>> Severity: wishlist >>>> >>>> Can we delete the unused macro DEFVAR_LISP_NOPROX? >>> >>> +1 >> >> Thanks, done, closing. > > Thanks! > > On master, this comment might need revising (staticpro now easserts that > the same variable isn't added twice): > > /* Similar but define a variable whose value is the Lisp Object stored > at address. Two versions: with and without gc-marking of the C > variable. The nopro version is used when that variable will be > gc-marked for some other reason, since marking the same slot twice > can cause trouble with strings. */ > void > defvar_lisp_nopro (struct Lisp_Fwd const *o_fwd, char const *namestring) > { > eassert (o_fwd->type =3D=3D Lisp_Fwd_Obj); > Lisp_Object sym =3D intern_c_string (namestring); > XBARE_SYMBOL (sym)->u.s.declared_special =3D true; > XBARE_SYMBOL (sym)->u.s.redirect =3D SYMBOL_FORWARDED; > SET_SYMBOL_FWD (XBARE_SYMBOL (sym), o_fwd); > } > > Also on master, the single user of DEFVAR_LISP_NOPRO is questionable: > font.c doesn't staticpro Vfont_weight_table because it appears in > font_style_table, but then font_style_table is sometimes modified so it > points to a new vector, and I don't see how Vfont_weight_table is > protected then. > > GDB experiment seems to indicate it's not protected at all, but it's in > the dump so it isn't freed either. When --enable-checking is in use, > however, pdumper.c will abort the next time it sees an object that > wasn't marked during a previous GC run. Patch: >From 4ba048bad6ff21ab95a5aeb2cbf33dc825890949 Mon Sep 17 00:00:00 2001 From: Pip Cet Date: Sun, 12 Jan 2025 22:45:55 +0000 Subject: [PATCH] Remove DEFVAR_LISP_NOPRO * src/font.c (syms_of_font): Use 'DEFVAR_LISP', not 'DEFVAR_LISP_NOPRO'. * src/lisp.h (DEFVAR_LISP_NOPRO): Macro removed. * src/lread.c (defvar_lisp_nopro): Function removed. (defvar_lisp): Inline defvar_lisp_nopro here. --- src/font.c | 6 +++--- src/lisp.h | 7 ------- src/lread.c | 13 ++----------- 3 files changed, 5 insertions(+), 21 deletions(-) diff --git a/src/font.c b/src/font.c index 86382267a4a..e6c41e41258 100644 --- a/src/font.c +++ b/src/font.c @@ -5954,7 +5954,7 @@ syms_of_font (void) table used by the font display code. So we make them read-only, to avoid this confusing situation. */ =20 - DEFVAR_LISP_NOPRO ("font-weight-table", Vfont_weight_table, + DEFVAR_LISP ("font-weight-table", Vfont_weight_table, =09 doc: /* Vector of valid font weight values. Each element has the form: [NUMERIC-VALUE SYMBOLIC-NAME ALIAS-NAME ...] @@ -5963,14 +5963,14 @@ syms_of_font (void) Vfont_weight_table =3D BUILD_STYLE_TABLE (weight_table); make_symbol_constant (intern_c_string ("font-weight-table")); =20 - DEFVAR_LISP_NOPRO ("font-slant-table", Vfont_slant_table, + DEFVAR_LISP ("font-slant-table", Vfont_slant_table, =09 doc: /* Vector of font slant symbols vs the corresponding numer= ic values. See `font-weight-table' for the format of the vector. This variable cannot be set; trying to do so will signal an error. */); Vfont_slant_table =3D BUILD_STYLE_TABLE (slant_table); make_symbol_constant (intern_c_string ("font-slant-table")); =20 - DEFVAR_LISP_NOPRO ("font-width-table", Vfont_width_table, + DEFVAR_LISP ("font-width-table", Vfont_width_table, =09 doc: /* Alist of font width symbols vs the corresponding numeri= c values. See `font-weight-table' for the format of the vector. This variable cannot be set; trying to do so will signal an error. */); diff --git a/src/lisp.h b/src/lisp.h index e3142f3b8cc..7646a3dd5f1 100644 --- a/src/lisp.h +++ b/src/lisp.h @@ -3532,7 +3532,6 @@ call0 (Lisp_Object fn) } =20 extern void defvar_lisp (struct Lisp_Objfwd const *, char const *); -extern void defvar_lisp_nopro (struct Lisp_Objfwd const *, char const *); extern void defvar_bool (struct Lisp_Boolfwd const *, char const *); extern void defvar_int (struct Lisp_Intfwd const *, char const *); extern void defvar_kboard (struct Lisp_Kboard_Objfwd const *, char const *= ); @@ -3560,12 +3559,6 @@ #define DEFVAR_LISP(lname, vname, doc)=09=09\ =3D {Lisp_Fwd_Obj, &globals.f_##vname};=09\ defvar_lisp (&o_fwd, lname);=09=09\ } while (false) -#define DEFVAR_LISP_NOPRO(lname, vname, doc)=09\ - do {=09=09=09=09=09=09\ - static struct Lisp_Objfwd const o_fwd=09\ - =3D {Lisp_Fwd_Obj, &globals.f_##vname};=09\ - defvar_lisp_nopro (&o_fwd, lname);=09=09\ - } while (false) #define DEFVAR_BOOL(lname, vname, doc)=09=09\ do {=09=09=09=09=09=09\ static struct Lisp_Boolfwd const b_fwd=09\ diff --git a/src/lread.c b/src/lread.c index ab900b3bee6..d6fa84bb826 100644 --- a/src/lread.c +++ b/src/lread.c @@ -5510,23 +5510,14 @@ defvar_bool (struct Lisp_Boolfwd const *b_fwd, char= const *namestring) } =20 /* Similar but define a variable whose value is the Lisp Object stored - at address. Two versions: with and without gc-marking of the C - variable. The nopro version is used when that variable will be - gc-marked for some other reason, since marking the same slot twice - can cause trouble with strings. */ + at address. */ void -defvar_lisp_nopro (struct Lisp_Objfwd const *o_fwd, char const *namestring= ) +defvar_lisp (struct Lisp_Objfwd const *o_fwd, char const *namestring) { Lisp_Object sym =3D intern_c_string (namestring); XBARE_SYMBOL (sym)->u.s.declared_special =3D true; XBARE_SYMBOL (sym)->u.s.redirect =3D SYMBOL_FORWARDED; SET_SYMBOL_FWD (XBARE_SYMBOL (sym), o_fwd); -} - -void -defvar_lisp (struct Lisp_Objfwd const *o_fwd, char const *namestring) -{ - defvar_lisp_nopro (o_fwd, namestring); staticpro (o_fwd->objvar); } =20 --=20 2.47.1 From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 13 07:16:27 2025 Received: (at 75521) by debbugs.gnu.org; 13 Jan 2025 12:16:27 +0000 Received: from localhost ([127.0.0.1]:50566 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXJMo-00060z-Ta for submit@debbugs.gnu.org; Mon, 13 Jan 2025 07:16:27 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:49434) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tXJMm-00060a-B8 for 75521@debbugs.gnu.org; Mon, 13 Jan 2025 07:16:24 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tXJMg-0002hF-ID; Mon, 13 Jan 2025 07:16:18 -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=0BYcxRviB3QhOvCB1hmM+TTyHTd6zF7UKi9YkUmkau4=; b=hFUtC+e/0L/h lv8SEQR5afCHZBO+LKjoAHaRK9+6h3SZBxJn3qHICWYitVPx/DHh8u4kQ2ML3C1+aRAsFLqE7YavM 9O5OzSfLL0QHfwMQCYoKoYNDdspz7ZlA3ICTzPRfSfupUkV2e/UvFVevLIl1MQ6XKJraKLJYlZZ2T xHCaqJyElZcayZuhJrPG4P6mmFZKD/NX7o/A0HsZYlWnw5coafBue8Py1Vamcu2yxt9B6zUiHeCGp DH3zQD9nTKJr3C5pOwoRj/a80anUVSpj3rgR5lrHmbo4i86CsJS6vFILebVgXXFaTxQhfic4J3UHh rEQ7qp3yINsSBMTMiClvUA==; Date: Mon, 13 Jan 2025 14:16:15 +0200 Message-Id: <86frlmx628.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <87v7uju0bu.fsf@protonmail.com> (bug-gnu-emacs@gnu.org) Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX References: <87v7uju0bu.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75521 Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: stefankangas@gmail.com > Date: Sun, 12 Jan 2025 22:36:12 +0000 > From: Pip Cet via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > Also on master, the single user of DEFVAR_LISP_NOPRO is questionable: > font.c doesn't staticpro Vfont_weight_table because it appears in > font_style_table, but then font_style_table is sometimes modified so it > points to a new vector, and I don't see how Vfont_weight_table is > protected then. According to this comment: /* Vector of Vfont_weight_table, Vfont_slant_table, and Vfont_width_table. */ static Lisp_Object font_style_table; Vfont_weight_table is actually an element of font_style_table, and that one is protected: DEFVAR_LISP_NOPRO ("font-width-table", Vfont_width_table, doc: /* Alist of font width symbols vs the corresponding numeric values. See `font-weight-table' for the format of the vector. This variable cannot be set; trying to do so will signal an error. */); Vfont_width_table = BUILD_STYLE_TABLE (width_table); make_symbol_constant (intern_c_string ("font-width-table")); staticpro (&font_style_table); font_style_table = CALLN (Fvector, Vfont_weight_table, Vfont_slant_table, Vfont_width_table); From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 13 07:57:17 2025 Received: (at 75521) by debbugs.gnu.org; 13 Jan 2025 12:57:17 +0000 Received: from localhost ([127.0.0.1]:50643 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXK0K-0002Lf-Pc for submit@debbugs.gnu.org; Mon, 13 Jan 2025 07:57:17 -0500 Received: from mail-4316.protonmail.ch ([185.70.43.16]:25327) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tXK0I-0002LR-0S for 75521@debbugs.gnu.org; Mon, 13 Jan 2025 07:57:15 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1736773027; x=1737032227; bh=S7bM7QUo3I0ZnulOYgGyiqeOTz77+7gGmtEuvvi2PKY=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=EncBX4VMniwjYF0K0bQsS16Bm8CyBsciiovL4tBey0qMFmGLrXSQQ5Ik3cWqYm2hz d2H8H11MZ/K3jkmVksBOGEEXY665jsdJGr9EbObuV0mPAxz+e5ASrP2trSG4JAh/7v 9cQMf/190k47UzWJf8KQXp+yuD9OfwAGdOkjQ/3rdeSxKgU/zS+aB6BqNIIGxeXDw9 B7dgh9RHWNiD0uWoCVbWMb+q39CFao7RXlqZifr7vATP5MkyNbIUEdZwz/XVTV1mxe MRX3aUt1W+brON0ppsEPY6V6y8CJt7JjxJm7DZvxkRJXNxpQBXdBDb1W5FpqOcSVms YD8I3sa+iLPtg== Date: Mon, 13 Jan 2025 12:57:03 +0000 To: Eli Zaretskii From: Pip Cet Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX Message-ID: <87msfuub1k.fsf@protonmail.com> In-Reply-To: <86frlmx628.fsf@gnu.org> References: <87v7uju0bu.fsf@protonmail.com> <86frlmx628.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: df24ee4ceee74e0b14aa4d9419dbe8ab775f1fbe MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 75521 Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) "Eli Zaretskii" writes: >> Cc: stefankangas@gmail.com >> Date: Sun, 12 Jan 2025 22:36:12 +0000 >> From: Pip Cet via "Bug reports for GNU Emacs, >> the Swiss army knife of text editors" >> >> Also on master, the single user of DEFVAR_LISP_NOPRO is questionable: >> font.c doesn't staticpro Vfont_weight_table because it appears in >> font_style_table, but then font_style_table is sometimes modified so it >> points to a new vector, and I don't see how Vfont_weight_table is >> protected then. > > According to this comment: > > /* Vector of Vfont_weight_table, Vfont_slant_table, and Vfont_width_tab= le. */ > static Lisp_Object font_style_table; > > Vfont_weight_table is actually an element of font_style_table, and > that one is protected: But then font_style_table is sometimes modified so it points to (i.e. contains as its element) a new vector, and I don't see how Vfont_weight_table is protected then. Pip From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 13 08:30:32 2025 Received: (at submit) by debbugs.gnu.org; 13 Jan 2025 13:30:32 +0000 Received: from localhost ([127.0.0.1]:50691 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXKWV-0003sF-MC for submit@debbugs.gnu.org; Mon, 13 Jan 2025 08:30:32 -0500 Received: from lists.gnu.org ([2001:470:142::17]:56798) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tXKWT-0003rz-UD for submit@debbugs.gnu.org; Mon, 13 Jan 2025 08:30:30 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tXKW8-0005qB-PU for bug-gnu-emacs@gnu.org; Mon, 13 Jan 2025 08:30:17 -0500 Received: from mail-wm1-x330.google.com ([2a00:1450:4864:20::330]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tXKW6-0003ke-Su; Mon, 13 Jan 2025 08:30:08 -0500 Received: by mail-wm1-x330.google.com with SMTP id 5b1f17b1804b1-43690d4605dso29747175e9.0; Mon, 13 Jan 2025 05:30:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736775005; x=1737379805; darn=gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=ore/NeYfqsA8OAkfx+goVOQ7SC6rKwjC71kuObukQqM=; b=YwPuiGsqQHpKkouXWiw8QfIJGt7qnwnquSfDNdGWrrZv5U7RJbzeIH8narxhRlja9F N9BKZ6DOjpRqPGUSeruVcoYUp68D2LYO0wjkW4Ttce5rEi/6rRJD7xe8YjZGQMTO/gUR OpIs53iKC/v0th/6fhO0MpMYCOGdO9XAmyiktDm5u/n7iF7JmlC7EtbkoFiBz9ggss4v tYWoHklXVxcSYxoEEZ3Kce49a8McQ+h+nw0+x/otOyQoUcxDiIM1jd0fMs4J/DBpqq1e FLdkZoZj94EHC3BsNhRW+RmwhS4YbKCHrgNFTCowyf2uzm8kTCIg8kpQJA4yM9q7lnIg /+iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736775005; x=1737379805; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ore/NeYfqsA8OAkfx+goVOQ7SC6rKwjC71kuObukQqM=; b=TR5Wn9z125h7BNm2uUkvYtRC7WdEQNxBIfGyAf8yURrznXIDuP71qdnbatho+P3/83 nKzj/QNXFOf9p+Ov/P4uMi/GeV/lZladVgB7LRv1WdHMAcE6jrbucjMB0a8Qd36/IzCu kPBaqmlnY3RXwPaYv1irwDUYA+3Qpc2Bp1yJvmkbRLNGWbYp/vKXN4UPkGPzagelE7tl V3WPU+nRy+bZTngwYkZ8zZ9qPRymjLMY21Aqq0T1mIacp2Cl+WxGKu7xhhE+mKkhRRZ/ CMYgJAhfdRFjPwXrWdkV4E7Rz3yLJnVqzD3o5rCCmY3ne0WfzXY+azFLivSIDiEOY79J MpmQ== X-Gm-Message-State: AOJu0Yy0VkaGcxHqLHuinfssx8xJMk7Y8GF5WWN2RykvXaXwggZG7VqW O4UZJ01VZslpUknJZAIdrMocS+b1atBjOJEJ2wqIbVrUtOrFF4IwCq84gg== X-Gm-Gg: ASbGnctXSsH2iBQohHZnxW1BIDiMV+vGcZvs+dG8k8WbjYDpNA211bIRMxCZpBjz5Ni pxninhysap/QPuzKexOnAugGvBeTXLvRWO9R8Tg/UyzJRgaCOQcYMd89NcnAUTC3oHclRiva/xj JoGq5MdReJxudBil0GlVxbFI5H5zJ2b09Z+5Gbr17bvoOekhOJUw6nD/kGz8YOFrITwcwvcRJ9s weyUoOTfUbwLLW7XD+nLYGmi3E+G2UrqW/RErir4MiKwuvh7u0MlnYelfevo9JIw/RoR9ny6FNg Hlfkvq59PUqjrAjJQRiCvzTnj+uZkMenVpe/URArcr08ErDF45douDNCJqJ2 X-Google-Smtp-Source: AGHT+IG2JBekwhcSOWj2hBul24P32CSEf2n7A4xcFz33U8stcqssi8fNu0D9xQtXL52NsGnczbFYXQ== X-Received: by 2002:a05:600c:a44:b0:434:a852:ba6d with SMTP id 5b1f17b1804b1-436e2692d98mr186462335e9.9.1736775004600; Mon, 13 Jan 2025 05:30:04 -0800 (PST) Received: from pro2 (p200300e0b71c2600d4477660fe6d1730.dip0.t-ipconnect.de. [2003:e0:b71c:2600:d447:7660:fe6d:1730]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-436e9e03e5fsm142339495e9.18.2025.01.13.05.30.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Jan 2025 05:30:04 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX In-Reply-To: <87msfuub1k.fsf@protonmail.com> (Pip Cet via's message of "Mon, 13 Jan 2025 12:57:03 +0000") References: <87v7uju0bu.fsf@protonmail.com> <86frlmx628.fsf@gnu.org> <87msfuub1k.fsf@protonmail.com> Date: Mon, 13 Jan 2025 14:30:03 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2a00:1450:4864:20::330; envelope-from=gerd.moellmann@gmail.com; helo=mail-wm1-x330.google.com X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text editors" writes: > "Eli Zaretskii" writes: > >>> Cc: stefankangas@gmail.com >>> Date: Sun, 12 Jan 2025 22:36:12 +0000 >>> From: Pip Cet via "Bug reports for GNU Emacs, >>> the Swiss army knife of text editors" >>> [...] Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (gerd.moellmann[at]gmail.com) -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [2001:470:142:0:0:0:0:17 listed in] [list.dnswl.org] 1.0 FREEMAIL_REPLY From and body contain different freemails X-Debbugs-Envelope-To: submit Cc: 75521@debbugs.gnu.org, Eli Zaretskii , Pip Cet , stefankangas@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text editors" writes: > "Eli Zaretskii" writes: > >>> Cc: stefankangas@gmail.com >>> Date: Sun, 12 Jan 2025 22:36:12 +0000 >>> From: Pip Cet via "Bug reports for GNU Emacs, >>> the Swiss army knife of text editors" >>> >>> Also on master, the single user of DEFVAR_LISP_NOPRO is questionable: >>> font.c doesn't staticpro Vfont_weight_table because it appears in >>> font_style_table, but then font_style_table is sometimes modified so it >>> points to a new vector, and I don't see how Vfont_weight_table is >>> protected then. >> >> According to this comment: >> >> /* Vector of Vfont_weight_table, Vfont_slant_table, and Vfont_width_table. */ >> static Lisp_Object font_style_table; >> >> Vfont_weight_table is actually an element of font_style_table, and >> that one is protected: > > But then font_style_table is sometimes modified so it points to > (i.e. contains as its element) a new vector, and I don't see how > Vfont_weight_table is protected then. > > Pip BTW, this is _exactly_ how the old GCPRO macro was used. "We don't need to GCPRO this local variable here because it's already protected by something else". Horrible nightmare! That caused me such pain debugging that I added conservative stack marking, split off the SDATA from strings and so on. I'd hope Emacs overcomes this. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 13 08:47:53 2025 Received: (at 75521) by debbugs.gnu.org; 13 Jan 2025 13:47:53 +0000 Received: from localhost ([127.0.0.1]:50715 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXKnI-0004bB-LG for submit@debbugs.gnu.org; Mon, 13 Jan 2025 08:47:52 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:57766) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tXKnG-0004au-Ag for 75521@debbugs.gnu.org; Mon, 13 Jan 2025 08:47:51 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tXKn8-0006ZK-OL; Mon, 13 Jan 2025 08:47:43 -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=7lIozjDlhmDzXz2ni9Hj9T3HWNTcjkY7s891Jdk4hak=; b=Ku2Dak1Mo+x5 8F7YH58KZPcvZAVbKbk3vkWB2ObGQWw1Loz9MlwR9MeiYGljxnYQtj3sFPRuwSKtz0V9TIBP9soTn gWAJ27SFJMF73J+a0fLJgNXQyCvcUJGLTiABVnDTnhNOntV1jmbs07Pne0dVpbor/cUEoYvNjSMxw 99Z9Gl5AcyXZ+ailbj2aSGNw/+xAfB18m+BYviBmblQEfkGWfD7LvlQeYszFcFPdgfWkLlMum0jue jalHfMm+M77OfCwIQa/5A5E+gXLx7aNwsBjLtbi0l+HUDq8pz9+8qPuwOnhn3KHNhIrzktHnFBaVk XpAWi+a60fpLIUygSqvXgQ==; Date: Mon, 13 Jan 2025 15:47:30 +0200 Message-Id: <86sepmvn9p.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <87msfuub1k.fsf@protonmail.com> (message from Pip Cet on Mon, 13 Jan 2025 12:57:03 +0000) Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX References: <87v7uju0bu.fsf@protonmail.com> <86frlmx628.fsf@gnu.org> <87msfuub1k.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75521 Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Mon, 13 Jan 2025 12:57:03 +0000 > From: Pip Cet > Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com > > "Eli Zaretskii" writes: > > > According to this comment: > > > > /* Vector of Vfont_weight_table, Vfont_slant_table, and Vfont_width_table. */ > > static Lisp_Object font_style_table; > > > > Vfont_weight_table is actually an element of font_style_table, and > > that one is protected: > > But then font_style_table is sometimes modified so it points to > (i.e. contains as its element) a new vector, and I don't see how > Vfont_weight_table is protected then. Modified where? From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 13 09:16:19 2025 Received: (at 75521) by debbugs.gnu.org; 13 Jan 2025 14:16:19 +0000 Received: from localhost ([127.0.0.1]:50768 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXLEo-0005sI-Cy for submit@debbugs.gnu.org; Mon, 13 Jan 2025 09:16:18 -0500 Received: from mail-10631.protonmail.ch ([79.135.106.31]:14989) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tXLEl-0005s1-T4 for 75521@debbugs.gnu.org; Mon, 13 Jan 2025 09:16:16 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1736777768; x=1737036968; bh=eI3YhtzFHzaeh4EW+ZJEJ3GWXf+Mak4VxvRXV4GJ6eo=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=muL/0NFjuAUJMTpXOJOwAi/S+pPWV6gPzVhUu/JEhAGnE7UqV/oAunUfapcj8IBvQ juqUFPCEelltUtDGeB7+TrdTlO8axFsOQt6l46NB5u2VGsy87BHV1vvA1+GYMuZBPt y8qVdpHGpLRYMd14DDjFuLRQfDpu1LwUJk5QH3RZsUoHK9YdPTi7bPmT1QolSV87Yx lwVhPHl/1GLKhHEsKjDtJ1mZBUDtZdW6v0JL6Z5RKub7kn+IkBWx3kwfAHUY1VR59G jxG5nzFqRASyjku1k8fjaHssipSNuNotrDG0qPInN0LgtZ+PFQy4mykXC1ES/bt5HX NFRJ27Zd+6mXQ== Date: Mon, 13 Jan 2025 14:16:04 +0000 To: Eli Zaretskii From: Pip Cet Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX Message-ID: <87ed16u7dw.fsf@protonmail.com> In-Reply-To: <86sepmvn9p.fsf@gnu.org> References: <87v7uju0bu.fsf@protonmail.com> <86frlmx628.fsf@gnu.org> <87msfuub1k.fsf@protonmail.com> <86sepmvn9p.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 27062ae8e2c74e65e62e49c3bc8366ea7f78445c MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 75521 Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) "Eli Zaretskii" writes: >> Date: Mon, 13 Jan 2025 12:57:03 +0000 >> From: Pip Cet >> Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com >> >> "Eli Zaretskii" writes: >> >> > According to this comment: >> > >> > /* Vector of Vfont_weight_table, Vfont_slant_table, and Vfont_width_= table. */ >> > static Lisp_Object font_style_table; >> > >> > Vfont_weight_table is actually an element of font_style_table, and >> > that one is protected: >> >> But then font_style_table is sometimes modified so it points to >> (i.e. contains as its element) a new vector, and I don't see how >> Vfont_weight_table is protected then. > > Modified where? font_style_to_value: if (! noerror) =09return -1; eassert (len < 255); elt =3D make_vector (2, make_fixnum (100)); ASET (elt, 1, val); ASET (font_style_table, prop - FONT_WEIGHT_INDEX, =09 CALLN (Fvconcat, table, make_vector (1, elt))); return (100 << 8) | (i << 4); It's not clear to me when this code is reached (usually, noerror is false and we don't modify font_style_table), but if it ever is reached, we lose (at least when --enable-checking or in temacs). The crash is easy to fix, but it's not at all clear to me that modifying font_style_table shouldn't also modify Vfont_weight_table etc. However, it is clear that the _NOPRO isn't required or helpful, and since that's the last usage, let's just remove this remnant of GCPRO times. If, in addition, we want to keep Vfont_weight_table synchronized with the table used by the font code to resolve weight symbols, we can do this (this would change behavior in those cases that previously resulted in a crash): diff --git a/src/font.c b/src/font.c index e6c41e41258..9b3d294640e 100644 --- a/src/font.c +++ b/src/font.c @@ -47,7 +47,22 @@ Copyright (C) 2006, 2007, 2008, 2009, 2010, 2011 #define DEFAULT_ENCODING Qiso8859_1 =20 /* Vector of Vfont_weight_table, Vfont_slant_table, and Vfont_width_table.= */ -static Lisp_Object font_style_table; +static Lisp_Object *font_style_table (int index) +{ + Lisp_Object *ret; + if (index =3D=3D FONT_WEIGHT_INDEX) + ret =3D &Vfont_weight_table; + else if (index =3D=3D FONT_SLANT_INDEX) + ret =3D &Vfont_slant_table; + else if (index =3D=3D FONT_WIDTH_INDEX) + ret =3D &Vfont_width_table; + else + emacs_abort (); + + CHECK_VECTOR (*ret); + + return ret; +} =20 /* Structure used for tables mapping weight, slant, and width numeric values and their names. */ @@ -376,10 +391,9 @@ font_pixel_size (struct frame *f, Lisp_Object spec) font_style_to_value (enum font_property_index prop, Lisp_Object val, bool noerror) { - Lisp_Object table =3D AREF (font_style_table, prop - FONT_WEIGHT_INDEX); + Lisp_Object table =3D *font_style_table (prop); int len; =20 - CHECK_VECTOR (table); len =3D ASIZE (table); =20 if (SYMBOLP (val)) @@ -418,8 +432,8 @@ font_style_to_value (enum font_property_index prop, Lis= p_Object val, eassert (len < 255); elt =3D make_vector (2, make_fixnum (100)); ASET (elt, 1, val); - ASET (font_style_table, prop - FONT_WEIGHT_INDEX, -=09 CALLN (Fvconcat, table, make_vector (1, elt))); + *font_style_table(prop) =3D +=09CALLN (Fvconcat, table, make_vector (1, elt)); return (100 << 8) | (i << 4); } else @@ -461,8 +475,7 @@ font_style_symbolic (Lisp_Object font, enum font_proper= ty_index prop, =20 if (NILP (val)) return Qnil; - table =3D AREF (font_style_table, prop - FONT_WEIGHT_INDEX); - CHECK_VECTOR (table); + table =3D *font_style_table (prop); i =3D XFIXNUM (val) & 0xFF; eassert (((i >> 4) & 0xF) < ASIZE (table)); elt =3D AREF (table, ((i >> 4) & 0xF)); @@ -588,13 +601,12 @@ font_prop_validate_style (Lisp_Object style, Lisp_Obj= ect val) if (FIXNUMP (val)) { EMACS_INT n =3D XFIXNUM (val); - CHECK_VECTOR (AREF (font_style_table, prop - FONT_WEIGHT_INDEX)); if (((n >> 4) & 0xF) -=09 >=3D ASIZE (AREF (font_style_table, prop - FONT_WEIGHT_INDEX))) +=09 >=3D ASIZE (*font_style_table (prop))) =09val =3D Qerror; else =09{ -=09 Lisp_Object elt =3D AREF (AREF (font_style_table, prop - FONT_WEIGHT_= INDEX), (n >> 4) & 0xF); +=09 Lisp_Object elt =3D AREF (*font_style_table (prop), (n >> 4) & 0xF); =20 =09 CHECK_VECTOR (elt); =09 if ((n & 0xF) + 1 >=3D ASIZE (elt)) @@ -5949,11 +5961,6 @@ syms_of_font (void) gets the repertory information by an opened font and ENCODING. */); Vfont_encoding_alist =3D Qnil; =20 - /* FIXME: These 3 vars are not quite what they appear: setq on them - won't have any effect other than disconnect them from the style - table used by the font display code. So we make them read-only, - to avoid this confusing situation. */ - DEFVAR_LISP ("font-weight-table", Vfont_weight_table, =09 doc: /* Vector of valid font weight values. Each element has the form: @@ -5961,25 +5968,18 @@ syms_of_font (void) NUMERIC-VALUE is an integer, and SYMBOLIC-NAME and ALIAS-NAME are symbols. This variable cannot be set; trying to do so will signal an error. */); Vfont_weight_table =3D BUILD_STYLE_TABLE (weight_table); - make_symbol_constant (intern_c_string ("font-weight-table")); =20 DEFVAR_LISP ("font-slant-table", Vfont_slant_table, =09 doc: /* Vector of font slant symbols vs the corresponding numer= ic values. See `font-weight-table' for the format of the vector. This variable cannot be set; trying to do so will signal an error. */); Vfont_slant_table =3D BUILD_STYLE_TABLE (slant_table); - make_symbol_constant (intern_c_string ("font-slant-table")); =20 DEFVAR_LISP ("font-width-table", Vfont_width_table, =09 doc: /* Alist of font width symbols vs the corresponding numeri= c values. See `font-weight-table' for the format of the vector. This variable cannot be set; trying to do so will signal an error. */); Vfont_width_table =3D BUILD_STYLE_TABLE (width_table); - make_symbol_constant (intern_c_string ("font-width-table")); - - staticpro (&font_style_table); - font_style_table =3D CALLN (Fvector, Vfont_weight_table, Vfont_slant_tab= le, -=09=09=09 Vfont_width_table); =20 DEFVAR_LISP ("font-log", Vfont_log, doc: /* A list that logs font-related actions and results, for debugging. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 13 09:27:19 2025 Received: (at submit) by debbugs.gnu.org; 13 Jan 2025 14:27:19 +0000 Received: from localhost ([127.0.0.1]:50791 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXLPS-0006Uo-Pm for submit@debbugs.gnu.org; Mon, 13 Jan 2025 09:27:19 -0500 Received: from lists.gnu.org ([2001:470:142::17]:48604) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tXLPP-0006UN-TT for submit@debbugs.gnu.org; Mon, 13 Jan 2025 09:27:17 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tXLPJ-0000w2-6g for bug-gnu-emacs@gnu.org; Mon, 13 Jan 2025 09:27:10 -0500 Received: from mail-40134.protonmail.ch ([185.70.40.134]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tXLPH-0003ln-IK for bug-gnu-emacs@gnu.org; Mon, 13 Jan 2025 09:27:08 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1736778424; x=1737037624; bh=tgPl8KHajDdLZcCvuAloPomUJZptCK0t3QaIATKrnao=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=sBZnP4ftoHaDbEBw/yitNLlmBTnE176ngn3f3tqy2AClgoozErp3vuS33AToYR8Mw yXEwvFmOf3m2GCGfwQ0Uzy0pD2+/bj4frHXvGP4c0Tt4+LcCorUSySrHm0cvP4jrkA nAwvg9YQo9O4TtDxmiqkLqf6ZOxNSti0TiKpDMQxVtTfZvK/2jYjp6dYHoMa97yaeS RwTuONIEUtYkR09qrteR/F+196an3KCJpioUVoixZ7SgAbWnSutNhYybhrHPFE5KAn X4+47Uh+4QT8heB64zk9syvBjzz9Vu3Rr8xC1h/gM4HuPgyGjhfiDUP3WeFqq13ha9 NpgsozcbZcJzg== Date: Mon, 13 Jan 2025 14:27:01 +0000 To: =?utf-8?Q?Gerd_M=C3=B6llmann?= From: Pip Cet Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX Message-ID: <87cygqu6vn.fsf@protonmail.com> In-Reply-To: References: <87v7uju0bu.fsf@protonmail.com> <86frlmx628.fsf@gnu.org> <87msfuub1k.fsf@protonmail.com> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 2bdab0f16cd1eb5de86d787f590cb881796c61b3 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.70.40.134; envelope-from=pipcet@protonmail.com; helo=mail-40134.protonmail.ch X-Spam_score_int: -10 X-Spam_score: -1.1 X-Spam_bar: - X-Spam_report: (-1.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, FREEMAIL_REPLY=1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: 2.0 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Gerd Möllmann writes: > Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text > editors" writes: > >> "Eli Zaretskii" writes: >> >>>> Cc: stefankangas@gmail.com >>>> Date: Sun, 12 Jan 2025 22:36:12 +0000 [...] Content analysis details: (2.0 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [2001:470:142:0:0:0:0:17 listed in] [list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (pipcet[at]protonmail.com) -0.0 SPF_HELO_PASS SPF: HELO matches SPF record 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) 1.0 FREEMAIL_REPLY From and body contain different freemails X-Debbugs-Envelope-To: submit Cc: 75521@debbugs.gnu.org, "Pip Cet via \"Bug reports for GNU Emacs, the Swiss army knife of text editors\"" , Eli Zaretskii , stefankangas@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) Gerd M=C3=B6llmann writes: > Pip Cet via "Bug reports for GNU Emacs, the Swiss army knife of text > editors" writes: > >> "Eli Zaretskii" writes: >> >>>> Cc: stefankangas@gmail.com >>>> Date: Sun, 12 Jan 2025 22:36:12 +0000 >>>> From: Pip Cet via "Bug reports for GNU Emacs, >>>> the Swiss army knife of text editors" >>>> >>>> Also on master, the single user of DEFVAR_LISP_NOPRO is questionable: >>>> font.c doesn't staticpro Vfont_weight_table because it appears in >>>> font_style_table, but then font_style_table is sometimes modified so i= t >>>> points to a new vector, and I don't see how Vfont_weight_table is >>>> protected then. >>> >>> According to this comment: >>> >>> /* Vector of Vfont_weight_table, Vfont_slant_table, and Vfont_width_t= able. */ >>> static Lisp_Object font_style_table; >>> >>> Vfont_weight_table is actually an element of font_style_table, and >>> that one is protected: >> >> But then font_style_table is sometimes modified so it points to >> (i.e. contains as its element) a new vector, and I don't see how >> Vfont_weight_table is protected then. >> >> Pip > > BTW, this is _exactly_ how the old GCPRO macro was used. "We don't need > to GCPRO this local variable here because it's already protected by > something else". Indeed. I played around with GC shortly before GCPRO was removed, thinking (naively) that almost all Lisp_Objects that needed to survive GC were GCPRO'd, and we would be able to use that for precise GC. But GCPRO only ever protected the value of a Lisp_Object, never its address, making it useless for other purposes. > That caused me such pain debugging > that I added conservative stack marking, split off the SDATA from > strings and so on. I'd hope Emacs overcomes this. I'm thinking of these changes as removing the last (hopefully) remnants of GCPRO: 1. Remove DEFVAR_LISP_NOPRO 2. Conservatively mark SAFE_ALLOCA'd memory 3. Conservatively mark SDATA pointers so they remain valid The problem with (3) is that pin_string becomes unnecessary for correctness then, and it would be nice to remove it, but I suspect that it is still necessary for performance: there are a lot of bytecode objects, and while we might hope that most of them live in the "old" sblocks that aren't copied, I don't think that's always true. (My implementation reorders sdata a little but not by more than one sblock. It'd be easy to change that not to reorder sdata at all, but then we'd see fragmentation). However, that still doesn't fix make_environment_block, which uses xmalloc. So we'd have to xstrdup there; or make some xmalloc'd memory conservatively scanned; or rewrite it to be a macro which calls SAFE_ALLOCA. Pip From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 13 11:41:42 2025 Received: (at 75521) by debbugs.gnu.org; 13 Jan 2025 16:41:42 +0000 Received: from localhost ([127.0.0.1]:52630 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXNVW-0007aa-7h for submit@debbugs.gnu.org; Mon, 13 Jan 2025 11:41:42 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:47656) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tXNVT-0007aJ-8Y for 75521@debbugs.gnu.org; Mon, 13 Jan 2025 11:41:40 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tXNVN-0005Ue-Ry; Mon, 13 Jan 2025 11:41:33 -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=e3ow9i7Opn4pUAoDhbbJS2ouH4/FhwXN0s2914Z26WY=; b=NTR0dB/0vGt7 auU0g0Vk68NS+kCoZ3rkYytatJ4MLmw6iiMCJvbtJ1cyPoU65oKltbVABpaiEbNeaRdv0GM8Pe0NW 5N0EST6JnLHmqpP38E8gdkN+uRjxUtTUF8pGehN+v8tfcSgXbPrjaPjU2NWrzE3NlwCl6L1HVaJIc 22p7WM03Lh01ImKDLmZDfqpCdk9vXpRecr1El7XikUl/w4wvJ8ZMixjRgVdMYFsXFtxgvl3YMaI/p I0wJK//Bm3qaV+sZ4+YacWY43oApHPZs2CeJz6I9byhu30Je4ySrv7hqFhGG3IUNS5EQ45jW6uGGH +WtfIFrJWrMW3ZBJY/ZvKw==; Date: Mon, 13 Jan 2025 18:41:32 +0200 Message-Id: <86jzayvf7n.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <87ed16u7dw.fsf@protonmail.com> (message from Pip Cet on Mon, 13 Jan 2025 14:16:04 +0000) Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX References: <87v7uju0bu.fsf@protonmail.com> <86frlmx628.fsf@gnu.org> <87msfuub1k.fsf@protonmail.com> <86sepmvn9p.fsf@gnu.org> <87ed16u7dw.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75521 Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Mon, 13 Jan 2025 14:16:04 +0000 > From: Pip Cet > Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com > > "Eli Zaretskii" writes: > > >> But then font_style_table is sometimes modified so it points to > >> (i.e. contains as its element) a new vector, and I don't see how > >> Vfont_weight_table is protected then. > > > > Modified where? > > font_style_to_value: > > if (! noerror) > return -1; > eassert (len < 255); > elt = make_vector (2, make_fixnum (100)); > ASET (elt, 1, val); > ASET (font_style_table, prop - FONT_WEIGHT_INDEX, > CALLN (Fvconcat, table, make_vector (1, elt))); > return (100 << 8) | (i << 4); OK, but the values gets plugged int font_style_table, right? And my reading of mark_object_root_visitor is that it marks its argument recursively, so any object reachable from font_style_table should also be protected? Am I wrong? From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 13 11:44:51 2025 Received: (at submit) by debbugs.gnu.org; 13 Jan 2025 16:44:51 +0000 Received: from localhost ([127.0.0.1]:52639 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXNYZ-0007fa-GE for submit@debbugs.gnu.org; Mon, 13 Jan 2025 11:44:51 -0500 Received: from lists.gnu.org ([2001:470:142::17]:49728) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tXNYX-0007fB-Dj for submit@debbugs.gnu.org; Mon, 13 Jan 2025 11:44:49 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tXNYR-00035M-U3 for bug-gnu-emacs@gnu.org; Mon, 13 Jan 2025 11:44:43 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tXNYR-0006M5-9Q; Mon, 13 Jan 2025 11:44:43 -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=6GUbW9ZdAON/hjoQwKub1xHl26SOsK7JPkaAgXGjCA8=; b=KJuTOshGo8Wd Bt/1eaTMgbE6hfg+Ao+n8zvdQv4O9acbBb72LAF3PEi9Ritl1NIKLxk2rCMV0gMWu8ZterUO/c3gh 2pcWxQuYyoTe0NRFavjeJpzm6hDKdEVAEx9uPpkpaPqFWhr3c8QQ0KvBrCIKSVlgcapgVHr51UGF2 Y1v0AY8i79SbmNlmR7K5sDIJYflSyyVJ+yPNEbLTtpdodd/me/OQIthjluUExb6HB0GpqaTa+EPn4 DV7tmkNR9Rtw7Qp186bRdrN7tCs5Jrko0N5YWeLHMdXJUL2SNAkfauKr9OFJa7LGnUl42tWy3rygd BLGiSz6sMmd7yWl7NXkYQQ==; Date: Mon, 13 Jan 2025 18:44:40 +0200 Message-Id: <86ikqivf2f.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <87cygqu6vn.fsf@protonmail.com> (message from Pip Cet on Mon, 13 Jan 2025 14:27:01 +0000) Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX References: <87v7uju0bu.fsf@protonmail.com> <86frlmx628.fsf@gnu.org> <87msfuub1k.fsf@protonmail.com> <87cygqu6vn.fsf@protonmail.com> X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: submit Cc: gerd.moellmann@gmail.com, 75521@debbugs.gnu.org, bug-gnu-emacs@gnu.org, stefankangas@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > Date: Mon, 13 Jan 2025 14:27:01 +0000 > From: Pip Cet > Cc: "Pip Cet via \"Bug reports for GNU Emacs, the Swiss army knife of text editors\"" , Eli Zaretskii , 75521@debbugs.gnu.org, stefankangas@gmail.com > > I'm thinking of these changes as removing the last (hopefully) remnants > of GCPRO: > > 1. Remove DEFVAR_LISP_NOPRO > 2. Conservatively mark SAFE_ALLOCA'd memory > 3. Conservatively mark SDATA pointers so they remain valid Let's not waste our time on improving the old GC, except where we have real bugs people actually bump into. Let's instead focus on making the igc branch ready sooner. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 13 11:46:53 2025 Received: (at 75521) by debbugs.gnu.org; 13 Jan 2025 16:46:53 +0000 Received: from localhost ([127.0.0.1]:52648 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXNaX-0007pL-3S for submit@debbugs.gnu.org; Mon, 13 Jan 2025 11:46:53 -0500 Received: from mail-10628.protonmail.ch ([79.135.106.28]:55835) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tXNaU-0007p4-6F for 75521@debbugs.gnu.org; Mon, 13 Jan 2025 11:46:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1736786803; x=1737046003; bh=jtSHElp4D5lx64O1NmLvp7/wT9Bc/L9V+gtGjrZN55w=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=yfq6UueduCGofOnn0Gt5nrHmbh5qRQS/nnQfiFqkTzTUfD6RVcU2IOR+2ElqZruqX Vk0fltN3nlX956jpaJ7FZVAPpWV0Qs3U4ZYn3sI7Zc+RqGlCGyKQpKm7+8cey7Im1N odJp6DQXrpv/4M867FPpPZ88ZtKz4FNpUzO2JwHkj7oy8BAP0AgT6U/WW+sFfkb87Z St4NvRtjAJB/VTU1Uy3hjP14/HGk/XNdiu/4Mwk4yEwDop1lSqYRUysNXOqWas2Ydx 1RZ/+TCPH4sy1Dg4DHtZe29Qla0x/xaAzin+cj1gVVSHkU2nKcgfGDxHN8ORU3Copr bXLniu2DFd9Zg== Date: Mon, 13 Jan 2025 16:46:39 +0000 To: Eli Zaretskii From: Pip Cet Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX Message-ID: <875xmiu0ex.fsf@protonmail.com> In-Reply-To: <86jzayvf7n.fsf@gnu.org> References: <87v7uju0bu.fsf@protonmail.com> <86frlmx628.fsf@gnu.org> <87msfuub1k.fsf@protonmail.com> <86sepmvn9p.fsf@gnu.org> <87ed16u7dw.fsf@protonmail.com> <86jzayvf7n.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 8c185f8d1c10df6845229d3055b37efd88089b30 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 75521 Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) "Eli Zaretskii" writes: >> Date: Mon, 13 Jan 2025 14:16:04 +0000 >> From: Pip Cet >> Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com >> >> "Eli Zaretskii" writes: >> >> >> But then font_style_table is sometimes modified so it points to >> >> (i.e. contains as its element) a new vector, and I don't see how >> >> Vfont_weight_table is protected then. >> > >> > Modified where? >> >> font_style_to_value: >> >> if (! noerror) >> =09return -1; >> eassert (len < 255); >> elt =3D make_vector (2, make_fixnum (100)); >> ASET (elt, 1, val); >> ASET (font_style_table, prop - FONT_WEIGHT_INDEX, >> =09 CALLN (Fvconcat, table, make_vector (1, elt))); >> return (100 << 8) | (i << 4); > > OK, but the values gets plugged int font_style_table, right? And my > reading of mark_object_root_visitor is that it marks its argument > recursively, so any object reachable from font_style_table should also > be protected? Am I wrong? No, you're not. Initially, Vfont_weight_table is protected because it's reached recursively from font_style_table. If font_style_table is modified no longer to contain Vfont_weight_table (by the code above), Vfont_weight_table loses its protection. Accessing Vfont_weight_table from Lisp when it's no longer protected will eventually cause a crash. Pip From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 13 12:16:34 2025 Received: (at 75521) by debbugs.gnu.org; 13 Jan 2025 17:16:34 +0000 Received: from localhost ([127.0.0.1]:52700 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXO3F-0000mo-QF for submit@debbugs.gnu.org; Mon, 13 Jan 2025 12:16:34 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:47660) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tXO3D-0000mY-4D for 75521@debbugs.gnu.org; Mon, 13 Jan 2025 12:16:31 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tXO37-0003M0-GJ; Mon, 13 Jan 2025 12:16:25 -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=Le6MXyYsU9QebuSr9lIbdB3f9F+YJX+RfxvBg+hyLfY=; b=c+3M3DqmQocy i0wSZC5a40hwOnTFih54x/aXM1ycMIAsE5JL3rUVMVZNxbgYl37BuLZTEME83kr+6yBpuGQqMUvFh eO3bEYaN+ArIzwLYGYZwdlvbr7cFEehaRpK3EIQ6N06IWuaoJ5841nsWf2Lb2AreQW/NXD+rPIREx ztwfiC6UiOjOTtyEFTb78T6x+U/N8R9qAbk+Vq8uwlubITEVNkTcbMh+0/AolAL7U6ggOgMcMkpTP 5G6gsgCajLNQ7jJCzHM15TzOW2OhNL2+FF4603YygVUHDi7MvfhW9Dt1zw6NF6rjcM0eo/JD3Shr/ ZaEWrVP0sf0XWvorgg6gNA==; Date: Mon, 13 Jan 2025 19:16:21 +0200 Message-Id: <86ed16vdlm.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <875xmiu0ex.fsf@protonmail.com> (message from Pip Cet on Mon, 13 Jan 2025 16:46:39 +0000) Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX References: <87v7uju0bu.fsf@protonmail.com> <86frlmx628.fsf@gnu.org> <87msfuub1k.fsf@protonmail.com> <86sepmvn9p.fsf@gnu.org> <87ed16u7dw.fsf@protonmail.com> <86jzayvf7n.fsf@gnu.org> <875xmiu0ex.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75521 Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Mon, 13 Jan 2025 16:46:39 +0000 > From: Pip Cet > Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com > > "Eli Zaretskii" writes: > > >> Date: Mon, 13 Jan 2025 14:16:04 +0000 > >> From: Pip Cet > >> Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com > >> > >> "Eli Zaretskii" writes: > >> > >> >> But then font_style_table is sometimes modified so it points to > >> >> (i.e. contains as its element) a new vector, and I don't see how > >> >> Vfont_weight_table is protected then. > >> > > >> > Modified where? > >> > >> font_style_to_value: > >> > >> if (! noerror) > >> return -1; > >> eassert (len < 255); > >> elt = make_vector (2, make_fixnum (100)); > >> ASET (elt, 1, val); > >> ASET (font_style_table, prop - FONT_WEIGHT_INDEX, > >> CALLN (Fvconcat, table, make_vector (1, elt))); > >> return (100 << 8) | (i << 4); > > > > OK, but the values gets plugged int font_style_table, right? And my > > reading of mark_object_root_visitor is that it marks its argument > > recursively, so any object reachable from font_style_table should also > > be protected? Am I wrong? > > No, you're not. Initially, Vfont_weight_table is protected because it's > reached recursively from font_style_table. If font_style_table is > modified no longer to contain Vfont_weight_table (by the code above), > Vfont_weight_table loses its protection. Accessing Vfont_weight_table > from Lisp when it's no longer protected will eventually cause a crash. But the above code just uses ASET to put in one of font_style_table's slots a Lisp vector. That vector is therefore reachable from font_style_table (which is also a Lisp vector). No? From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 13 12:19:15 2025 Received: (at 75521) by debbugs.gnu.org; 13 Jan 2025 17:19:15 +0000 Received: from localhost ([127.0.0.1]:52705 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXO5q-0000rC-LM for submit@debbugs.gnu.org; Mon, 13 Jan 2025 12:19:14 -0500 Received: from mail-10630.protonmail.ch ([79.135.106.30]:22689) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tXO5o-0000qy-HO for 75521@debbugs.gnu.org; Mon, 13 Jan 2025 12:19:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1736788744; x=1737047944; bh=3JjXRkckptUgZ/N0XLLI926CsUpP+iySHFMkkUJBpgU=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=aIRAlvioSYChYQCe/FGp/rmb7xz61oF7PWxuMIDiY/6US3ZF8S9vIguRl/5445Qcm +SJ+6wjgZlPaEOCGTIDySGELD6VNujABoKTtt+wulY1tsvUWeCX7m55QJ3FWMWS45t 7UiesedTOqb1OiDr5f0lKcspxmqP+M+NEIQ0RzjxVg0TIzluqyeJq9242UUHFcj8CL aUn860JvxYWhq7JGi0cHeZq6SPe1OTIfB2JoVbuYB5mlsFHTPtSiPEAW1pFZ9Wc4Hs y19lOj8S8RuRy7YqJr79mzpN9iuTunqVL5c1esyMb/4TLXQtqS2q5CfM2aAiSq5c/s eCIXy61dgHrrw== Date: Mon, 13 Jan 2025 17:18:58 +0000 To: Eli Zaretskii From: Pip Cet Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX Message-ID: <871px6tyx2.fsf@protonmail.com> In-Reply-To: <86ed16vdlm.fsf@gnu.org> References: <87v7uju0bu.fsf@protonmail.com> <86frlmx628.fsf@gnu.org> <87msfuub1k.fsf@protonmail.com> <86sepmvn9p.fsf@gnu.org> <87ed16u7dw.fsf@protonmail.com> <86jzayvf7n.fsf@gnu.org> <875xmiu0ex.fsf@protonmail.com> <86ed16vdlm.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: eeeec8f14b10af4cd0946f540936a0d0c4fc1522 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 75521 Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) "Eli Zaretskii" writes: >> Date: Mon, 13 Jan 2025 16:46:39 +0000 >> From: Pip Cet >> Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com >> >> "Eli Zaretskii" writes: >> >> >> Date: Mon, 13 Jan 2025 14:16:04 +0000 >> >> From: Pip Cet >> >> Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com >> >> >> >> "Eli Zaretskii" writes: >> >> >> >> >> But then font_style_table is sometimes modified so it points to >> >> >> (i.e. contains as its element) a new vector, and I don't see how >> >> >> Vfont_weight_table is protected then. >> >> > >> >> > Modified where? >> >> >> >> font_style_to_value: >> >> >> >> if (! noerror) >> >> =09return -1; >> >> eassert (len < 255); >> >> elt =3D make_vector (2, make_fixnum (100)); >> >> ASET (elt, 1, val); >> >> ASET (font_style_table, prop - FONT_WEIGHT_INDEX, >> >> =09 CALLN (Fvconcat, table, make_vector (1, elt))); >> >> return (100 << 8) | (i << 4); >> > >> > OK, but the values gets plugged int font_style_table, right? And my >> > reading of mark_object_root_visitor is that it marks its argument >> > recursively, so any object reachable from font_style_table should also >> > be protected? Am I wrong? >> >> No, you're not. Initially, Vfont_weight_table is protected because it's >> reached recursively from font_style_table. If font_style_table is >> modified no longer to contain Vfont_weight_table (by the code above), >> Vfont_weight_table loses its protection. Accessing Vfont_weight_table >> from Lisp when it's no longer protected will eventually cause a crash. > > But the above code just uses ASET to put in one of font_style_table's > slots a Lisp vector. That vector is therefore reachable from > font_style_table (which is also a Lisp vector). No? But the old vector, which was in the slot before, is no longer reachable after the ASET. That old vector can still be referenced from Lisp as font-weight-table (or one of the other two). That means an object is reachable from Lisp but not protected from GC. Pip From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 13 12:36:24 2025 Received: (at 75521) by debbugs.gnu.org; 13 Jan 2025 17:36:24 +0000 Received: from localhost ([127.0.0.1]:52737 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXOMP-0001g2-0Y for submit@debbugs.gnu.org; Mon, 13 Jan 2025 12:36:24 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:36124) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tXOML-0001fo-SE for 75521@debbugs.gnu.org; Mon, 13 Jan 2025 12:36:18 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tXOMF-0006yc-Mn; Mon, 13 Jan 2025 12:36:12 -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=7Tz3bp9FYvDDOb4JINAGhv07zad8GfbpgfjUfCOV2oQ=; b=ii4IhVTa/KQd 4usIKuhhozFacwdkmsOgnsGimxDCVjUBaUOQZt5nddAqHkYrhUnlJEi3RXserKafhm5+5YrYmK06K rblOihcRo/2i4dieEPxq8D4JB2LcbXHuKDiXo1C/F73uULMEGYGEagZeX6CHyDliW1h7tcruWPmcI HzdnQBv4u6wMeAqMOx1+uHDyFSnCwKto/x+CS8HaRQLKgsIiYC95kJYtwTgPLdwsQDIRVxVeElSRG ArcLAl2tiAa/YUpqzLyqwP0PgWDWxIDfeQDvzBA4irHdaYiHAuvsWpTyNiHqwBLK5mxIx+LIp9HV0 udAXqi7oXYNOAMWjhSIgrg==; Date: Mon, 13 Jan 2025 19:35:27 +0200 Message-Id: <86a5buvcps.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <871px6tyx2.fsf@protonmail.com> (message from Pip Cet on Mon, 13 Jan 2025 17:18:58 +0000) Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX References: <87v7uju0bu.fsf@protonmail.com> <86frlmx628.fsf@gnu.org> <87msfuub1k.fsf@protonmail.com> <86sepmvn9p.fsf@gnu.org> <87ed16u7dw.fsf@protonmail.com> <86jzayvf7n.fsf@gnu.org> <875xmiu0ex.fsf@protonmail.com> <86ed16vdlm.fsf@gnu.org> <871px6tyx2.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75521 Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Mon, 13 Jan 2025 17:18:58 +0000 > From: Pip Cet > Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com > > "Eli Zaretskii" writes: > > >> Date: Mon, 13 Jan 2025 16:46:39 +0000 > >> From: Pip Cet > >> Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com > >> > >> "Eli Zaretskii" writes: > >> > >> >> Date: Mon, 13 Jan 2025 14:16:04 +0000 > >> >> From: Pip Cet > >> >> Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com > >> >> > >> >> "Eli Zaretskii" writes: > >> >> > >> >> >> But then font_style_table is sometimes modified so it points to > >> >> >> (i.e. contains as its element) a new vector, and I don't see how > >> >> >> Vfont_weight_table is protected then. > >> >> > > >> >> > Modified where? > >> >> > >> >> font_style_to_value: > >> >> > >> >> if (! noerror) > >> >> return -1; > >> >> eassert (len < 255); > >> >> elt = make_vector (2, make_fixnum (100)); > >> >> ASET (elt, 1, val); > >> >> ASET (font_style_table, prop - FONT_WEIGHT_INDEX, > >> >> CALLN (Fvconcat, table, make_vector (1, elt))); > >> >> return (100 << 8) | (i << 4); > >> > > >> > OK, but the values gets plugged int font_style_table, right? And my > >> > reading of mark_object_root_visitor is that it marks its argument > >> > recursively, so any object reachable from font_style_table should also > >> > be protected? Am I wrong? > >> > >> No, you're not. Initially, Vfont_weight_table is protected because it's > >> reached recursively from font_style_table. If font_style_table is > >> modified no longer to contain Vfont_weight_table (by the code above), > >> Vfont_weight_table loses its protection. Accessing Vfont_weight_table > >> from Lisp when it's no longer protected will eventually cause a crash. > > > > But the above code just uses ASET to put in one of font_style_table's > > slots a Lisp vector. That vector is therefore reachable from > > font_style_table (which is also a Lisp vector). No? > > But the old vector, which was in the slot before, is no longer reachable > after the ASET. AFAIU, we copy the old vector to the new one when we call vconcat. > That old vector can still be referenced from Lisp as > font-weight-table (or one of the other two). That means an object is > reachable from Lisp but not protected from GC. I don't understand: if it's reachable from Lisp, it must be protected by definition, no? GC can only free objects that are not reachable from any other object. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 13 13:14:01 2025 Received: (at 75521) by debbugs.gnu.org; 13 Jan 2025 18:14:01 +0000 Received: from localhost ([127.0.0.1]:52799 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXOwq-0003Lb-Pf for submit@debbugs.gnu.org; Mon, 13 Jan 2025 13:14:01 -0500 Received: from mail-ed1-x532.google.com ([2a00:1450:4864:20::532]:47284) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tXOwn-0003L4-B6 for 75521@debbugs.gnu.org; Mon, 13 Jan 2025 13:13:58 -0500 Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-5d647d5df90so7699167a12.2 for <75521@debbugs.gnu.org>; Mon, 13 Jan 2025 10:13:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736792031; x=1737396831; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=sMK/aFfW2cN5IQ0n4ybG0A1EEP/A+ch4iiK2sgCdjCg=; b=HAr5H+Fhg0x3tYc3VEAu6h+RpBXzMRrufU8Oez4OQIvR/1Chhl6MCblib0AyvA0DJX fy1jc8bT50aKkbmSyb3sxD8SzGeYdJk2YMzhkvCJl+DvOrYPNtlfc8HXdRQvACoRJnV8 1VWYaln/L32MuNvGHK5vsVVRfDR/jbQdtUnjBbK+NBo+trBcjrjKHLk0r7Wl7td8/LoB Bv8VFu3/A0xILVk+Ixu5r7Zldz2odjtYDJFSaFCG9ZBvxnM6AxofNQbhAepjNZPuoLmn oEO7Nx0MV8KeBlzFL40MF9fC4Kg2vfZ2fFBuXccFhBypSDRJIHJ7WSl046wsKvt65xO8 l98A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736792031; x=1737396831; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=sMK/aFfW2cN5IQ0n4ybG0A1EEP/A+ch4iiK2sgCdjCg=; b=W1XRbnTLmHWA+6FoEBdIR73+NhXcojCmpB1gB0KM7wdYFwXsxNN8L+63IW7WUfMCko PpU+wvtft9QozFB+CO7wjThTo4d4mSZMbdVx1JQFJVFXZCgDT0LkUUoO7D3FFYUeY5Lh Aamg9+cWIT8ImD1jfP6VpOI6dIFx6tavcLLNpCv00YLVqzygvQ66LRrcp3HUCqC9ZWBn rFyFdjpNP56KUxJb+hmFDzbQU2qXSpZv7f31tnRGVyzeKsLrud7GBAo+FJbb5BsoI29r +Bd8pl4SfzrfnA1COALn52sVx5GFo2tJGegTqJ02WAmChNbFA0ArYvIsL5HjG11H41z9 vr3w== X-Forwarded-Encrypted: i=1; AJvYcCWZpaCoxhijkHw39mbtB7NgreM4oorarlmnjXDi+RdcKXB6H9HuBMkDZ3rp0eYGRHlpfsAeHA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxJTChMMBxV86c3TXykRfGpRTTzjOlPYkNFO2PL93/aL9mZGOmC +cgy0WYkmO4g9O8DeTeAs419ldcdXWisEPLolU+zvX8NI9W9dPp8yAUMGgqGUpaRdE6EppPfCzb 8mCU7+svBNmIxPwtL67HwPLgFu0w= X-Gm-Gg: ASbGncvM0x0OPZrpWQRmBe0HBfdBy6rHSWQYDLMmOsGjNAVYH0BF++GIzMsLDCrk+tq tGxqwEMfOwwFG0WQjV4UsX9P/3uAliuq6LgNDn32o X-Google-Smtp-Source: AGHT+IGj816tHZsMF7BIfqcIhpgTxuFnmwl/xJpTGwSCfc8VKQOUPZ4zXAEuZcKvw3AdXObeyuT1w2rbCpIPY8wbwPQ= X-Received: by 2002:a05:6402:40d5:b0:5d9:f21e:ff5 with SMTP id 4fb4d7f45d1cf-5d9f21e18a0mr1085388a12.16.1736792030917; Mon, 13 Jan 2025 10:13:50 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Mon, 13 Jan 2025 18:13:50 +0000 From: Stefan Kangas In-Reply-To: <86ikqivf2f.fsf@gnu.org> References: <87v7uju0bu.fsf@protonmail.com> <86frlmx628.fsf@gnu.org> <87msfuub1k.fsf@protonmail.com> <87cygqu6vn.fsf@protonmail.com> <86ikqivf2f.fsf@gnu.org> MIME-Version: 1.0 Date: Mon, 13 Jan 2025 18:13:50 +0000 X-Gm-Features: AbW1kvb5Idwm4PWBDQkDD08vaN8Nx42WhFbhuxU1s2X3kmwHkRBxmi85hO9xtvE Message-ID: Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX To: Eli Zaretskii , Pip Cet Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75521 Cc: gerd.moellmann@gmail.com, 75521@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> Date: Mon, 13 Jan 2025 14:27:01 +0000 >> From: Pip Cet >> Cc: "Pip Cet via \"Bug reports for GNU Emacs, the Swiss army knife of text editors\"" , Eli Zaretskii , 75521@debbugs.gnu.org, stefankangas@gmail.com >> >> I'm thinking of these changes as removing the last (hopefully) remnants >> of GCPRO: >> >> 1. Remove DEFVAR_LISP_NOPRO >> 2. Conservatively mark SAFE_ALLOCA'd memory >> 3. Conservatively mark SDATA pointers so they remain valid > > Let's not waste our time on improving the old GC, except where we have > real bugs people actually bump into. Let's instead focus on making > the igc branch ready sooner. I didn't look into 2-3, but at least 1 seems aligned with the goal of merging the igc branch sooner. It's not a huge deal, but it's one less thing to worry about. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 13 13:21:19 2025 Received: (at 75521) by debbugs.gnu.org; 13 Jan 2025 18:21:19 +0000 Received: from localhost ([127.0.0.1]:52821 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXP3v-0003kZ-7o for submit@debbugs.gnu.org; Mon, 13 Jan 2025 13:21:19 -0500 Received: from mail-40134.protonmail.ch ([185.70.40.134]:28619) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tXP3s-0003kK-Jh for 75521@debbugs.gnu.org; Mon, 13 Jan 2025 13:21:17 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1736792469; x=1737051669; bh=6X0TbqHQcgc1woVl43gbSz1hFEqiOXWqeovik6umrFU=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=PJHDMKipIXXAt3wqX178EZ4OwjCCPHWDzE/GPd4v9GxD0eg0PG5FMB/P5bz6WDl4p lh2Pju8ReJRSLwOlo900Y3c0icYH1dh8ygiT/bMO1CC1Z4P7cawoEGTwCKRIj36cu3 1JtPvC2hx3mvHwl86CVNw9I57obo6gakLskcaHNzHUIbvlK4WLglX6bQ+oFCxc2xL6 f+5RahQXcnwzWT6dXcvN6BCavJGPvGsAbcKZtZ6Uwx7w4KIBugxLa2S+50p4wwYCLx g1XB64vYx0TjxNJ9Kuvsb5NbDaDQUPwbK9p/P38SGzE844QD/kfcwAuVDGYdszwFS5 jzybTXKPAMVJQ== Date: Mon, 13 Jan 2025 18:21:05 +0000 To: Eli Zaretskii From: Pip Cet Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX Message-ID: <87wmeyshh3.fsf@protonmail.com> In-Reply-To: <86a5buvcps.fsf@gnu.org> References: <87msfuub1k.fsf@protonmail.com> <86sepmvn9p.fsf@gnu.org> <87ed16u7dw.fsf@protonmail.com> <86jzayvf7n.fsf@gnu.org> <875xmiu0ex.fsf@protonmail.com> <86ed16vdlm.fsf@gnu.org> <871px6tyx2.fsf@protonmail.com> <86a5buvcps.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 7e581b6a170735398f8e032e1a503118053c32aa MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 75521 Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) "Eli Zaretskii" writes: >> Date: Mon, 13 Jan 2025 17:18:58 +0000 >> From: Pip Cet >> Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com >> >> "Eli Zaretskii" writes: >> >> >> Date: Mon, 13 Jan 2025 16:46:39 +0000 >> >> From: Pip Cet >> >> Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com >> >> >> >> "Eli Zaretskii" writes: >> >> >> >> >> Date: Mon, 13 Jan 2025 14:16:04 +0000 >> >> >> From: Pip Cet >> >> >> Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com >> >> >> >> >> >> "Eli Zaretskii" writes: >> >> >> >> >> >> >> But then font_style_table is sometimes modified so it points to >> >> >> >> (i.e. contains as its element) a new vector, and I don't see ho= w >> >> >> >> Vfont_weight_table is protected then. >> >> >> > >> >> >> > Modified where? >> >> >> >> >> >> font_style_to_value: >> >> >> >> >> >> if (! noerror) >> >> >> =09return -1; >> >> >> eassert (len < 255); >> >> >> elt =3D make_vector (2, make_fixnum (100)); >> >> >> ASET (elt, 1, val); >> >> >> ASET (font_style_table, prop - FONT_WEIGHT_INDEX, >> >> >> =09 CALLN (Fvconcat, table, make_vector (1, elt))); >> >> >> return (100 << 8) | (i << 4); >> >> > >> >> > OK, but the values gets plugged int font_style_table, right? And m= y >> >> > reading of mark_object_root_visitor is that it marks its argument >> >> > recursively, so any object reachable from font_style_table should a= lso >> >> > be protected? Am I wrong? >> >> >> >> No, you're not. Initially, Vfont_weight_table is protected because i= t's >> >> reached recursively from font_style_table. If font_style_table is >> >> modified no longer to contain Vfont_weight_table (by the code above), >> >> Vfont_weight_table loses its protection. Accessing Vfont_weight_tabl= e >> >> from Lisp when it's no longer protected will eventually cause a crash= . >> > >> > But the above code just uses ASET to put in one of font_style_table's >> > slots a Lisp vector. That vector is therefore reachable from >> > font_style_table (which is also a Lisp vector). No? >> >> But the old vector, which was in the slot before, is no longer reachable >> after the ASET. > > AFAIU, we copy the old vector to the new one when we call vconcat. Fvconcat creates a new vector, with some of its contents copied from the old vector. It does not destroy the old vector or make it reachable from the new vector. The old vector remains a valid Lisp object, and it's still reachable from Lisp by evaluating font-weight-table, but it's not marked during GC. (When using pdumper, it's not usually freed because it's in the dump, and we never free dumped objects, but pdumper also eassert()s that a dump object which was unreachable during a GC cycle never becomes reachable again. If you build with checking enabled, it's easy enough to get a crash if font_style_to_value ever modifies font_style_table, but I don't know for which font backends it ever does that by itself: doing it in GDB triggers the bug just as I described, though). >> That old vector can still be referenced from Lisp as >> font-weight-table (or one of the other two). That means an object is >> reachable from Lisp but not protected from GC. > > I don't understand: if it's reachable from Lisp, it must be protected > by definition, no? No, that's not correct. GC only protects global Lisp_Object variables if they're staticpro'd. A non-staticpro'd Lisp_Object variable must be protected in another way, or we have an unprotected reachable object. > GC can only free objects that are not reachable from any other object. No, that's not correct: the value of a forwarded symbol is not marked by alloc.c GC. =09 case SYMBOL_FORWARDED: =09=09/* If the value is forwarded to a buffer or keyboard field, =09=09 these are marked when we see the corresponding object. =09=09 And if it's forwarded to a C variable, either it's not =09=09 a Lisp_Object var, or it's staticpro'd already, or it's =09=09 reachable from font_style_table which is also =09=09 staticpro'd. */ =09=09break; That comment is incorrect, because font_style_table may contain a newly-consed vector, not the one that's still referred to as font-weight-table. Pip From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 13 13:55:22 2025 Received: (at 75521) by debbugs.gnu.org; 13 Jan 2025 18:55:23 +0000 Received: from localhost ([127.0.0.1]:52859 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXPas-0005He-EP for submit@debbugs.gnu.org; Mon, 13 Jan 2025 13:55:22 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:51990) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tXPaq-0005HM-0j for 75521@debbugs.gnu.org; Mon, 13 Jan 2025 13:55:20 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tXPak-0008JR-9I; Mon, 13 Jan 2025 13:55:14 -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=d9TRhUeZimJuZoraRaKFhw3DA5EFC0V7MjKh+2npDPM=; b=Yt8ouUcCOZMV fQc8wg1G5OS3Ck88S3benxa2dtN6PO3YalQs1f/B0wBsoAf4sbaOhj2p6B24JbGlk9CNIH+cntI8S U/SV1HOtAP9QycKzrSV0LqGTBtwSzB0o/R96GGGaEyOr9iDjKpJZdKJbHz77EqyIjltnFMSKK12Vw MuVS1AB64He4O2e2SJgT8U/O3cua37O1vhdeejQPCVLdS9jV+QyJazSrqJ9j/KfD6CBkG2liZLWW3 EgajCPuVcOFpjLkVxT3mNyg0hju7b3cuOg+urp3DrHZWnQX0gHR+RCObWYip0Zz9spJNw5Zlrxr/w t8Qa1sTH5psTWIx9k9b4gQ==; Date: Mon, 13 Jan 2025 20:55:07 +0200 Message-Id: <867c6yv910.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <87wmeyshh3.fsf@protonmail.com> (message from Pip Cet on Mon, 13 Jan 2025 18:21:05 +0000) Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX References: <87msfuub1k.fsf@protonmail.com> <86sepmvn9p.fsf@gnu.org> <87ed16u7dw.fsf@protonmail.com> <86jzayvf7n.fsf@gnu.org> <875xmiu0ex.fsf@protonmail.com> <86ed16vdlm.fsf@gnu.org> <871px6tyx2.fsf@protonmail.com> <86a5buvcps.fsf@gnu.org> <87wmeyshh3.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75521 Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Mon, 13 Jan 2025 18:21:05 +0000 > From: Pip Cet > Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com > > "Eli Zaretskii" writes: > > >> But the old vector, which was in the slot before, is no longer reachable > >> after the ASET. > > > > AFAIU, we copy the old vector to the new one when we call vconcat. > > Fvconcat creates a new vector, with some of its contents copied from the > old vector. It does not destroy the old vector or make it reachable > from the new vector. The old vector remains a valid Lisp object, and > it's still reachable from Lisp by evaluating font-weight-table, but it's > not marked during GC. (When using pdumper, it's not usually freed > because it's in the dump, and we never free dumped objects, but pdumper > also eassert()s that a dump object which was unreachable during a GC > cycle never becomes reachable again. If you build with checking > enabled, it's easy enough to get a crash if font_style_to_value ever > modifies font_style_table, but I don't know for which font backends it > ever does that by itself: doing it in GDB triggers the bug just as I > described, though). I think there's a misunderstanding here. Can you please walk me through the code below: Lisp_Object table = AREF (font_style_table, prop - FONT_WEIGHT_INDEX); ... elt = make_vector (2, make_fixnum (100)); ASET (elt, 1, val); ASET (font_style_table, prop - FONT_WEIGHT_INDEX, CALLN (Fvconcat, table, make_vector (1, elt))); and tell what is the "old vector" here that you are talking about? And if that old vector is reachable from font_style_table, why do you say it is not marked, if mark_object_root_visitor marks its argument recursively? > >> That old vector can still be referenced from Lisp as > >> font-weight-table (or one of the other two). That means an object is > >> reachable from Lisp but not protected from GC. > > > > I don't understand: if it's reachable from Lisp, it must be protected > > by definition, no? > > No, that's not correct. GC only protects global Lisp_Object variables > if they're staticpro'd. A non-staticpro'd Lisp_Object variable must be > protected in another way, or we have an unprotected reachable object. So you are saying that the problem that we don't assign the new value (received from vconcat) to the appropriate variable (Vfont_weight_table etc.)? > > GC can only free objects that are not reachable from any other object. > > No, that's not correct: the value of a forwarded symbol is not marked by > alloc.c GC. > > case SYMBOL_FORWARDED: > /* If the value is forwarded to a buffer or keyboard field, > these are marked when we see the corresponding object. > And if it's forwarded to a C variable, either it's not > a Lisp_Object var, or it's staticpro'd already, or it's > reachable from font_style_table which is also > staticpro'd. */ > break; > > That comment is incorrect, because font_style_table may contain a > newly-consed vector, not the one that's still referred to as > font-weight-table. Sorry, you lost me here. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 13 14:08:08 2025 Received: (at 75521) by debbugs.gnu.org; 13 Jan 2025 19:08:08 +0000 Received: from localhost ([127.0.0.1]:52869 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXPnE-0005ri-5x for submit@debbugs.gnu.org; Mon, 13 Jan 2025 14:08:08 -0500 Received: from mail-ed1-x535.google.com ([2a00:1450:4864:20::535]:48564) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tXPnB-0005r7-Ej for 75521@debbugs.gnu.org; Mon, 13 Jan 2025 14:08:06 -0500 Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-5d9f0a6adb4so1007483a12.1 for <75521@debbugs.gnu.org>; Mon, 13 Jan 2025 11:08:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736795278; x=1737400078; darn=debbugs.gnu.org; h=to:subject:message-id:date:mime-version:references:in-reply-to:from :from:to:cc:subject:date:message-id:reply-to; bh=T83KSEWAJ+RKWh33iozI6Fv7wQwkNOkLHhd5q4grAus=; b=LhcV5VDWMbHQHPBoXPN7hpPGLfi33gSJyUiAxRLIWyx/rR1E7HjHzyozMUeWn4NuKM e4v4Lgfy7hfroCeAXFCll+44+ilWN4u9rsx1qaHxWZskr9ptmPC3k69GFBp1CLvmQuaf GbrvaHGL5YbbNxM2wn5onwgawgtSviodfh6bR0tKQdKZJZreABJfM6c40sBQ4e5xHhic TOE8oWzYUkKrHcvKvyzC8oCQ+kWMil7Epui1GOGTcMFnhO4ZbM+ucEmHoJWzWaPWp1Et Qu4PN92BPhi5VpMjJPagWmXQ66Li6FNqFjleZTnZtVYAJpXqoPM6QlKJfhrFFHjzoJK3 Co8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736795278; x=1737400078; h=to:subject:message-id:date:mime-version:references:in-reply-to:from :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=T83KSEWAJ+RKWh33iozI6Fv7wQwkNOkLHhd5q4grAus=; b=YdsVpvLkj4GW2jPv8bzO8oHy0b0V3e0x1gG+oaIDqjb6GC7Pda9LaI3Pe/YrRyXacK eTEd26t//g62zAPRsX/BnKAk4MxauFJavh2O16Fq0kTiXdyPs2BdugTCvHFwFqLnTY1j EPHJVcdab9JLOawqS3xVUBQKe9dPtBl5tScjNzjuEwyhzFUFYVojDTMYHxPRQlaZuy3O FBQ/W4daD2m1TMnwgJmq7CU2+mnyFvpEhhu15o0fPCF6Kr++b5LqVxzcSe18wXqkz6sW 3N05ZJFFa7LBKr4mbzC+4iumpghZuJhswOHTVi69byGDG+tfwZ3gX9d6tMS66Ia+N4zm G/Og== X-Forwarded-Encrypted: i=1; AJvYcCWDPjINGsw31VQQKvk1JZb5Jo9BP6jOmHZhK8x8Fm3AokdfiNEL8u1zk/VgI5F3aWnvfKODjA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwpTapUqufvhnetVLsaZ3zuZdKvsFXsp5vR0QiByOXhLy3+c5kW 2RDjDdC/GeABtiz3+fSdjD+01pjCOvX1RPJPBHlURiQ1KjaC5ekdgAwyGgl/nrSBAwasQi4FW/r fENLJW3IMv+CY2ZSKWpyIMUDO6mI= X-Gm-Gg: ASbGncv8uYUDLEw3nwxKr2aoX7zqxK4JVwHVdeNHsg7TwrFtX6fTHg1fZJOAiEjza4R jyPpNXJhRjRg47K2f5meh7M4vsL+SVG6dbx3xPvAG X-Google-Smtp-Source: AGHT+IER77BNqh7p4aaL8v/qN+r8jpbTTjLmjEZqTchiR+bH2CSviTO27X4EX6R4F0ZflPAcM7VwthH6QhvzDew3Liw= X-Received: by 2002:a50:c94d:0:b0:5d9:82bc:ad05 with SMTP id 4fb4d7f45d1cf-5d982bcb4b7mr13077519a12.8.1736795277755; Mon, 13 Jan 2025 11:07:57 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Mon, 13 Jan 2025 19:07:57 +0000 From: Stefan Kangas In-Reply-To: <87r057tzjg.fsf@protonmail.com> References: <87r057tzjg.fsf@protonmail.com> MIME-Version: 1.0 Date: Mon, 13 Jan 2025 19:07:57 +0000 X-Gm-Features: AbW1kvZHcMaesDMW-OnBngyhpKF_LRzq4HqkRSntOi2wNb1LFQe3XttAc7Nqjp0 Message-ID: Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX To: Pip Cet , 75521@debbugs.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75521 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Pip Cet writes: > Patch: Thanks! Your patch seems to make things both safer and simpler. I'm curious why this was considered worth optimizing in the first place. Is it just a remnant from the olden days when doing that type of thing might have been more worthwhile? These days, I'd doubt that it would make a measurable difference. DEFVAR_LISP_NOPRO was introduced at least as early as 1991. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 13 14:16:29 2025 Received: (at 75521) by debbugs.gnu.org; 13 Jan 2025 19:16:29 +0000 Received: from localhost ([127.0.0.1]:52888 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXPvI-0006GP-QO for submit@debbugs.gnu.org; Mon, 13 Jan 2025 14:16:29 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:49118) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tXPvF-0006GB-TD for 75521@debbugs.gnu.org; Mon, 13 Jan 2025 14:16:26 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tXPv9-0002km-Uw; Mon, 13 Jan 2025 14:16:20 -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=+ppKSX4Z78mxOZaf28PLpNXmxPEZ6ZcUUSNuBT99vNc=; b=DfDzppk+JQDh ESIf3Xzl4P0pW//gF0fC7VeDgtIX5SPxpjY7FSKrQ8CF3w7pT3UeQ5e6t181APvFDBCUFHvzOW6j9 MgRd76TVIeQ9vrTVkJt9YgXbnf5lmRpkGsjdlWm7WM8w72XdyoIccnn/mUzyr+vX1ltDc+wV+Z7hB rxlfDrMaCgkOxB36UlYv2hBhGUQkt3gEnYmAT7C9WpuXMVZZgcDOgVJp62g+MW+O1cijj3ftlZItz MVf5ZvHzpvu9kbuirM34lpsLqJLj79hRMvpH3N4MWgfLxG2dUqem6gqYVI7MZA6ArhcT6ZJMJsJ4y im/5YrGiRzK0n3lWFPdVDA==; Date: Mon, 13 Jan 2025 21:16:15 +0200 Message-Id: <865xmiv81s.fsf@gnu.org> From: Eli Zaretskii To: Stefan Kangas In-Reply-To: (message from Stefan Kangas on Mon, 13 Jan 2025 19:07:57 +0000) Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX References: <87r057tzjg.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75521 Cc: 75521@debbugs.gnu.org, pipcet@protonmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Kangas > Date: Mon, 13 Jan 2025 19:07:57 +0000 > > Pip Cet writes: > > > Patch: > > Thanks! Your patch seems to make things both safer and simpler. We are still discussing what should be the minimal change in this case and where exactly. > I'm curious why this was considered worth optimizing in the first place. What is the optimization here? DEFVAR_LISP_NOPRO or font_style_table? From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 13 14:19:16 2025 Received: (at 75521) by debbugs.gnu.org; 13 Jan 2025 19:19:16 +0000 Received: from localhost ([127.0.0.1]:52893 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXPxz-0006M2-Mn for submit@debbugs.gnu.org; Mon, 13 Jan 2025 14:19:16 -0500 Received: from mail-4316.protonmail.ch ([185.70.43.16]:56355) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tXPxw-0006Lo-GS for 75521@debbugs.gnu.org; Mon, 13 Jan 2025 14:19:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1736795945; x=1737055145; bh=lafFQr13fQQ8kIlRICvHbpiqNGlvoDdHxe5TyHcgr20=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=M4vHuUEbpkpmQ1SJ+bB/wQeUJNxTYHfkV4OEuGSP3/7/OFvkwoFUQo3Mfd2ABzTk5 2e9SduOmRJ5une0capuhptS/EnZJmTm5DaL/JpXp/MwFRIVFdKmtMxSeW8bsSeskKw L97W0tiHkv2OIG6TJsy1pszKbGPwGNwRmFrGFJKscYfHV5TFknhJEo0Ycv1l4xwcM+ GnuAXKV710NHMCtunl0/uJX7aoRsbQLXLJMfUv/ZTWKUxigAuZ5sllmdXBd8O/F1fo r/VAKXWIMPviv7ErTEJg85CfZ39JubTRQfB9+INxxs18394m2ahgxDzN82hC8fwM0j FzFQJmUSVRNzw== Date: Mon, 13 Jan 2025 19:18:59 +0000 To: Eli Zaretskii From: Pip Cet Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX Message-ID: <87ldveseso.fsf@protonmail.com> In-Reply-To: <867c6yv910.fsf@gnu.org> References: <87ed16u7dw.fsf@protonmail.com> <86jzayvf7n.fsf@gnu.org> <875xmiu0ex.fsf@protonmail.com> <86ed16vdlm.fsf@gnu.org> <871px6tyx2.fsf@protonmail.com> <86a5buvcps.fsf@gnu.org> <87wmeyshh3.fsf@protonmail.com> <867c6yv910.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 49421a1c33b4554729ae9055c3d457f2790e1e5b MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 75521 Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) "Eli Zaretskii" writes: >> Date: Mon, 13 Jan 2025 18:21:05 +0000 >> From: Pip Cet >> Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com >> >> "Eli Zaretskii" writes: >> >> >> But the old vector, which was in the slot before, is no longer reacha= ble >> >> after the ASET. >> > >> > AFAIU, we copy the old vector to the new one when we call vconcat. >> >> Fvconcat creates a new vector, with some of its contents copied from the >> old vector. It does not destroy the old vector or make it reachable >> from the new vector. The old vector remains a valid Lisp object, and >> it's still reachable from Lisp by evaluating font-weight-table, but it's >> not marked during GC. (When using pdumper, it's not usually freed >> because it's in the dump, and we never free dumped objects, but pdumper >> also eassert()s that a dump object which was unreachable during a GC >> cycle never becomes reachable again. If you build with checking >> enabled, it's easy enough to get a crash if font_style_to_value ever >> modifies font_style_table, but I don't know for which font backends it >> ever does that by itself: doing it in GDB triggers the bug just as I >> described, though). > > I think there's a misunderstanding here. Can you please walk me > through the code below: > > Lisp_Object table =3D AREF (font_style_table, prop - FONT_WEIGHT_INDEX)= ; At this point, table, AREF (font_style_table, 0), and Vfont_weight_table all refer to the same Lisp object T. > elt =3D make_vector (2, make_fixnum (100)); > ASET (elt, 1, val); elt is a new Lisp object. > ASET (font_style_table, prop - FONT_WEIGHT_INDEX, > =09 CALLN (Fvconcat, table, make_vector (1, elt))); 1. make_vector creates a temporary one-element vector 2. vconcat creates a new Lisp object, T2 3. AREF (font_style_table, 0) is changed to refer to T2 Vfont_weight_table still refers to T. > and tell what is the "old vector" here that you are talking about? The old vector is T. It is no longer visible to GC once the function terminates and table goes out of scope. It is still the value of Vfont_weight_table. > And if that old vector is reachable from font_style_table, why do you > say it is not marked, if mark_object_root_visitor marks its argument > recursively? mark_object_root_visitor is never called for Vfont_weight_table because it is not staticpro'd. It is called for font_style_table, but font_style_table no longer refers to T; it refers to T2 only. >> >> That old vector can still be referenced from Lisp as >> >> font-weight-table (or one of the other two). That means an object is >> >> reachable from Lisp but not protected from GC. >> > >> > I don't understand: if it's reachable from Lisp, it must be protected >> > by definition, no? >> >> No, that's not correct. GC only protects global Lisp_Object variables >> if they're staticpro'd. A non-staticpro'd Lisp_Object variable must be >> protected in another way, or we have an unprotected reachable object. > > So you are saying that the problem that we don't assign the new value > (received from vconcat) to the appropriate variable > (Vfont_weight_table etc.)? My first patch assumes that behavior was intentional, and retains it; my second patch assumes it wasn't, and changes things so font_style_table is no longer needed, because we just use Vfont_weight_table directly in its place. We should not attempt to keep two different memory locations synchronized by trying to catch all modifications. That never works, and there's no reason for this complication. >> > GC can only free objects that are not reachable from any other object. >> >> No, that's not correct: the value of a forwarded symbol is not marked by >> alloc.c GC. >> >> =09 case SYMBOL_FORWARDED: >> =09=09/* If the value is forwarded to a buffer or keyboard field, >> =09=09 these are marked when we see the corresponding object. >> =09=09 And if it's forwarded to a C variable, either it's not >> =09=09 a Lisp_Object var, or it's staticpro'd already, or it's >> =09=09 reachable from font_style_table which is also >> =09=09 staticpro'd. */ >> =09=09break; >> >> That comment is incorrect, because font_style_table may contain a >> newly-consed vector, not the one that's still referred to as >> font-weight-table. > > Sorry, you lost me here. As I've tried to explain a number of times, the problem is that AREF (font_style_table, 0) isn't necessarily equal to Vfont_weight_table. The comment claims it is, but that's incorrect. Pip From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 13 14:35:18 2025 Received: (at 75521) by debbugs.gnu.org; 13 Jan 2025 19:35:18 +0000 Received: from localhost ([127.0.0.1]:52910 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXQDV-00078r-NK for submit@debbugs.gnu.org; Mon, 13 Jan 2025 14:35:18 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:52650) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tXQDS-000748-QU for 75521@debbugs.gnu.org; Mon, 13 Jan 2025 14:35:16 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tXQDN-0005Iv-BR; Mon, 13 Jan 2025 14:35:09 -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=ilQdwsnHaL/kt3UMOrdSXkJXtnVY+iF16yGjlfST9a4=; b=Lh7Ewu5pC3Mi VJq2gGsIhqBbGCixBY93YgKPkD4quDsBdnVDLWJZiQb4MMCsp6gXpSZyl1kV9D7TywjlFL1sueUB1 KZpCA7y2gVAuMctAwM19L5J0L0O8gnjbr0rzipvCZZzNXJqBgwKMmxS756xIFee9Vrfwy6iEW+OWn ctWENrSoX2kfZ8YLOaZEuxxOSFdiJZs+nspi57nzHE/wCtCrF6djqNc23X0QnLdGX7zqIUBVBG1lH O2Sqlr/omynrHI0foEzLK/ZxSseeSMtSyaWfMHi6kKogvSIAvwYlsIfjIGaFFDDYZl5HDj46IUgAm +KB/nghfyM19eIdA1wBS0Q==; Date: Mon, 13 Jan 2025 21:35:04 +0200 Message-Id: <864j22v76f.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <87ldveseso.fsf@protonmail.com> (message from Pip Cet on Mon, 13 Jan 2025 19:18:59 +0000) Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX References: <87ed16u7dw.fsf@protonmail.com> <86jzayvf7n.fsf@gnu.org> <875xmiu0ex.fsf@protonmail.com> <86ed16vdlm.fsf@gnu.org> <871px6tyx2.fsf@protonmail.com> <86a5buvcps.fsf@gnu.org> <87wmeyshh3.fsf@protonmail.com> <867c6yv910.fsf@gnu.org> <87ldveseso.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75521 Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Mon, 13 Jan 2025 19:18:59 +0000 > From: Pip Cet > Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com > > "Eli Zaretskii" writes: > > > So you are saying that the problem that we don't assign the new value > > (received from vconcat) to the appropriate variable > > (Vfont_weight_table etc.)? > > My first patch assumes that behavior was intentional, and retains it; my > second patch assumes it wasn't, and changes things so font_style_table > is no longer needed, because we just use Vfont_weight_table directly in > its place. If we remove font_style_table, then all the code in font.c which uses that table and accesses Vfont_weight_table etc. by indexing into font_style_table, will stop working, no? So I think I'd prefer to just assign the new value of the table, as returned by vconcat, to the corresponding variable (Vfont_weight_table etc.), and leave the rest of the code intact. That sounds like a much smaller change which only touches a single place, where the problem is. Are there any problems with this? > We should not attempt to keep two different memory locations > synchronized by trying to catch all modifications. That never works, > and there's no reason for this complication. I don't think I follow: which modifications are you talking about? If that's Vfont_weight_table etc., then these 3 are documented to be unmodifiable directly. > >> > GC can only free objects that are not reachable from any other object. > >> > >> No, that's not correct: the value of a forwarded symbol is not marked by > >> alloc.c GC. > >> > >> case SYMBOL_FORWARDED: > >> /* If the value is forwarded to a buffer or keyboard field, > >> these are marked when we see the corresponding object. > >> And if it's forwarded to a C variable, either it's not > >> a Lisp_Object var, or it's staticpro'd already, or it's > >> reachable from font_style_table which is also > >> staticpro'd. */ > >> break; > >> > >> That comment is incorrect, because font_style_table may contain a > >> newly-consed vector, not the one that's still referred to as > >> font-weight-table. > > > > Sorry, you lost me here. > > As I've tried to explain a number of times, the problem is that AREF > (font_style_table, 0) isn't necessarily equal to Vfont_weight_table. > The comment claims it is, but that's incorrect. Ah, so it's a separate issue with that comment. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 13 14:37:52 2025 Received: (at 75521) by debbugs.gnu.org; 13 Jan 2025 19:37:52 +0000 Received: from localhost ([127.0.0.1]:52916 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXQFz-0007Dh-L0 for submit@debbugs.gnu.org; Mon, 13 Jan 2025 14:37:51 -0500 Received: from mail-4322.protonmail.ch ([185.70.43.22]:40455) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tXQFw-0007DP-Rv for 75521@debbugs.gnu.org; Mon, 13 Jan 2025 14:37:50 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1736797062; x=1737056262; bh=n6eWVOxf0BhPkB/ZgRcCzKdTxI9UxJ7p5Yc+JkQyHMY=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=Glk5F47eQYleeL5dYFCaaDnu/2fb/id5exyOM7mnxlQwjEErgKzCExediOQFOSG16 z7tMLM10IRCOhD05dgRo/muqEErf6uX/VabD2ovO/1WTY+UB09uZK5j5qalChuq+mI V3NpV7qrfiB76RZWca90h5kaZA0WDRw68Hs5HZUDVq+IVrA2B0WZWwC9EgkOwyYE1m b85He3Z5YrWr5fvlT6oSGUAftCU848otlXReryj0ViGNmP0bL/GKbe7DIUaI+jcpGQ 2nyTJDuLdmTBKIzWxTYB1vI54uQKXrd0uXyJI4syEnEYQgVd5vZ2RYJ3u9/HZToj4K FbWYIY1yorykA== Date: Mon, 13 Jan 2025 19:37:37 +0000 To: Stefan Kangas From: Pip Cet Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX Message-ID: <87h662sdxj.fsf@protonmail.com> In-Reply-To: References: <87r057tzjg.fsf@protonmail.com> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: a4cf430d3fbf8a9ec7e1d4a18b2b07c46997a613 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75521 Cc: 75521@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) "Stefan Kangas" writes: > Pip Cet writes: > >> Patch: > > Thanks! Your patch seems to make things both safer and simpler. That's the first patch, right? If Eli wants to keep never-used Lisp APIs stable and prefers a minimal change, we should do that, but we should also fix the comment in alloc.c: diff --git a/src/alloc.c b/src/alloc.c index 8307c74c106..6a72e8aa087 100644 --- a/src/alloc.c +++ b/src/alloc.c @@ -7405,9 +7405,7 @@ #define CHECK_ALLOCATED_AND_LIVE_SYMBOL()=09=09((void= ) 0) =09=09/* If the value is forwarded to a buffer or keyboard field, =09=09 these are marked when we see the corresponding object. =09=09 And if it's forwarded to a C variable, either it's not -=09=09 a Lisp_Object var, or it's staticpro'd already, or it's -=09=09 reachable from font_style_table which is also -=09=09 staticpro'd. */ +=09=09 a Lisp_Object var or it's staticpro'd already. */ =09=09break; =09 default: emacs_abort (); =09 } > I'm curious why this was considered worth optimizing in the first place. So am I. It seems particularly strange to me that this was considered an optimization at all: make-docfile.c could simply have moved all global variables into a contiguous section, and then we wouldn't need to staticpro them individually. Also irrelevant on today's machines, of course. (staticpro is a bit strange for another reason: are you supposed to call it while the variable is uninitialized? If the initialization expression calls Lisp, that might GC, and GC shouldn't see uninitialized values. But if you call it after initializing the variable, you're putting data into unprotected memory, which is also something that should raise an alarm. Right now, both approaches are okay and in use, but that's inconsistent. That's why I proposed changing staticpro to have two arguments quite a while back.) Pip From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 13 14:57:33 2025 Received: (at 75521) by debbugs.gnu.org; 13 Jan 2025 19:57:33 +0000 Received: from localhost ([127.0.0.1]:52938 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXQZ2-00085p-Jp for submit@debbugs.gnu.org; Mon, 13 Jan 2025 14:57:33 -0500 Received: from mail-10631.protonmail.ch ([79.135.106.31]:40167) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tXQYz-00085Y-La for 75521@debbugs.gnu.org; Mon, 13 Jan 2025 14:57:30 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1736798242; x=1737057442; bh=Q83ulgCPwZ9NstbYNUV4ZfvVGQwbRs8Wk1q6UAS2jBg=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=apQzeyLCFOQxrU5Dpd8hMq6SBQyCmIwq+yQs1Nt2juIVE1J6z9H7IcSsFK97c7ZJ0 +LMp/F9vCFbPPmA515lc+fe8BPrMs/G5P8kNuyKSJov1hUwQhTCovrRpK4g+saPX9T enBW2hxqAgFMOnMiiBgQ60XOM8E7Y9pshC+e5BoZ8DPyVAS7Um1SrH2NoGK1+f00QV +IRnbky8EOTPcc0aa23WSVTehOjefYiVm1SFAqGwPSYqMjIrqQuYjTYmgk9TlYcYzm ngsR4nG4TwnAzb9sk9fiIsnxxHgZXuu67K/fyrNVarqlvnsHU+AreZsmahUWaj+U8i k3brv28tQnUig== Date: Mon, 13 Jan 2025 19:57:17 +0000 To: Eli Zaretskii From: Pip Cet Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX Message-ID: <87cygqsd0q.fsf@protonmail.com> In-Reply-To: <864j22v76f.fsf@gnu.org> References: <875xmiu0ex.fsf@protonmail.com> <86ed16vdlm.fsf@gnu.org> <871px6tyx2.fsf@protonmail.com> <86a5buvcps.fsf@gnu.org> <87wmeyshh3.fsf@protonmail.com> <867c6yv910.fsf@gnu.org> <87ldveseso.fsf@protonmail.com> <864j22v76f.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 4193de709d9fa0b520696e2a93ab77ffcceeca12 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 75521 Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) "Eli Zaretskii" writes: >> Date: Mon, 13 Jan 2025 19:18:59 +0000 >> From: Pip Cet >> Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com >> >> "Eli Zaretskii" writes: >> >> > So you are saying that the problem that we don't assign the new value >> > (received from vconcat) to the appropriate variable >> > (Vfont_weight_table etc.)? >> >> My first patch assumes that behavior was intentional, and retains it; my >> second patch assumes it wasn't, and changes things so font_style_table >> is no longer needed, because we just use Vfont_weight_table directly in >> its place. > > If we remove font_style_table, then all the code in font.c which uses > that table and accesses Vfont_weight_table etc. by indexing into > font_style_table, will stop working, no? See my second patch, it's not a huge change. > So I think I'd prefer to > just assign the new value of the table, as returned by vconcat, to the > corresponding variable (Vfont_weight_table etc.), and leave the rest > of the code intact. That sounds like a much smaller change which only > touches a single place, where the problem is. Are there any problems > with this? Yes, of course there are. It's a very fragile approach, as evidenced by the fact that it was broken for so long, and there's absolutely no benefit to it. The next person to attempt to change this code won't understand why we use a non-staticpro'd variable which is kept in sync with a staticpro'd one (because there is no reason to do so), and probably break things again. >> We should not attempt to keep two different memory locations >> synchronized by trying to catch all modifications. That never works, >> and there's no reason for this complication. > > I don't think I follow: which modifications are you talking about? If > that's Vfont_weight_table etc., then these 3 are documented to be > unmodifiable directly. You mean the comment starting with "FIXME"? I thought it'd be good to fix that. (It's also inaccurate, because the problematic workaround it describes does not, actually, work). The vectors, of course, can be modified, and that will have very strange and unexpected results. >> >> > GC can only free objects that are not reachable from any other obje= ct. >> >> >> >> No, that's not correct: the value of a forwarded symbol is not marked= by >> >> alloc.c GC. >> >> >> >> =09 case SYMBOL_FORWARDED: >> >> =09=09/* If the value is forwarded to a buffer or keyboard field, >> >> =09=09 these are marked when we see the corresponding object. >> >> =09=09 And if it's forwarded to a C variable, either it's not >> >> =09=09 a Lisp_Object var, or it's staticpro'd already, or it's >> >> =09=09 reachable from font_style_table which is also >> >> =09=09 staticpro'd. */ >> >> =09=09break; >> >> >> >> That comment is incorrect, because font_style_table may contain a >> >> newly-consed vector, not the one that's still referred to as >> >> font-weight-table. >> > >> > Sorry, you lost me here. >> >> As I've tried to explain a number of times, the problem is that AREF >> (font_style_table, 0) isn't necessarily equal to Vfont_weight_table. >> The comment claims it is, but that's incorrect. > > Ah, so it's a separate issue with that comment. No, it's not! The comment is about the very same issue we've been "discussing" for so long. We tried avoiding a staticpro, it failed to work, the right thing to do is to add the staticpro rather than complicating a fragile workaround further so it will work for a brief period until the next change breaks it again. Pip From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 13 15:01:35 2025 Received: (at 75521) by debbugs.gnu.org; 13 Jan 2025 20:01:35 +0000 Received: from localhost ([127.0.0.1]:52945 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXQcw-0008JS-UD for submit@debbugs.gnu.org; Mon, 13 Jan 2025 15:01:35 -0500 Received: from mail-ed1-x52f.google.com ([2a00:1450:4864:20::52f]:60891) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tXQct-0008JB-5d for 75521@debbugs.gnu.org; Mon, 13 Jan 2025 15:01:32 -0500 Received: by mail-ed1-x52f.google.com with SMTP id 4fb4d7f45d1cf-5d90a5581fcso7958080a12.1 for <75521@debbugs.gnu.org>; Mon, 13 Jan 2025 12:01:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736798485; x=1737403285; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=+EyByX9f4bGQpF7feC6huV1zJSTf1/mebkT8nYMX5iI=; b=ePydGy2ifD+il5lAicRcDqeYwcUKyPnDKEUHlzAr+OpwyunMEKpqmeYw6/lYUvRjCX +XRVRJpySbcd3Vw7LZ69JiDGRVeMAMcmc6MxtqoFyxSb+xAH+Q1oPLrhBpGVvgGtoqs2 vKZLeO92WVJ3NU2iZXLyW9pNfbIHoOU9WxT+OjFca+3RcK6ARmBW5ZcRCmKfJkOQFQkk 4SpOk+CBgFnne1x0v9mGwKcEb/fwrp2/xfBQ2OPXXwU7dYoSs9/gWI8ytcnCU14+QAN9 4bNeTepZw3tvuxz5qro9ZWJabxWQQFBWQwc/+JfoOxdZ2MpcnJhC/dwKePScDXZ+GCBR pV2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736798485; x=1737403285; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=+EyByX9f4bGQpF7feC6huV1zJSTf1/mebkT8nYMX5iI=; b=THPynO5kgtXY9pM26+IvWEr8rnbU2zZiSoCGuvbGRNwWegRKR875YEXVvpZ9ZEnR1O 1dtYxn5q1d/Ogbm1WQsa9nXeBqUuZkFC3o+UtbcErhjEBPi5xGOcK7OFfxqp3V67U5iu HEWap08T5/UJPckgoo569MmjTeSLvibM/vmP0xPACU9RqC/GNlE/IbTgbYRAY1cqv4iL 7Fe/aVVyQShMhvpMymAYzoVmVmiBMozoB1WiCbJF6hZ/o0gJHDQJJeq/SABBVvKAJp7V OYU0UFnCSYXTRdLj/xyRPHd0NZVql5FJeg2xKqkVvAgXKa3bDocvcF+USCWSd90bDlmh 1U9g== X-Forwarded-Encrypted: i=1; AJvYcCXaTN3jn+clkQyCdDyztzH+JJ2X39Eh+x5N839IWsOVBrQCkNask6bADAm0dRa4hmEn/V9EJw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwCwPTGcW3fA5A8WmzL0K3s1DqMvEAk9sZlX/an0BygGSL4EFI/ WiWxPGZmmS2HvXaFICLm4LNXc4lKU9VjRlRlNLilupBE6krXd+/FiZ/vB6sjl4H/XvWQtkGdfEK 5V3j59fTD3ZkiI639/Zv6dpaWhlk= X-Gm-Gg: ASbGnctOb4Hu3T2owvlSzJZgfyAFS6ow8FJE1zrFSQbsEENgf5617JCQyvEPDFZMT26 ArjPHJFRx6Nx01XC8HbeqpFkKXkDoq8kpId1k9Xk0 X-Google-Smtp-Source: AGHT+IELNQ3tiuJxzI1GKjsAUpNbFkXj4cZFHYEmamuU88q5wmmqdv5DkZs91iTinQZgUcX3S623X1p6h1TggefcP2w= X-Received: by 2002:a05:6402:3550:b0:5d9:8877:895a with SMTP id 4fb4d7f45d1cf-5d988778a53mr17691319a12.17.1736798484768; Mon, 13 Jan 2025 12:01:24 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Mon, 13 Jan 2025 20:01:24 +0000 From: Stefan Kangas In-Reply-To: <865xmiv81s.fsf@gnu.org> References: <87r057tzjg.fsf@protonmail.com> <865xmiv81s.fsf@gnu.org> MIME-Version: 1.0 Date: Mon, 13 Jan 2025 20:01:24 +0000 X-Gm-Features: AbW1kvZKJ_tYieuoFPsplvwjz3aGO-zaI7u0OflQCzjvNd4336bmFSJhNXpnpfs Message-ID: Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75521 Cc: 75521@debbugs.gnu.org, pipcet@protonmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> I'm curious why this was considered worth optimizing in the first place. > > What is the optimization here? DEFVAR_LISP_NOPRO or font_style_table? I was thinking of DEFVAR_LISP_NOPRO: https://lists.gnu.org/r/emacs-devel/2024-05/msg00896.html From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 13 15:07:31 2025 Received: (at 75521) by debbugs.gnu.org; 13 Jan 2025 20:07:31 +0000 Received: from localhost ([127.0.0.1]:52953 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXQih-00006e-5O for submit@debbugs.gnu.org; Mon, 13 Jan 2025 15:07:31 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:40110) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tXQie-00006P-4d for 75521@debbugs.gnu.org; Mon, 13 Jan 2025 15:07:29 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tXQiY-0000kQ-Nn; Mon, 13 Jan 2025 15:07:22 -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=3uVYai54cZTJJl2x5xydo1TAL//m6YSFe2p9qMMFSJg=; b=PT5UqLlM56zs BMSmpgXyLuMUgECYPOfvqDZG+szXQKIjMlsiIG6ZOsMKv/ilQ1fof7K172d52CnbXwqlcVXOrXuWp u092j1L3ci1Iu0Gdj9uIvikBjh6eIqhFrBrjabJwHBp2y9pwh4VNOJui4zcQjxE+Dk2EhPd++Lwmr OfiGl8/aGQRsYVpleEQ3DJsBuhxW/wPxqIz5oJYIgisrMmMlFhtx6EtiI7AOK5319d7/R+Y3hGp13 4hmQ9S0+kPM0hNWnsh8W3fIEwtY71/+M0xUzmPk0ih6G1DgMJyvdnillG17LP1PWhAr/1r/foCqgT dSSuacO1IQOuyOgRpUQ5Dg==; Date: Mon, 13 Jan 2025 22:07:21 +0200 Message-Id: <861px6v5om.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <87cygqsd0q.fsf@protonmail.com> (message from Pip Cet on Mon, 13 Jan 2025 19:57:17 +0000) Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX References: <875xmiu0ex.fsf@protonmail.com> <86ed16vdlm.fsf@gnu.org> <871px6tyx2.fsf@protonmail.com> <86a5buvcps.fsf@gnu.org> <87wmeyshh3.fsf@protonmail.com> <867c6yv910.fsf@gnu.org> <87ldveseso.fsf@protonmail.com> <864j22v76f.fsf@gnu.org> <87cygqsd0q.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75521 Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Mon, 13 Jan 2025 19:57:17 +0000 > From: Pip Cet > Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com > > "Eli Zaretskii" writes: > > >> We should not attempt to keep two different memory locations > >> synchronized by trying to catch all modifications. That never works, > >> and there's no reason for this complication. > > > > I don't think I follow: which modifications are you talking about? If > > that's Vfont_weight_table etc., then these 3 are documented to be > > unmodifiable directly. > > You mean the comment starting with "FIXME"? No, I mean this part of the doc string: This variable cannot be set; trying to do so will signal an error. What two different memory locations did you have in mind above? > >> As I've tried to explain a number of times, the problem is that AREF > >> (font_style_table, 0) isn't necessarily equal to Vfont_weight_table. > >> The comment claims it is, but that's incorrect. > > > > Ah, so it's a separate issue with that comment. > > No, it's not! The comment is about the very same issue we've been > "discussing" for so long. The main issue is the code, not the comment. So fixing the comment is a separate issue. Anyway, please don't install anything yet. I want to take a closer look at this code and its usage, and I've ran out of time for today. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 13 15:11:09 2025 Received: (at 75521) by debbugs.gnu.org; 13 Jan 2025 20:11:09 +0000 Received: from localhost ([127.0.0.1]:52961 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXQmD-0000IX-C9 for submit@debbugs.gnu.org; Mon, 13 Jan 2025 15:11:09 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:35328) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tXQmB-0000I6-Eb for 75521@debbugs.gnu.org; Mon, 13 Jan 2025 15:11:07 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tXQm6-00019q-1e; Mon, 13 Jan 2025 15:11:02 -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=q5ErzL6HfRRxhSBIqaTTSWkr/0YdZo+NhIta5k5G3No=; b=nXMF2+KCe/9F rono5KmgVphHVy+6eJ57LHWzRMdD4KqQCeWffxxAWxti2pUUwGQzy/nNwc90SYLhpB0/Rwm5qn1Vs 25Rzs6+umLP6tNTPp8Pujikd4MLczRspwvfy8R6Ost37nWeLs68vo93zJxl2kf1eAUMWTQIoZte7N Jl3ObJjo5dcDbAwlYTjatwrdwM139cr7KUjrIj50syP1xbP1CoS+oY2e75lUbISFtuTeJeo2maoXx wni9QuzfsyqD+vsSWQW4oYkRl8EAJi+pNgWYuq+ET/lo8VuOQyewnFGB91QfKlvAXKBBaamN4OGkp ZiUPQadcjM9GvF0pPijdOA==; Date: Mon, 13 Jan 2025 22:11:00 +0200 Message-Id: <86zfjutqy3.fsf@gnu.org> From: Eli Zaretskii To: Stefan Kangas In-Reply-To: (message from Stefan Kangas on Mon, 13 Jan 2025 20:01:24 +0000) Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX References: <87r057tzjg.fsf@protonmail.com> <865xmiv81s.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75521 Cc: 75521@debbugs.gnu.org, pipcet@protonmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Kangas > Date: Mon, 13 Jan 2025 20:01:24 +0000 > Cc: pipcet@protonmail.com, 75521@debbugs.gnu.org > > Eli Zaretskii writes: > > >> I'm curious why this was considered worth optimizing in the first place. > > > > What is the optimization here? DEFVAR_LISP_NOPRO or font_style_table? > > I was thinking of DEFVAR_LISP_NOPRO: AFAIU, it's there to avoid protecting something that is already protected. staticvec[] is a static vector, so wasting slots there is best avoided. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 13 15:38:47 2025 Received: (at 75521) by debbugs.gnu.org; 13 Jan 2025 20:38:47 +0000 Received: from localhost ([127.0.0.1]:52991 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXRCw-0001TG-Pl for submit@debbugs.gnu.org; Mon, 13 Jan 2025 15:38:47 -0500 Received: from mail-40134.protonmail.ch ([185.70.40.134]:50199) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tXRCt-0001Sz-KD for 75521@debbugs.gnu.org; Mon, 13 Jan 2025 15:38:44 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1736800717; x=1737059917; bh=GEmah6edp5wX1gYmrvB7G6w5TsvgGx22IuJj73XOM9g=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=GLInzjFzRK1NUn2Hn65v1/05OOa0p2W0gQfrbyF79QDQSRdGL1ybX0f+hSx2uGyTU MReHKsAUEyfELdhp6OEO83NJ0iZuNyVbvaOkI4SSr4S6d0poYDwwKD9tCjm5ogIFSF 8rV5NhE4Aaag0FLDmHB+sY8wRJSHMGLQWrwzkzITBsHs5bN+1OoQDhYypsGaSxO4bq v4W+DM/4JQf3aTmdih0B9tQD1IRmZdDhWsqXXCWkYC+MIg1SmCRdm1VgNa5z3iy0AL etKrxy7lYV4qJyJqGLucCv3kmQASE9jWUUqqdGcU4jnTwh6zUee89k1yNzHGPIlBDh G6CInbYotjqJw== Date: Mon, 13 Jan 2025 20:38:34 +0000 To: Eli Zaretskii From: Pip Cet Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX Message-ID: <8734hmsb41.fsf@protonmail.com> In-Reply-To: <861px6v5om.fsf@gnu.org> References: <871px6tyx2.fsf@protonmail.com> <86a5buvcps.fsf@gnu.org> <87wmeyshh3.fsf@protonmail.com> <867c6yv910.fsf@gnu.org> <87ldveseso.fsf@protonmail.com> <864j22v76f.fsf@gnu.org> <87cygqsd0q.fsf@protonmail.com> <861px6v5om.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: fd001e63f87845d60cb7ebffaaacaf1348b048a2 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75521 Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) "Eli Zaretskii" writes: > Anyway, please don't install anything yet. I want to take a closer > look at this code and its usage, and I've ran out of time for today. Okay. It's probably best to take a break from this issue, anyway. Pip From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 13 16:09:12 2025 Received: (at 75521) by debbugs.gnu.org; 13 Jan 2025 21:09:13 +0000 Received: from localhost ([127.0.0.1]:53052 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXRgO-0005uJ-JN for submit@debbugs.gnu.org; Mon, 13 Jan 2025 16:09:12 -0500 Received: from mail-ej1-x62d.google.com ([2a00:1450:4864:20::62d]:42461) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tXRgL-0005tc-Ah for 75521@debbugs.gnu.org; Mon, 13 Jan 2025 16:09:10 -0500 Received: by mail-ej1-x62d.google.com with SMTP id a640c23a62f3a-ab2e308a99bso49519966b.1 for <75521@debbugs.gnu.org>; Mon, 13 Jan 2025 13:09:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736802543; x=1737407343; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=B28xiopNsZJvYDvxKVOKr6BCwpBCvWOzUSDzNdRlyjY=; b=QtroiVvqYHI68JeuAOq8K48ZXGaCrVsDi5WsodIyc9B8ie+3HOrr9Oi16Rg7Qkis36 ltCYmneciXOI/jCDLblOZAg+xjOOw1sF+kzd9gc/oIMwNhz8MREVtu687IWkMEjNge8S 1VnaI2rtffANockC1UP2oTO+Uz2sHTSeHRmBpDDiMpvjDw9L8aZ7zsIZndSA+AllBfDE U3JtUWeZjYatj7D7zp+b6q3+SaoVgUXjpuh/rVjKI7kJZKbelvRtwC69MceQ3WZmNNjE SCKzlcOeiCETvTK4eadQbAseEWQ6z46WOORSCLQQJfZhDfKA8lr6xtdWnhEHvwUzPGE8 DbzA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736802543; x=1737407343; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=B28xiopNsZJvYDvxKVOKr6BCwpBCvWOzUSDzNdRlyjY=; b=PzrYYo9TVQa/2MWoGns49ZHgflX1Pxuvmmfp489xXBlZUr06DS3vpJZoa69DrTv4Ua 6fYSeKu6Nmt6Z+kQQ6G3p6CYhI9N2K3QlcNpKRomVnl0xezEb/siZ52fF29My4kyQxWr L/QwzHf+WOPgPyE93jUGOhXSartj8B5i4y+FvkAGH10ufRaXig3Zjz/4EIR8b00KwFCz tMtMFmxni+cVvI1F2ZmgQ33MTuvT2l9apms9TWEFfXodpKmRnonA6rSdsFnrL4E37Vl8 hxqwKP5e3qsHlggV3VHrLAoGiSd92luUhniQ5vAN2V9cFcJyVmF9HTfVB673YNT8TAfE uG2w== X-Forwarded-Encrypted: i=1; AJvYcCVtMbRMw/NXlqCYuwy6Rkzap0kKIyaEMrAqR7hvHawrIKYPBGqPlEd6kuiCvn9nFV2Iga2rWw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyLVXqUSv8vXYTFUIr7+ba8ubOgnlqnW51mUAFw0BcjShp/eVOl I06M+6ARNsNW4N2SSGj1lNCBNqlKhPj9MgKG6CPhkPAurm27Ojm/GwrH73DkbvF0DR9kWsW3XXv Tszd9RzXmqdaXLv/XRc4cTDhseKM= X-Gm-Gg: ASbGncvvyNIbHXv+lKHL92N+bxrwTnaxaBQmeaypG5+9pUhx/yZGXU45lbVWv9yit6/ aTBqQDwdAYIo3MQyvRh5AvrnCZb5CaRZ/Vd41n0au X-Google-Smtp-Source: AGHT+IF+H4QCWBBVizpgMDFv4vjm8tWV81COzq5xA7LxqQAY5qaEmN/pO+y1GA96eQ5S0WDGsOt6UdwU9J4u9Tw8M7E= X-Received: by 2002:a17:907:a088:b0:ab2:bd80:4519 with SMTP id a640c23a62f3a-ab2c3c79997mr1726087966b.16.1736802543028; Mon, 13 Jan 2025 13:09:03 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Mon, 13 Jan 2025 21:09:02 +0000 From: Stefan Kangas In-Reply-To: <86zfjutqy3.fsf@gnu.org> References: <87r057tzjg.fsf@protonmail.com> <865xmiv81s.fsf@gnu.org> <86zfjutqy3.fsf@gnu.org> MIME-Version: 1.0 Date: Mon, 13 Jan 2025 21:09:02 +0000 X-Gm-Features: AbW1kvay09U1n6CuWQay1nCBJQQdaQNCiBETYmcdX2NokYxmyetE5koPJvEnklA Message-ID: Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 75521 Cc: 75521@debbugs.gnu.org, pipcet@protonmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Stefan Kangas >> Date: Mon, 13 Jan 2025 20:01:24 +0000 >> Cc: pipcet@protonmail.com, 75521@debbugs.gnu.org >> >> Eli Zaretskii writes: >> >> >> I'm curious why this was considered worth optimizing in the first place. >> > >> > What is the optimization here? DEFVAR_LISP_NOPRO or font_style_table? >> >> I was thinking of DEFVAR_LISP_NOPRO: > > AFAIU, it's there to avoid protecting something that is already > protected. staticvec[] is a static vector, so wasting slots there is > best avoided. Yes, indeed, but that seems like an optimization that is not worth doing. Not these days, at any rate. It complicates the code, leading to confusion (case in point: this long thread where many cycles were spent discussing it), and the performance gains are not likely to even be measurable. Note that with MPS, DEFVAR_LISP and DEFVAR_LISP_NOPRO are equivalent. So by getting rid of DEFVAR_LISP_NOPRO, we would reduce the delta between igc and master as a nice bonus. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 13 22:30:12 2025 Received: (at 75521) by debbugs.gnu.org; 14 Jan 2025 03:30:12 +0000 Received: from localhost ([127.0.0.1]:53497 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXXd6-0006e9-Bw for submit@debbugs.gnu.org; Mon, 13 Jan 2025 22:30:12 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:35384) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tXXd4-0006Z8-59 for 75521@debbugs.gnu.org; Mon, 13 Jan 2025 22:30:10 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tXXcy-0001Ho-Na; Mon, 13 Jan 2025 22:30:04 -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=nkgWIrcynd5DNeD8qdIR5PfKaBnDpP71ZG/r2GY24Sk=; b=rRcF5YjSiRrF KOiR32fYgnq0elV6h7gfL7tExZQAAPNuaMMgyBEB5NPUhsbXHGXTSnqgn09m2ErVpy8bJiro+Rzot +RSUTuR6ci6IV4m3gTgxSExxKI0zlMCUfNkPs3mFZmnRVfy7egonUiZcq9cT51nsNAvqsAbViYkgZ u299+B2R+uVmeC4HPkDqd4Br2fl4TfChYNSTWwQ+cdVgtjKwiZSXu0QmoYOJS4CPPB/RhzG6qfIPx nMQMB1GhOu5VXjao+EmNqdU2ZERoZOtvNUkRmG6UG7UZdZSE6Gm3lCBz3bk69epQRYiJyJYrVc6/1 pEjcsv+zFNUvQU3nBBVfGQ==; Date: Tue, 14 Jan 2025 05:30:02 +0200 Message-Id: <86y0zet6md.fsf@gnu.org> From: Eli Zaretskii To: Stefan Kangas In-Reply-To: (message from Stefan Kangas on Mon, 13 Jan 2025 21:09:02 +0000) Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX References: <87r057tzjg.fsf@protonmail.com> <865xmiv81s.fsf@gnu.org> <86zfjutqy3.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75521 Cc: 75521@debbugs.gnu.org, pipcet@protonmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Kangas > Date: Mon, 13 Jan 2025 21:09:02 +0000 > Cc: pipcet@protonmail.com, 75521@debbugs.gnu.org > > Eli Zaretskii writes: > > >> From: Stefan Kangas > >> Date: Mon, 13 Jan 2025 20:01:24 +0000 > >> Cc: pipcet@protonmail.com, 75521@debbugs.gnu.org > >> > >> Eli Zaretskii writes: > >> > >> >> I'm curious why this was considered worth optimizing in the first place. > >> > > >> > What is the optimization here? DEFVAR_LISP_NOPRO or font_style_table? > >> > >> I was thinking of DEFVAR_LISP_NOPRO: > > > > AFAIU, it's there to avoid protecting something that is already > > protected. staticvec[] is a static vector, so wasting slots there is > > best avoided. > > Yes, indeed, but that seems like an optimization that is not worth > doing. Not these days, at any rate. If you try to staticpro too many variables, the build will fail because Emacs runs out of space in staticvec. Not everyone knows what to do in this case, and it's an annoyance when this happens. So I would not say so easily that it's an optimization not worth doing, no. > It complicates the code, leading to confusion (case in point: this long > thread where many cycles were spent discussing it), and the performance > gains are not likely to even be measurable. That's normal in Emacs. Some stuff is complex, and given enough comments can be dealt with without too many problems. And this thread is in a way a self-inflicted shoot-in-the-foot problem: we could have left the code alone, as it works for us for decades without any visible problems. > Note that with MPS, DEFVAR_LISP and DEFVAR_LISP_NOPRO are equivalent. When the igc branch lands, this will be a non-issue, yes. One more reason not to waste too much effort on this code now. But since the genie is out of the bottle, we must. > So by getting rid of DEFVAR_LISP_NOPRO, we would reduce the delta > between igc and master as a nice bonus. Why do we need to reduce the delta? what does that get us? From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 14 00:07:14 2025 Received: (at 75521) by debbugs.gnu.org; 14 Jan 2025 05:07:14 +0000 Received: from localhost ([127.0.0.1]:53593 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXZ90-0002UG-5k for submit@debbugs.gnu.org; Tue, 14 Jan 2025 00:07:14 -0500 Received: from mail-wr1-x430.google.com ([2a00:1450:4864:20::430]:47348) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tXZ8y-0002U1-2E for 75521@debbugs.gnu.org; Tue, 14 Jan 2025 00:07:12 -0500 Received: by mail-wr1-x430.google.com with SMTP id ffacd0b85a97d-385e27c75f4so3545818f8f.2 for <75521@debbugs.gnu.org>; Mon, 13 Jan 2025 21:07:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736831226; x=1737436026; darn=debbugs.gnu.org; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:from:to:cc:subject:date:message-id:reply-to; bh=/2at8rRgUk4SQyXC9SVeKIAMkXmrCJdphe5v8/nGZNs=; b=O4QKeQmWGuEx57ZBYrG+ngsjFtJiDcCbCkjCT0TGsTNZ9F2qXB3vwfFKEFLVdHjZGR Vgn/MSZSkUX8JXZwNSWdPw2oI8g+MXeaScE/kRMVkPoi/sHONNtw4hscatLwLJfmPHu7 YEUcsBfH9g7ypKIq7RzQEAfrcRA0AExFlpW266qITNx1dNqP+9yCjvB76RquCJcDEHYk 53oEneUvlomWAqvXEfjsjyzoagoHe/+pDMYQvInY5j5RWyYUxokakgGKwiigtTM2t+sA WNLI1f34ITMpIRzfV8OzeLmsu/nxPiYWvTsGErvmEngKUd7TjkoVfvetAiDvOUl37AQU GIQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736831226; x=1737436026; h=mime-version:user-agent:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=/2at8rRgUk4SQyXC9SVeKIAMkXmrCJdphe5v8/nGZNs=; b=InhVxi4tuS9ZmS/Ai4OWzkGu6KxYCDCnTUMDRrGElmyS9wM+51fEhGRR+3qgI6DRvb WNVO/dHPrH5hgB8qUd747BhQmPnIEKL3DKqiW7kB/xy/YTH0jS4y/XWjx398Vz2F+JLG HrQeArG/OrG+7zDtcaV0j9WiBKqgjlwpSDYLRTs+oXV+ZKWiOCCzH5M87sH4t+mrB3Yw q4HDg2X+EmWu8wpypC0XTst5yL9BqadESef00NG/V6hsV9KTEwXZPX+5/FbWTzAy/8hW RpHC0gMJTsEheMFrdB3eeuEXBnOnoFstY6yBzm2xhg65KJII8FTinRJZECQIZ1TSy3so 6r7w== X-Forwarded-Encrypted: i=1; AJvYcCX1MQ1WIkPB2zvs5jMkv70rSZrgp9ZBXuy3J2z+/AP7bSSDA20JoziN7dahDH3/WkjgPC8M2g==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwgXEfonA1OtuonhSU9ijaGJlLsLqifhV7zue1j4YgFzN0XWgNh Be32SdZbWiVUqaqIoKZ4/R1Z9ZrYYllW3WChPjfrZJbCOnBnBYv5 X-Gm-Gg: ASbGnct7lyyvCaI1QOLzYsttyx9H9uq8WBSC/q8nxq9fuyIj7g5abUk9RIAuKECGhR+ BCTP/rBz9FIUYaMu9lCae6gZLATF0rDzpbI6mvpXL2hZ4ZTRvfByl6dxDQ2ZjXVtAAO8o+SGfXr g8hDevfDPSuufQgye0TMRAOM4USJe+UCEzcOCLnA/UO8pPrGyvbwN8JsKYS3xWfbeGGPq1S26VQ 9wWgZEaxFAl8PUrPqyyQDFMz73/x2cIgqoyMfAcRtJeOn3CuU0wfUxPrW0REsZ3ZzY1ZMIOgPIP NGf5rrqKrDaZTeABc+kHv5R4mDhrWDxdlmyEtf7w8Ulq1KzRcto09BBjxNzmDaxxLQ== X-Google-Smtp-Source: AGHT+IEdaayTzKrh+IRepoCoDiROrnTZ/r8KFfIVkHVPFetnmlFl2oCq6kCPqhdXyFL6QKRP/RWmMQ== X-Received: by 2002:a5d:5f8f:0:b0:38a:2b39:679d with SMTP id ffacd0b85a97d-38a87313e2cmr19181031f8f.32.1736831225690; Mon, 13 Jan 2025 21:07:05 -0800 (PST) Received: from pro2 (p200300e0b7253f00ad002432608bf091.dip0.t-ipconnect.de. [2003:e0:b725:3f00:ad00:2432:608b:f091]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-38a8e4b7f79sm14027206f8f.69.2025.01.13.21.07.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 13 Jan 2025 21:07:04 -0800 (PST) From: =?utf-8?Q?Gerd_M=C3=B6llmann?= To: Stefan Kangas Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX In-Reply-To: (Stefan Kangas's message of "Mon, 13 Jan 2025 21:09:02 +0000") References: <87r057tzjg.fsf@protonmail.com> <865xmiv81s.fsf@gnu.org> <86zfjutqy3.fsf@gnu.org> Date: Tue, 14 Jan 2025 06:07:02 +0100 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75521 Cc: 75521@debbugs.gnu.org, Eli Zaretskii , pipcet@protonmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stefan Kangas writes: >> AFAIU, it's there to avoid protecting something that is already >> protected. staticvec[] is a static vector, so wasting slots there is >> best avoided. > > Yes, indeed, but that seems like an optimization that is not worth > doing. Not these days, at any rate. > > It complicates the code, leading to confusion (case in point: this long > thread where many cycles were spent discussing it), and the performance > gains are not likely to even be measurable. +1000 From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 14 05:57:09 2025 Received: (at 75521) by debbugs.gnu.org; 14 Jan 2025 10:57:09 +0000 Received: from localhost ([127.0.0.1]:54020 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXebc-0004VA-Lz for submit@debbugs.gnu.org; Tue, 14 Jan 2025 05:57:09 -0500 Received: from mail-4322.protonmail.ch ([185.70.43.22]:32171) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tXebZ-0004UU-KW for 75521@debbugs.gnu.org; Tue, 14 Jan 2025 05:57:06 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1736852218; x=1737111418; bh=U+MD/tx5O1unMsOrZC2mmbntO9T1VYjk+/iHgPw2OWg=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=ddB+VDqqh3MTh6cv675hkTHCrOSk6JQHzF0e+WuCgb4EdZpb/7RR73Ye5B0FCkKBo LtkPsd/6yLFMbDh+f6Is1K1mfq8YeRLKrsvSFAx51S+06KAR3E1yuyMvTiJj7ZsSFA iFlyy3R9K1vTRgD3uZXoT06bdAXLGmWgvZfd5wPOilGntZRAyvICbOhcjg4+tY8RLM HYUmlwg08Y66JtfEULMjPu/+kydOvN+7nPNVweaONn3sVt5yfAG9tKngieSvNaPQn+ 8gWPj3GILyn8/rR/RE63YLDL8ARTwW/jWuarBsSld2XFKTXDnh2sf16+YZruUaJZ9q GkdEOiWloSdfA== Date: Tue, 14 Jan 2025 10:56:55 +0000 To: Eli Zaretskii From: Pip Cet Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX Message-ID: <87wmexr7df.fsf@protonmail.com> In-Reply-To: <86y0zet6md.fsf@gnu.org> References: <87r057tzjg.fsf@protonmail.com> <865xmiv81s.fsf@gnu.org> <86zfjutqy3.fsf@gnu.org> <86y0zet6md.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: a40d01a9db7a40bd0e4d877b99a8331189fed4f4 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.8 (-) X-Debbugs-Envelope-To: 75521 Cc: 75521@debbugs.gnu.org, Stefan Kangas X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.8 (--) "Eli Zaretskii" writes: >> From: Stefan Kangas >> Date: Mon, 13 Jan 2025 21:09:02 +0000 >> Cc: pipcet@protonmail.com, 75521@debbugs.gnu.org >> >> Eli Zaretskii writes: >> >> >> From: Stefan Kangas >> >> Date: Mon, 13 Jan 2025 20:01:24 +0000 >> >> Cc: pipcet@protonmail.com, 75521@debbugs.gnu.org >> >> >> >> Eli Zaretskii writes: >> >> >> >> >> I'm curious why this was considered worth optimizing in the first = place. >> >> > >> >> > What is the optimization here? DEFVAR_LISP_NOPRO or font_style_tabl= e? >> >> >> >> I was thinking of DEFVAR_LISP_NOPRO: >> > >> > AFAIU, it's there to avoid protecting something that is already >> > protected. staticvec[] is a static vector, so wasting slots there is >> > best avoided. >> >> Yes, indeed, but that seems like an optimization that is not worth >> doing. Not these days, at any rate. > > If you try to staticpro too many variables, the build will fail > because Emacs runs out of space in staticvec. Not everyone knows what > to do in this case, and it's an annoyance when this happens. So I > would not say so easily that it's an optimization not worth doing, no. Running out of NSTATICS is not and never has been a significant problem. If you want to change the error message (which seems quite clear, to me), feel free to, but saying that we shouldn't staticpro variables that need to be staticpro'd because we might have to bump NSTATICS is too ridiculous an argument to entertain. (On this system, NSTATICS is 2048, but there are only 304 explicit staticpro calls in the Emacs code base, plus 636 DEFVAR_LISP* calls. We're very, very far from the point where we need to consider bumping it.) >> It complicates the code, leading to confusion (case in point: this long >> thread where many cycles were spent discussing it), and the performance >> gains are not likely to even be measurable. > > That's normal in Emacs. Some stuff is complex, and given enough > comments can be dealt with without too many problems. > > And this thread is in a way a self-inflicted shoot-in-the-foot > problem: we could have left the code alone, as it works for us for > decades without any visible problems. Keeping unnecessary and broken complexity because "it works for us" (it doesn't work for anyone using the API; I assume people tried, failed, and gave up on Emacs) is not the right thing to do, no. What went wrong here is quite different: it's a simple problem, it was discovered and fixed, it took quite a while to get you to understand it, and then you immediately went into "oh, right, it's a bug, but let's not fix it" mode. It's a bug, there's a fix, it simplifies things significantly (lines starting with "DEF" are magic to make-docfile.c, so we should try to reduce the number of cases that imperfect parser has to handle). Describing someone's effort to improve Emacs as "shoot-in-the-foot" is quite offensive, BTW. >> Note that with MPS, DEFVAR_LISP and DEFVAR_LISP_NOPRO are equivalent. > > When the igc branch lands, this will be a non-issue, yes. One more ^^^^ That's still an "if", IMHO. > reason not to waste too much effort on this code now. But since the > genie is out of the bottle, we must. Saying that improving the Emacs code base is a waste of effort only makes sense if you think Emacs development will stop soon. Even then, it's also quite offensive. >> So by getting rid of DEFVAR_LISP_NOPRO, we would reduce the delta >> between igc and master as a nice bonus. > > Why do we need to reduce the delta? what does that get us? It turns the "if" into more of a "when". I'll stop here. Yet another simple improvement (and bug fix) to Emacs which was effectively vetoed. Pip From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 14 09:16:42 2025 Received: (at 75521) by debbugs.gnu.org; 14 Jan 2025 14:16:42 +0000 Received: from localhost ([127.0.0.1]:54288 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXhik-0002bE-Cv for submit@debbugs.gnu.org; Tue, 14 Jan 2025 09:16:42 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:48092) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tXhie-0002ar-Pv for 75521@debbugs.gnu.org; Tue, 14 Jan 2025 09:16:39 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tXhiX-0006ZG-3G; Tue, 14 Jan 2025 09:16:30 -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=Pdd+FRUzUXA/PQU6qO7eWIZvQ62DYyFOArMGvQG6sRU=; b=hfiN/07/iHE+ OLAarLSgR+CHYXyALhTT1SIp+cWua0MjZ8tCkxOr3HscjtFhzEqqx5/R4ebJXrm7P+FCwAG9S3P7x WZpxP+HQBkdMiAiF5Euu5/KfdyxUKPC3bWStLjbHqpNJpsz1v0cPf03LLc3mmJV4Vc4MEo8AhoFjv aUOQNl1Aqg1Oi5ML7v6RYLfQV4+7DLLS6mmxs+guhrKPSyO15gzZc2vw6MMNn3ZlC4/KqWcan548p Vb9MEOuV6vAE+AAVWGgFv0tFTypTVcK2IIiZt9a/NaZ04nYMJdao+wKR/KOpWwjFUAbtx1FjD5lnp 6+8z8POBiNvLwHa9qXxVLg==; Date: Tue, 14 Jan 2025 16:16:21 +0200 Message-Id: <86frlltr9m.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <87wmexr7df.fsf@protonmail.com> (message from Pip Cet on Tue, 14 Jan 2025 10:56:55 +0000) Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX References: <87r057tzjg.fsf@protonmail.com> <865xmiv81s.fsf@gnu.org> <86zfjutqy3.fsf@gnu.org> <86y0zet6md.fsf@gnu.org> <87wmexr7df.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75521 Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Tue, 14 Jan 2025 10:56:55 +0000 > From: Pip Cet > Cc: Stefan Kangas , 75521@debbugs.gnu.org > > I'll stop here. Yet another simple improvement (and bug fix) to Emacs > which was effectively vetoed. I have nothing useful to respond to these accusations, except to reiterate my firm belief that we should prefer investing our energy and resources in adding new infrastructure and/or replacing old one with newer and better one, to investing them in cleaning up old infrastructure. The old infrastructure works and works well; it had worked for us for decades. Cleaning it up brings only very small gains, if at all, while running non-negligible risks of introducing bugs. So replacing the current GC with a better, more performant and sophisticated one, is okay and very welcome; cleaning up the old GC is much less so (especially when we already have plans for replacing it). Let's be wise in where we decide to invest our resources. From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 14 10:59:52 2025 Received: (at 75521) by debbugs.gnu.org; 14 Jan 2025 15:59:52 +0000 Received: from localhost ([127.0.0.1]:55396 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXjKZ-0007pA-Qs for submit@debbugs.gnu.org; Tue, 14 Jan 2025 10:59:52 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:39100) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tXjKW-0007or-Vw for 75521@debbugs.gnu.org; Tue, 14 Jan 2025 10:59:49 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tXjKR-0000cT-Gn; Tue, 14 Jan 2025 10:59:43 -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=i/u0UfnP+A9YdFatr4MSDwHxpANuiaWBpbH0IjpzAHM=; b=OTo9moNaahBS F9iPrpnqnGVBTDSfYtThOP3phlfuDaqd0botSMzj4TtJvnjsDynHQDv1kn1nRAxGwhEEMmVrDEpRd VpLJjNBDHT1Qj431YMMYu1lkKJIwA1nmPJrMy8KYxN6Y1Nn76abLqhjNcwBBPIgDHljJxS3O39H7l 7FCVuS0TrfPHG67wU5RcmcmjXUfvuIxbaZDahoPW2sbS/VcyOQSXTlzUwFA6H7JGBf27wj173jihR CP643N6aKbIAVOt5lKXcEQmIHUIAbMW8/07+1LfkDRqfYlFLG0oMjx9gnKXihllw1mYAO77/qA1si o23bPKb1sM3iR1nKznh/CA==; Date: Tue, 14 Jan 2025 17:59:37 +0200 Message-Id: <86cygptmhi.fsf@gnu.org> From: Eli Zaretskii To: pipcet@protonmail.com, stefankangas@gmail.com In-Reply-To: <861px6v5om.fsf@gnu.org> (message from Eli Zaretskii on Mon, 13 Jan 2025 22:07:21 +0200) Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX References: <875xmiu0ex.fsf@protonmail.com> <86ed16vdlm.fsf@gnu.org> <871px6tyx2.fsf@protonmail.com> <86a5buvcps.fsf@gnu.org> <87wmeyshh3.fsf@protonmail.com> <867c6yv910.fsf@gnu.org> <87ldveseso.fsf@protonmail.com> <864j22v76f.fsf@gnu.org> <87cygqsd0q.fsf@protonmail.com> <861px6v5om.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75521 Cc: 75521@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com > Date: Mon, 13 Jan 2025 22:07:21 +0200 > From: Eli Zaretskii > > > Anyway, please don't install anything yet. I want to take a closer > look at this code and its usage, and I've ran out of time for today. WDYT about the patch below? It's supposed to keep the 3 variables in sync with the corresponding slots in font_style_table, if the slots are ever modified. diff --git a/src/font.c b/src/font.c index 8638226..77fc74b 100644 --- a/src/font.c +++ b/src/font.c @@ -418,8 +418,23 @@ font_style_to_value (enum font_property_index prop, Lisp_Object val, eassert (len < 255); elt = make_vector (2, make_fixnum (100)); ASET (elt, 1, val); - ASET (font_style_table, prop - FONT_WEIGHT_INDEX, - CALLN (Fvconcat, table, make_vector (1, elt))); + Lisp_Object new_table = CALLN (Fvconcat, table, make_vector (1, elt)); + /* Update the corresponding variable with the new value. */ + switch (prop) + { + case FONT_WEIGHT_INDEX: + Vfont_weight_table = new_table; + break; + case FONT_SLANT_INDEX: + Vfont_slant_table = new_table; + break; + case FONT_WIDTH_INDEX: + Vfont_width_table = new_table; + break; + default: + break; + } + ASET (font_style_table, prop - FONT_WEIGHT_INDEX, new_table); return (100 << 8) | (i << 4); } else From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 14 12:02:59 2025 Received: (at 75521) by debbugs.gnu.org; 14 Jan 2025 17:03:00 +0000 Received: from localhost ([127.0.0.1]:55492 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXkJf-00035z-Eh for submit@debbugs.gnu.org; Tue, 14 Jan 2025 12:02:59 -0500 Received: from mail-4316.protonmail.ch ([185.70.43.16]:41683) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tXkJb-00034h-GN for 75521@debbugs.gnu.org; Tue, 14 Jan 2025 12:02:58 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1736874166; x=1737133366; bh=gXlVZcBeWvbSPjz+tnbwoC4Hhv6mVDFWXEGqsSCqVHQ=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=X5lb2PCo293kAELTRriGaBp1I0iknQ2B8tmc17Ja6dQxW2BVmq73dm70xY/eDhCk3 yQzw4455hH6QSAyragRply7j9BL3ruFF+au2XU6qmx8gyUYO6XPOpMiDDf7TyPt/3m bRIRN7mDz64VdjGhn10yx5U+acjf7ZEJP31+z3JY/TwKSytJSJ51vGcaocQl4IURI5 J4augltzhZU+I5clCH1ZayuoRZxZwfHVMhYhL9qt3CyGhIMyAgW+VwWrY8o3kRG/oz YQPpS1w66F/94TiTqbfnveizY0oazqgXCEZkgyc6ooB0ASCQIKmiC/Qk3HNgQzvvjL iNcX1qONs7+Ug== Date: Tue, 14 Jan 2025 17:02:41 +0000 To: Eli Zaretskii From: Pip Cet Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX Message-ID: <87y0zdpbvd.fsf@protonmail.com> In-Reply-To: <86cygptmhi.fsf@gnu.org> References: <86a5buvcps.fsf@gnu.org> <87wmeyshh3.fsf@protonmail.com> <867c6yv910.fsf@gnu.org> <87ldveseso.fsf@protonmail.com> <864j22v76f.fsf@gnu.org> <87cygqsd0q.fsf@protonmail.com> <861px6v5om.fsf@gnu.org> <86cygptmhi.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 456357c4cb06d29457ba7aea6d7ca97bea13acda MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 75521 Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) "Eli Zaretskii" writes: >> Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com >> Date: Mon, 13 Jan 2025 22:07:21 +0200 >> From: Eli Zaretskii >> >> >> Anyway, please don't install anything yet. I want to take a closer >> look at this code and its usage, and I've ran out of time for today. > > WDYT about the patch below? It's supposed to keep the 3 variables in > sync with the corresponding slots in font_style_table, if the slots > are ever modified. If you meant to ask whether the patch will momentarily render this specific bug harmless, I believe it will (but expose other bugs which will still cause crashes). However, I don't like it one bit, and reviewing it finds many other things that seem like bugs here. I've already answered the question of what I think about this approach: "It's a very fragile approach, as evidenced by the fact that it was broken for so long, and there's absolutely no benefit to it. The next person to attempt to change this code won't understand why we use a non-staticpro'd variable which is kept in sync with a staticpro'd one (because there is no reason to do so), and probably break things again." Note that it's not just in theory that it's fragile: I have experimented with changes to the nativecomp code which would have broken it, because make_symbol_constant shouldn't just trap writes, it should also allow the nativecomp code to generate better code. It also changes behavior, of course, and the new behavior doesn't make much sense: with or without --enable-checking, it's trivial to cause further crashes by modifying the Vfont_weight_table variable's value, for example. I think we should fix this code not to crash with or without --enable-checking. It may be best to simply remove the Lisp variables entirely. > diff --git a/src/font.c b/src/font.c > index 8638226..77fc74b 100644 > --- a/src/font.c > +++ b/src/font.c > @@ -418,8 +418,23 @@ font_style_to_value (enum font_property_index prop, = Lisp_Object val, > eassert (len < 255); I don't see why this eassert makes sense. If we ever reach this code, why do we assume we can't reach it 256 times? If we reach it 256 times (or thereabouts), why crash Emacs? If we want to crash Emacs in this case, why only crash it if --enable-checking has been specified? font.c needs careful analysis, because there are too many apparent bugs in it right now (it also assumes that Vfont_encoding_alist isn't circular, for example). "Minimal" changes are not the right thing to do here. > elt =3D make_vector (2, make_fixnum (100)); This is also strange: 100 is the "medium" weight; we should be using 80, which is the "normal" one. 100 is the correct default slant and width, though. > ASET (elt, 1, val); > - ASET (font_style_table, prop - FONT_WEIGHT_INDEX, > -=09 CALLN (Fvconcat, table, make_vector (1, elt))); > + Lisp_Object new_table =3D CALLN (Fvconcat, table, make_vector (1, = elt)); This is also strange: the tables are documented to be sorted numerically, but I don't see any code that relies on that. vconcat certainly doesn't leave the tables sorted. I do see code, e.g. font_style_symbolic, which assumes that (i>>4) is the index corresponding to value i; this is not currently true, and font_style_symbolic will either eassert or fail to find the right entry. In the absence of checking, it will most likely cause crashes... > + /* Update the corresponding variable with the new value. */ > + switch (prop) > +=09{ > +=09case FONT_WEIGHT_INDEX: > +=09 Vfont_weight_table =3D new_table; > +=09 break; > +=09case FONT_SLANT_INDEX: > +=09 Vfont_slant_table =3D new_table; > +=09 break; > +=09case FONT_WIDTH_INDEX: > +=09 Vfont_width_table =3D new_table; > +=09 break; > +=09default: > +=09 break; "eassume (0);" is the right thing to do here, IMHO. If the default label isn't optimized out, it's redundant code. If we ever reach the default label, something else is severely wrong, so the eassume-as-eassert thing would save us. > +=09} > + ASET (font_style_table, prop - FONT_WEIGHT_INDEX, new_table); > return (100 << 8) | (i << 4); I need to check what this return value is used for: if 0x64f0 is the right return value for i =3D=3D 0xf, why is it 0x6500 for i =3D=3D 0x10? So, sorry, further fixes required, a minimal fix won't work. Pip From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 14 16:09:41 2025 Received: (at 75521) by debbugs.gnu.org; 14 Jan 2025 21:09:41 +0000 Received: from localhost ([127.0.0.1]:55954 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXoAO-000723-Qb for submit@debbugs.gnu.org; Tue, 14 Jan 2025 16:09:41 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:57906) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tXoAL-00071l-5m for 75521@debbugs.gnu.org; Tue, 14 Jan 2025 16:09:38 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tXoAE-0006D2-F4; Tue, 14 Jan 2025 16:09:30 -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=CfWHJixmuYhk9i7bhrnk8KShhX/XG9oUa2qwpS0+PqY=; b=eHOk6l0ljtJ4 pawiqjH6arKCrnKGG2bFfUmXHEMs36pCO8xnWpT/cDihUJYCdGrmvsZJIZzlpqneNxBC+XyEMeOQx abWujK4Aa6wiRIQg1pn8/jNhedjkU0aDh8052zZ9XVq1ounZZ76oDfWU/mjAbb4bcj73F/XzL7UCg 8AnkIFTU565q5vYpvuvVEK2Ly6m86osJfhW2Ca4xejd8IHHZHMMDyFpBjCT/GHX4uUbcXg17wccsA Y+KXnCM6REZHxyOZrB++CPzg2TayG7GXRuib6nTwjiAH/7GwPPndtxgX+uVojdiSc8cD6mY3s1bcK zdBtW2AQKBMpm/SQjwbWvA==; Date: Tue, 14 Jan 2025 23:09:27 +0200 Message-Id: <865xmht854.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <87y0zdpbvd.fsf@protonmail.com> (message from Pip Cet on Tue, 14 Jan 2025 17:02:41 +0000) Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX References: <86a5buvcps.fsf@gnu.org> <87wmeyshh3.fsf@protonmail.com> <867c6yv910.fsf@gnu.org> <87ldveseso.fsf@protonmail.com> <864j22v76f.fsf@gnu.org> <87cygqsd0q.fsf@protonmail.com> <861px6v5om.fsf@gnu.org> <86cygptmhi.fsf@gnu.org> <87y0zdpbvd.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75521 Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Tue, 14 Jan 2025 17:02:41 +0000 > From: Pip Cet > Cc: stefankangas@gmail.com, 75521@debbugs.gnu.org > > "Eli Zaretskii" writes: > > >> Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com > >> Date: Mon, 13 Jan 2025 22:07:21 +0200 > >> From: Eli Zaretskii > >> > >> > >> Anyway, please don't install anything yet. I want to take a closer > >> look at this code and its usage, and I've ran out of time for today. > > > > WDYT about the patch below? It's supposed to keep the 3 variables in > > sync with the corresponding slots in font_style_table, if the slots > > are ever modified. > > If you meant to ask whether the patch will momentarily render this > specific bug harmless, I believe it will (but expose other bugs which > will still cause crashes). I was asking about the problem where that code makes the values of Vfont_weight_table and its 2 brethren vulnerable to being GC'ed. That's the only problem I tried to solve with that patch. That Vfont_weight_table etc. are also updated to reflect the changes in font_style_table is a nice benefit. If you agree that this problem will be solved by the patch, then I'd like to install it, because it's very simple and localized, so the risk to break something is IMO very low. > I've already answered the question of what I think about this approach: > "It's a very fragile approach, as evidenced by the fact that it was > broken for so long, and there's absolutely no benefit to it. I think this wasn't reported because that code is seldom if ever executed. I couldn't find a way to enter it. But I see no reason to remove it at this point. > The next > person to attempt to change this code won't understand why we use a > non-staticpro'd variable which is kept in sync with a staticpro'd one > (because there is no reason to do so), and probably break things again." That can be alleviated a bit by adding commentary which explains this subtlety. > It also changes behavior, of course, and the new behavior doesn't make > much sense: with or without --enable-checking, it's trivial to cause > further crashes by modifying the Vfont_weight_table variable's value, > for example. Vfont_weight_table etc. are supposed not to be modifiable (it should cause Emacs to signal an error). If you can show a recipe for causing a crash by modifying them, I will certainly see why we don't behave as the doc string says. In any case, this is a separate issue. > I think we should fix this code not to crash with or without > --enable-checking. Crashes should be avoided, I agree. > It may be best to simply remove the Lisp variables entirely. I don't want to remove them because they are used, albeit in a small number of places. > > diff --git a/src/font.c b/src/font.c > > index 8638226..77fc74b 100644 > > --- a/src/font.c > > +++ b/src/font.c > > @@ -418,8 +418,23 @@ font_style_to_value (enum font_property_index prop, Lisp_Object val, > > eassert (len < 255); > > I don't see why this eassert makes sense. If we ever reach this code, > why do we assume we can't reach it 256 times? The code as implemented cannot allow the value to exceed 255, because each of the 3 style properties is restricted to be a vector of at most 256 elements. See the comment about that in font.h. > If we reach it 256 times > (or thereabouts), why crash Emacs? If we want to crash Emacs in this > case, why only crash it if --enable-checking has been specified? The original code (from Emacs 23) called emacs_abort here, so it aborted in both development and production builds. We could restore that. I don't think it matters much, since I cannot imagine a real-life situation where we get to that limit. And it's a separate issue as well. > font.c needs careful analysis That is certainly true (and the same goes for fontset.c, btw). > because there are too many apparent bugs > in it right now (it also assumes that Vfont_encoding_alist isn't > circular, for example). I don't think it's quite as buggy as you think. It does have quite a few places which are hard to explain, because the original experts who developed that part of Emacs are no longer active in Emacs development. > "Minimal" changes are not the right thing to do here. Let's disagree about that. Emacs is a large, old, and very stable program, so "minimal changes" are IMO exactly the right thing, as long as we don't change things radically. E.g., if someone wanted to completely redesign and reimplement how Emacs selects fonts, and could show convincingly that the new design will give us clear advantages in speed and/or correctness, then of course "minimal changes" won't apply. But otherwise making potentially disruptive changes in code we don't understand well which works quite well on several very different platforms is not TRT in my book. > > elt = make_vector (2, make_fixnum (100)); > > This is also strange: 100 is the "medium" weight; we should be using 80, > which is the "normal" one. 100 is the correct default slant and width, > though. Emacs originally didn't distinguish between "normal" and "medium". > > ASET (elt, 1, val); > > - ASET (font_style_table, prop - FONT_WEIGHT_INDEX, > > - CALLN (Fvconcat, table, make_vector (1, elt))); > > + Lisp_Object new_table = CALLN (Fvconcat, table, make_vector (1, elt)); > > This is also strange: the tables are documented to be sorted > numerically, but I don't see any code that relies on that. vconcat > certainly doesn't leave the tables sorted. Probably one more sign that this code is not used in practice. > I do see code, e.g. font_style_symbolic, which assumes that (i>>4) is > the index corresponding to value i; this is not currently true, and > font_style_symbolic will either eassert or fail to find the right entry. Please elaborate: when and how this could not be true. > In the absence of checking, it will most likely cause crashes... > > > + /* Update the corresponding variable with the new value. */ > > + switch (prop) > > + { > > + case FONT_WEIGHT_INDEX: > > + Vfont_weight_table = new_table; > > + break; > > + case FONT_SLANT_INDEX: > > + Vfont_slant_table = new_table; > > + break; > > + case FONT_WIDTH_INDEX: > > + Vfont_width_table = new_table; > > + break; > > + default: > > + break; > > "eassume (0);" is the right thing to do here, IMHO. If the default > label isn't optimized out, it's redundant code. If we ever reach the > default label, something else is severely wrong, so the > eassume-as-eassert thing would save us. We could do that, but the original code didn't, either. IOW, this is a separate issue. > So, sorry, further fixes required, a minimal fix won't work. I was asking about the fix to the single issue I intended to fix. From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 14 16:46:16 2025 Received: (at 75521) by debbugs.gnu.org; 14 Jan 2025 21:46:16 +0000 Received: from localhost ([127.0.0.1]:56009 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXojn-0000WY-Kr for submit@debbugs.gnu.org; Tue, 14 Jan 2025 16:46:15 -0500 Received: from mail-ed1-x52b.google.com ([2a00:1450:4864:20::52b]:58398) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tXojl-0000WG-1l for 75521@debbugs.gnu.org; Tue, 14 Jan 2025 16:46:13 -0500 Received: by mail-ed1-x52b.google.com with SMTP id 4fb4d7f45d1cf-5d414b8af7bso10522105a12.0 for <75521@debbugs.gnu.org>; Tue, 14 Jan 2025 13:46:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736891167; x=1737495967; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=lf9qG7eZo231MzY44eUEKAVrj9kk9c07RyffhrCT+Zg=; b=a/PksCQgFIgF/XUHcssILaa41wRdcJ4I+M0GHDZeUACFw6vtmwYphuJOslXj1JjpV9 0nEXQibSWV4twDrWgnf9EUNw8jBdXDxqWzI4umxsJD0moSAiSNlDVZLVrTlN+u2m7sJB TzvFyhKhmFir5Ok9RcholEF8Bho5WQsoIRuOY42ICk9OnKlgp5C6ych6rVlmJWdtLi/b lj8jizSV5H2yEFe7Bmn0QaDW9R8XR5sdvKcyOnfsH2LZqbawqB4IfDDMFeGtJwegD50F KlFS34BwAB+r/6cliJkZ65Cf+avlOUVYGd6fgk/TjrAj1tRE54QCxg1O6lPXrSOZ4Z5U cGHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736891167; x=1737495967; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=lf9qG7eZo231MzY44eUEKAVrj9kk9c07RyffhrCT+Zg=; b=sTPlIik3W5FYW0JQ9JP2b2w2LP1uJb84z+soCTRztqKyFVdVf2QYu0jjoH9x3jqJYG HtpQlDXDRCWOW+/2L4v2j1VV0LOETDoDxgswi0jgzRbN5tQc04e9xE06gm6PUSrkuB6Y UT4yuKe2jAUrA7lxv4C2JJYeT7hKcpJF7kmRDxdElKbFsleVe1XPQn1Hizf9BqT0ot65 CEPkPb6lzXsiXOcy5dgMsGmN8yTfpcj7dc32oy207O5osepbkafrroctoBw5kCejiezo 1qaof9F8KknuL1+xgGh7lQe2yMYN267iV1ChfSxo9a1qa7vieTOg8sMXOzlqxsXXaPF1 l5Pg== X-Forwarded-Encrypted: i=1; AJvYcCUmc8z0m3qmupwUGVfMo1iqqXxAygviucCMv5xEM9H9WbNk7yEEZ1245toUqT/2mKQQlFMi0g==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxoXHvXvkgr5AJMir6OedP8hw9a4E15ndbbGI3NcrcJ/wJPM+e+ k2uZQg97kXT0BQpLrJWsr9ysdCEax5WMzNBnltVgoDOffjYrrDMYsSM5b6gmUf1XvqL40d5hAZd IVqAZgml9DGFDw39N4MMg/PCqSOQ= X-Gm-Gg: ASbGncsmquXvioNFeoMRMbQAWsozjM7lNuaPoVy00yeIiNrwlQO0xVN/pAe6kxxaYPR vdq4BWDrbaSQO6/Hm837WXGxy6mWO17B1YSoLGlsX X-Google-Smtp-Source: AGHT+IGEMitODKsuSLxHDJTH7oSSONSXzgGxF2Mc8OJriLCB/7iLCSNriLTvPe+HzgDkpuKPxUxAvtJoDhH5xBj5INA= X-Received: by 2002:a05:6402:4315:b0:5d9:f8d3:6e69 with SMTP id 4fb4d7f45d1cf-5d9f8d37175mr4254861a12.16.1736891166588; Tue, 14 Jan 2025 13:46:06 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Tue, 14 Jan 2025 16:46:06 -0500 From: Stefan Kangas In-Reply-To: <86y0zet6md.fsf@gnu.org> References: <87r057tzjg.fsf@protonmail.com> <865xmiv81s.fsf@gnu.org> <86zfjutqy3.fsf@gnu.org> <86y0zet6md.fsf@gnu.org> MIME-Version: 1.0 Date: Tue, 14 Jan 2025 16:46:06 -0500 X-Gm-Features: AbW1kvZQvSBVrhS6Mae0-xNCxfSfGX4_jPFJsLkyXHkfblocM-RdP2ec9SRXxb4 Message-ID: Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 75521 Cc: 75521@debbugs.gnu.org, pipcet@protonmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Stefan Kangas >> Date: Mon, 13 Jan 2025 21:09:02 +0000 >> Cc: pipcet@protonmail.com, 75521@debbugs.gnu.org >> >> Yes, indeed, but that seems like an optimization that is not worth >> doing. Not these days, at any rate. > > If you try to staticpro too many variables, the build will fail > because Emacs runs out of space in staticvec. Not everyone knows what > to do in this case, and it's an annoyance when this happens. So I > would not say so easily that it's an optimization not worth doing, no. NSTATICS was last increased by Paul in 2013 (4195afc389bb). I ask to consider again what are the benefits of keeping this macro. >> Note that with MPS, DEFVAR_LISP and DEFVAR_LISP_NOPRO are equivalent. > > When the igc branch lands, this will be a non-issue, yes. One more > reason not to waste too much effort on this code now. But since the > genie is out of the bottle, we must. Are you okay with removing this on the scratch/igc branch only? >> So by getting rid of DEFVAR_LISP_NOPRO, we would reduce the delta >> between igc and master as a nice bonus. > > Why do we need to reduce the delta? what does that get us? IME, all things being equal, it's always going to be easier to review and eventually merge changes if the delta is smaller. From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 14 16:58:53 2025 Received: (at 75521) by debbugs.gnu.org; 14 Jan 2025 21:58:54 +0000 Received: from localhost ([127.0.0.1]:56021 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tXow1-00012H-6d for submit@debbugs.gnu.org; Tue, 14 Jan 2025 16:58:53 -0500 Received: from mail-40131.protonmail.ch ([185.70.40.131]:60343) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tXovy-00011x-N1 for 75521@debbugs.gnu.org; Tue, 14 Jan 2025 16:58:52 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1736891923; x=1737151123; bh=8mA5LiNd+7OpyWbNrZElfb8kYBm2VyCW8KKZXveOTQs=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=raDoHcAO38n3zWVf+GpeyUHDSm7TQzHjlMZAL+x1+ChH02n5K8dgz4iX2AOeqUQSq zPWjNZl3eT4JR/t3AD43uk7CGYVRyLVIQgQM4SkqsQDJglZkTXOgEdmxhKT+zzbDYC C6cO8rRi25FjLdxgPXfgxruMhEFAGJYv8tzZversSxNyZXpMQyiixwq4APhtoNSHds o9ug+Azuas4rminmyK2KyjIPtpytUB9TUN4cI5MKULIHr9IFHSU61hR2WqI/tA4zvC ouF/Gt3mMAezruxjDul0CE5J6oRUSrfW0cs7AWfRLwAnrRZUyQAbhNeqQTi8uPsK0K yvxFqRixz+qpA== Date: Tue, 14 Jan 2025 21:58:37 +0000 To: Eli Zaretskii From: Pip Cet Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX Message-ID: <877c6xoy65.fsf@protonmail.com> In-Reply-To: <865xmht854.fsf@gnu.org> References: <867c6yv910.fsf@gnu.org> <87ldveseso.fsf@protonmail.com> <864j22v76f.fsf@gnu.org> <87cygqsd0q.fsf@protonmail.com> <861px6v5om.fsf@gnu.org> <86cygptmhi.fsf@gnu.org> <87y0zdpbvd.fsf@protonmail.com> <865xmht854.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 63cc68e2e81adf75145e783ffe92b3de338dd9c4 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.8 (/) X-Debbugs-Envelope-To: 75521 Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.8 (--) "Eli Zaretskii" writes: >> Date: Tue, 14 Jan 2025 17:02:41 +0000 >> From: Pip Cet >> Cc: stefankangas@gmail.com, 75521@debbugs.gnu.org >> >> "Eli Zaretskii" writes: >> >> >> Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com >> >> Date: Mon, 13 Jan 2025 22:07:21 +0200 >> >> From: Eli Zaretskii >> >> >> >> >> >> Anyway, please don't install anything yet. I want to take a closer >> >> look at this code and its usage, and I've ran out of time for today. >> > >> > WDYT about the patch below? It's supposed to keep the 3 variables in >> > sync with the corresponding slots in font_style_table, if the slots >> > are ever modified. >> >> If you meant to ask whether the patch will momentarily render this >> specific bug harmless, I believe it will (but expose other bugs which >> will still cause crashes). > > I was asking about the problem where that code makes the values of > Vfont_weight_table and its 2 brethren vulnerable to being GC'ed. > That's the only problem I tried to solve with that patch. That > Vfont_weight_table etc. are also updated to reflect the changes in > font_style_table is a nice benefit. Not really a benefit: updating the variables might expose other (crashable) bugs more. > If you agree that this problem will be solved by the patch, then I'd > like to install it, because it's very simple and localized, so the > risk to break something is IMO very low. It introduces what are effectively new crashable bugs by attempting to fix old ones. I'm neutral: installing this patch won't improve things significantly, but if you think there might be a slight improvement, you probably have your reasons. >> I've already answered the question of what I think about this approach: >> "It's a very fragile approach, as evidenced by the fact that it was >> broken for so long, and there's absolutely no benefit to it. > > I think this wasn't reported because that code is seldom if ever > executed. I couldn't find a way to enter it. But I see no reason to > remove it at this point. No one suggested removing this code. >> The next >> person to attempt to change this code won't understand why we use a >> non-staticpro'd variable which is kept in sync with a staticpro'd one >> (because there is no reason to do so), and probably break things again." > > That can be alleviated a bit by adding commentary which explains this > subtlety. The "subtlety" is unnecessary complication, but I repeat myself. We can't add a comment explaining the reason for it because it's not necessary. >> It also changes behavior, of course, and the new behavior doesn't make >> much sense: with or without --enable-checking, it's trivial to cause >> further crashes by modifying the Vfont_weight_table variable's value, >> for example. > > Vfont_weight_table etc. are supposed not to be modifiable (it should > cause Emacs to signal an error). If you can show a recipe for causing > a crash by modifying them, I will certainly see why we don't behave as > the doc string says. ??? Of course the vector value can be modified, it's just that the variable cannot be assigned to. Faset doesn't care, and why would it? > In any case, this is a separate issue. Agreed. I'm not asking you not to install your patch (it's code churn, but then it's possible it'll fix slightly more crashes than it introduces), and please give me some time to think about whether it's really worth it to go through another dozen-or-so email cycles just to end up with another "fix" which makes Emacs even more complicated while failing to address the actual issues. Pip From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 15 08:53:22 2025 Received: (at 75521) by debbugs.gnu.org; 15 Jan 2025 13:53:22 +0000 Received: from localhost ([127.0.0.1]:57275 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tY3ph-0001T9-LT for submit@debbugs.gnu.org; Wed, 15 Jan 2025 08:53:22 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:45266) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tY3pf-0001Sk-5Y for 75521@debbugs.gnu.org; Wed, 15 Jan 2025 08:53:20 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tY3pZ-0008Ce-Oj; Wed, 15 Jan 2025 08:53:13 -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=POFBnbmrZ8KdutUNPt2PIkQwc2L3wfVEy0XuVioV4ho=; b=TePvVf/DoKA8 42meF0Pk9MY1zh3Or/ZrXe+9Ky1Qyc2gn0T6DNrailDkeN5x8vivw105Dd8kcOF/WuNd22NPx4iBi MFoVwzL5pGj5LdNr7EnVVDxflBUYMGKcOi6q/jDhb60c8vgrZqTF552kJmPlWCrAswqBGoizNKBLV jQTmxhnBkMcwMZNszO7Fnw6oeuFAPCwGOV+UpZZnpTjx91AQ0IwdsSxULHMtzirOT0XlpYZ/uGvyH ne15vCJTARUeigTIhUSgwspLtMptPvw8bkymoeZl3aM+QO9nWdrH/IvqypKZY/dczQmIuE/mXCFzM KddI/aI8uHi4zElUyN0EQw==; Date: Wed, 15 Jan 2025 15:53:10 +0200 Message-Id: <867c6wkwu1.fsf@gnu.org> From: Eli Zaretskii To: Stefan Kangas In-Reply-To: (message from Stefan Kangas on Tue, 14 Jan 2025 16:46:06 -0500) Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX References: <87r057tzjg.fsf@protonmail.com> <865xmiv81s.fsf@gnu.org> <86zfjutqy3.fsf@gnu.org> <86y0zet6md.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75521 Cc: 75521@debbugs.gnu.org, pipcet@protonmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Kangas > Date: Tue, 14 Jan 2025 16:46:06 -0500 > Cc: pipcet@protonmail.com, 75521@debbugs.gnu.org > > Eli Zaretskii writes: > > >> From: Stefan Kangas > >> Date: Mon, 13 Jan 2025 21:09:02 +0000 > >> Cc: pipcet@protonmail.com, 75521@debbugs.gnu.org > >> > >> Yes, indeed, but that seems like an optimization that is not worth > >> doing. Not these days, at any rate. > > > > If you try to staticpro too many variables, the build will fail > > because Emacs runs out of space in staticvec. Not everyone knows what > > to do in this case, and it's an annoyance when this happens. So I > > would not say so easily that it's an optimization not worth doing, no. > > NSTATICS was last increased by Paul in 2013 (4195afc389bb). Actually, it was a year before, but I don't see how that changes the fact that redundant protecting should be avoided. > I ask to consider again what are the benefits of keeping this macro. There are no benefits in keeping it. But there are risks in removing it, because that requires changes in font.c, in code which we don't understand well enough (see this discussion as the evidence), and thus could inadvertently break by some change. > >> Note that with MPS, DEFVAR_LISP and DEFVAR_LISP_NOPRO are equivalent. > > > > When the igc branch lands, this will be a non-issue, yes. One more > > reason not to waste too much effort on this code now. But since the > > genie is out of the bottle, we must. > > Are you okay with removing this on the scratch/igc branch only? I have no problems with doing that on the branch conditioned by "#ifdef HAVE_MPS", if indeed DEFVAR_LISP_NOPRO is equivalent to DEFVAR_LISP there. But are they indeed equivalent? staticpro still exists on the branch, and AFAICT we create a root from staticvec. So why are they equivalent? > >> So by getting rid of DEFVAR_LISP_NOPRO, we would reduce the delta > >> between igc and master as a nice bonus. > > > > Why do we need to reduce the delta? what does that get us? > > IME, all things being equal, it's always going to be easier to review > and eventually merge changes if the delta is smaller. For such significant changes, I don't expect anyone to eyeball the diffs when merging the branch. From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 15 12:52:29 2025 Received: (at 75521) by debbugs.gnu.org; 15 Jan 2025 17:52:29 +0000 Received: from localhost ([127.0.0.1]:58634 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tY7Z7-0004bd-4o for submit@debbugs.gnu.org; Wed, 15 Jan 2025 12:52:29 -0500 Received: from mail-4316.protonmail.ch ([185.70.43.16]:55793) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tY7Z3-0004bM-Vy for 75521@debbugs.gnu.org; Wed, 15 Jan 2025 12:52:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1736963537; x=1737222737; bh=aIRdOweMLuLiVds17EsRrlmBtmCW0l7znT3cMihEYe0=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=LazQH1IoxBa+dpUC3tf3Xi1ehhkB63D+xXnyQhrj8SGhMOj5NDO5cPrdamvcd3+Ez FaKPFjK2wMr88P/NAIzsv+jfn/YWL0AlSR/Kt1cGb/Hs0+PJ0ogG4t3cy3ZJrsx/LV kxkFMBpFrTlX7KvLw5/anQ+kffkgP/IhgFki/fjTfjNanNXjWvNI/shYuVZpYh9wgn MzEfXyU7HbimbtmHTD+2DUBRjUSQwZE58N64SWMOyyM1ltp1uwvVUC61LGzhK8rgZb FM5kw+3idNczR0vPyXcepDTmtzz8R/ko8KGVDGOH/5o2ec6gtI5KEqwI93ANQDnYUX kfLGYksHltPIw== Date: Wed, 15 Jan 2025 17:52:13 +0000 To: Eli Zaretskii From: Pip Cet Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX Message-ID: <877c6wneww.fsf@protonmail.com> In-Reply-To: <867c6wkwu1.fsf@gnu.org> References: <865xmiv81s.fsf@gnu.org> <86zfjutqy3.fsf@gnu.org> <86y0zet6md.fsf@gnu.org> <867c6wkwu1.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 1bc12118160aea380e5852282939d9aab897e2ae MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75521 Cc: 75521@debbugs.gnu.org, Stefan Kangas X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) "Eli Zaretskii" writes: >> From: Stefan Kangas >> Date: Tue, 14 Jan 2025 16:46:06 -0500 >> Cc: pipcet@protonmail.com, 75521@debbugs.gnu.org >> >> Eli Zaretskii writes: >> >> >> From: Stefan Kangas >> >> Date: Mon, 13 Jan 2025 21:09:02 +0000 >> >> Cc: pipcet@protonmail.com, 75521@debbugs.gnu.org >> >> >> >> Yes, indeed, but that seems like an optimization that is not worth >> >> doing. Not these days, at any rate. >> > >> > If you try to staticpro too many variables, the build will fail >> > because Emacs runs out of space in staticvec. Not everyone knows what >> > to do in this case, and it's an annoyance when this happens. So I >> > would not say so easily that it's an optimization not worth doing, no. >> >> NSTATICS was last increased by Paul in 2013 (4195afc389bb). > > Actually, it was a year before, but I don't see how that changes the > fact that redundant protecting should be avoided. That sentence is the straw that broke the camel's back. It's not a fact, it's an individual opinion which virtually everyone else disagrees with (for very good reasons). I certainly do. Literally the only argument that has been advanced to support this *opinion* is that removing the *three* remaining _NOPROs (which are, at this point, NOT redundant, but buggy) would somehow cause us to run out of NSTATICS, which would mean more than doubling our staticpro calls overnight, adding more than a thousand staticpros. If diverging opinions are described as contradicting alleged "facts", there is no point discussing this further. Pip From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 15 14:46:07 2025 Received: (at 75521) by debbugs.gnu.org; 15 Jan 2025 19:46:07 +0000 Received: from localhost ([127.0.0.1]:58788 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tY9L5-0001J4-I4 for submit@debbugs.gnu.org; Wed, 15 Jan 2025 14:46:07 -0500 Received: from mail-ed1-x52a.google.com ([2a00:1450:4864:20::52a]:53723) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tY9L0-0001IM-QW for 75521@debbugs.gnu.org; Wed, 15 Jan 2025 14:46:05 -0500 Received: by mail-ed1-x52a.google.com with SMTP id 4fb4d7f45d1cf-5da12292b67so184732a12.3 for <75521@debbugs.gnu.org>; Wed, 15 Jan 2025 11:46:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736970356; x=1737575156; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=T9F7zbMf5RVwa42BbMH9CQCQDJg/J9fV27mp6R6sSFk=; b=HTrCJWZTmyrOkN9a3giezvCeyDV+viEIoxJ8+egaVn11fBiFK60S4bqX7Hcxj/eUdX 1iRy5NBwyh39kiJkcQmvlsD/wT49s335zrlUkqXVDIJkrbjvqqoI1GHbybkaD8g1G2t8 PgqWUTqYcMF9cGQuWcj0yWDgfw9zrHjxNS4xrfg4AZDye+8kPE5QRpx8BJ/qlOlPL3kQ VVIrC4iWFlZt6FILe5e8Ljg/hqQmhlQqIaR7NSw2TMrAoYmWPzuvP9S7h8Dp1yCT2tN5 ATXSh2tzYRp37bajEd+AAf6ifMXmbONibpd6pmSxhbELpaCzvaSrii8ToLcK1x4VD+Yh 3ccQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736970357; x=1737575157; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=T9F7zbMf5RVwa42BbMH9CQCQDJg/J9fV27mp6R6sSFk=; b=kqTzQAOqcNOMGK2OLrbYB9VeE7p6q9WSAcSn/Sy8N4HNe+Z2nj9ISN4Iu5uggQDA8c avA8YZWNSADLxKAqwzqDiNdBZGc3CqSFtngwKBRbVy99NMPjJrsqmsSzdsa7QOp8GPiQ oiCvS2D2hJWabOTdPjOfMzJUV6sIbSVEr3eRvDyA95gF4AMiwtCJPT9rI9enEKTju0BS x2+iLIYjrwpLSYvJ4Ma/8SgIVfJevr0/DLmtjYOCNYqZzDQ3t/h5VFltLZx5u4DdFX01 0Gdwb+PeGF2WnnucV4vr8juH4y9aCe2N5LsU/L6ru8VpuigVVUbG8c6ZK2qU5qXZ+Oog Cspg== X-Forwarded-Encrypted: i=1; AJvYcCU9bkI748Zm9EhAa5G/aGScb3fRI5YxpN7uwPF4/+hkh3fFWt0yIIjTQ0yNRBZ+8LCzdFD+2g==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yyo6n6XG0ACmlE2sqdjJfUxkHdOww8asFxVLA7u1rq7nTqVBxH7 Pb6R0z0vKmIiDv27pUduN+60qVWCkONeN0c6zQPM42uwk5I0ufaVgi1S6BuIBJ7JVuO4Sh4tz1U ze0M0d60W4Fl4addoHBehaocfBss= X-Gm-Gg: ASbGncv6AEMqVwsk4wKUvVhAztXKPHDktVhfdxURgxspVZ37tWkTfS02mvqw1rm5sDE wCgnxqIy0FjgMYcMcNKqElVPlIhpZCNn7lN9HydQh X-Google-Smtp-Source: AGHT+IHcD8o8g/XgAfGWQd5dSp7l5IpsqjzCU1suk5m5mQb9LCsXxbCgdHChDjQrtvVlJHDpisq3Ac6cVn9f5Z4zyis= X-Received: by 2002:a05:6402:4314:b0:5d9:f1f7:5bcc with SMTP id 4fb4d7f45d1cf-5d9f1f75e45mr22501355a12.29.1736970356434; Wed, 15 Jan 2025 11:45:56 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Wed, 15 Jan 2025 19:45:55 +0000 From: Stefan Kangas In-Reply-To: <867c6wkwu1.fsf@gnu.org> References: <87r057tzjg.fsf@protonmail.com> <865xmiv81s.fsf@gnu.org> <86zfjutqy3.fsf@gnu.org> <86y0zet6md.fsf@gnu.org> <867c6wkwu1.fsf@gnu.org> MIME-Version: 1.0 Date: Wed, 15 Jan 2025 19:45:55 +0000 X-Gm-Features: AbW1kvZz3RKBNGsboB7MM12S0erRj4m43GPqP7PPGsziFL_lpKf9vl8ubtHubHE Message-ID: Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 75521 Cc: 75521@debbugs.gnu.org, pipcet@protonmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> Are you okay with removing this on the scratch/igc branch only? > > I have no problems with doing that on the branch conditioned by > "#ifdef HAVE_MPS", if indeed DEFVAR_LISP_NOPRO is equivalent to > DEFVAR_LISP there. Thanks, done in commit de864e4f3b2. > But are they indeed equivalent? staticpro still > exists on the branch, and AFAICT we create a root from staticvec. So > why are they equivalent? Yes, they had the same definition: #define DEFVAR_LISP(lname, vname, doc) \ do { \ static struct Lisp_Fwd const o_fwd \ = {Lisp_Fwd_Obj, .u.objvar = &globals.f_##vname}; \ defvar_lisp (&o_fwd, lname); \ } while (false) #ifdef HAVE_MPS #define DEFVAR_LISP_NOPRO(lname, vname, doc) \ do { \ static struct Lisp_Fwd const o_fwd \ = {Lisp_Fwd_Obj, .u.objvar = &globals.f_##vname}; \ defvar_lisp (&o_fwd, lname); \ } while (false) #else From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 15 15:27:55 2025 Received: (at 75521) by debbugs.gnu.org; 15 Jan 2025 20:27:55 +0000 Received: from localhost ([127.0.0.1]:58901 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tY9zW-0006B1-Tm for submit@debbugs.gnu.org; Wed, 15 Jan 2025 15:27:55 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:50758) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tY9zU-0006Ao-Tg for 75521@debbugs.gnu.org; Wed, 15 Jan 2025 15:27:53 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tY9zO-0000KF-Nw; Wed, 15 Jan 2025 15:27:46 -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=Hopncr+ydxt5UguCtlsJAMeG3esVwigZYgYCX2B5tTY=; b=jeWHysn7pbNI itluzaQkMN6GEcuPeSAfnuza/u6qNVq08PN48BURarsh6oe3MocO4HBw3AGLTLg+9KHdX+9ZBcKPJ hAltqUerDUPy3M7kHa6v6/07QJbaqox7hbbP1uG0MfBJBhj7kSg2EdL18oaK16CswejNPQTqxzQTP kGa0x9e/OfL/dwtLg8apBjkX113Xi0B5a+bCZdrN8DYQdTzkKq7cW41ZV66uU7qY8k8EyUhgiga2B uGCiRGxntTYUQ+UNMfxt1vH6gTRQlW7laUOHWijkGhMn0CR0NkG+5I1BFA/6tBCmLQi6gqR8l47NO c2J4kiKzeJ+cDKlZxlfPUA==; Date: Wed, 15 Jan 2025 22:27:43 +0200 Message-Id: <867c6vkekg.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <877c6wneww.fsf@protonmail.com> (message from Pip Cet on Wed, 15 Jan 2025 17:52:13 +0000) Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX References: <865xmiv81s.fsf@gnu.org> <86zfjutqy3.fsf@gnu.org> <86y0zet6md.fsf@gnu.org> <867c6wkwu1.fsf@gnu.org> <877c6wneww.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75521 Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Wed, 15 Jan 2025 17:52:13 +0000 > From: Pip Cet > Cc: Stefan Kangas , 75521@debbugs.gnu.org > > "Eli Zaretskii" writes: > > >> NSTATICS was last increased by Paul in 2013 (4195afc389bb). > > > > Actually, it was a year before, but I don't see how that changes the > > fact that redundant protecting should be avoided. > > That sentence is the straw that broke the camel's back. > > It's not a fact, it's an individual opinion which virtually everyone > else disagrees with (for very good reasons). I certainly do. Literally > the only argument that has been advanced to support this *opinion* is > that removing the *three* remaining _NOPROs (which are, at this point, > NOT redundant, but buggy) would somehow cause us to run out of NSTATICS, > which would mean more than doubling our staticpro calls overnight, > adding more than a thousand staticpros. It isn't an opinion. Wasting memory is bad, period. We could argue whether 3 slots in staticvec is a significant waste or not, and that would be a matter of opinion, but Stefan's question was why do we do it, and I answered that. All your other arguments are about something else, and are definitely opinions. (Though I don't understand since when or why "opinion" became a derogatory word around here.) > If diverging opinions are described as contradicting alleged "facts", > there is no point discussing this further. Then don't. From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 15 15:45:49 2025 Received: (at 75521) by debbugs.gnu.org; 15 Jan 2025 20:45:49 +0000 Received: from localhost ([127.0.0.1]:58923 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tYAGr-00071b-Eu for submit@debbugs.gnu.org; Wed, 15 Jan 2025 15:45:49 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:54136) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tYAGn-00071L-A7 for 75521@debbugs.gnu.org; Wed, 15 Jan 2025 15:45:47 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tYAGh-00025K-Oi; Wed, 15 Jan 2025 15:45:39 -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=pA1IzDv7Km1UxhZTByUd4WbB4Ui3Wp4ygx81HLan1aM=; b=diY4X8LGj6QQ H7FMWzpL3qz+PtTyYf6ipnP2r0kWAG3uxP/3fzGq/F6D4x/ndp+H5fdDcl9rmrFLEKPj7eg/pawiN l8IdIca7urq03iMdYEmSsnBSQAw6W4EYKaCwGo0MUgaAT/sqlIbnzGFmRX+ZFTiwz76Qb8YV0igXz brPfrhR5pg5i6G9nQK91u9hh8rc4cCvFK5Aj1gaqjB1K7sX+Ea0tl4e97OQCs6QcpW1NkFu3xZla7 iqXprZw1mdgOW8TSkXjtEPSIj2N0wEawc/vHXLhXoFYXVgqjPY1beQpdeIl6tPocPKKQJ38iZCG94 I1mbFhxeBe92Cr1SoOl8Ew==; Date: Wed, 15 Jan 2025 22:45:21 +0200 Message-Id: <865xmfkdr2.fsf@gnu.org> From: Eli Zaretskii To: Stefan Kangas In-Reply-To: (message from Stefan Kangas on Wed, 15 Jan 2025 19:45:55 +0000) Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX References: <87r057tzjg.fsf@protonmail.com> <865xmiv81s.fsf@gnu.org> <86zfjutqy3.fsf@gnu.org> <86y0zet6md.fsf@gnu.org> <867c6wkwu1.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75521 Cc: 75521@debbugs.gnu.org, pipcet@protonmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Kangas > Date: Wed, 15 Jan 2025 19:45:55 +0000 > Cc: pipcet@protonmail.com, 75521@debbugs.gnu.org > > Eli Zaretskii writes: > > >> Are you okay with removing this on the scratch/igc branch only? > > > > I have no problems with doing that on the branch conditioned by > > "#ifdef HAVE_MPS", if indeed DEFVAR_LISP_NOPRO is equivalent to > > DEFVAR_LISP there. > > Thanks, done in commit de864e4f3b2. Too bad you did that while we are still discussing the issue. Why the haste? The result is that we now have confusing code, see below. > > But are they indeed equivalent? staticpro still > > exists on the branch, and AFAICT we create a root from staticvec. So > > why are they equivalent? > > Yes, they had the same definition: > > #define DEFVAR_LISP(lname, vname, doc) \ > do { \ > static struct Lisp_Fwd const o_fwd \ > = {Lisp_Fwd_Obj, .u.objvar = &globals.f_##vname}; \ > defvar_lisp (&o_fwd, lname); \ > } while (false) > #ifdef HAVE_MPS > #define DEFVAR_LISP_NOPRO(lname, vname, doc) \ > do { \ > static struct Lisp_Fwd const o_fwd \ > = {Lisp_Fwd_Obj, .u.objvar = &globals.f_##vname}; \ > defvar_lisp (&o_fwd, lname); \ > } while (false) > #else Heh, I was looking at these: void defvar_lisp_nopro (struct Lisp_Fwd const *o_fwd, char const *namestring) { eassert (o_fwd->type == Lisp_Fwd_Obj); Lisp_Object sym = intern_c_string (namestring); XBARE_SYMBOL (sym)->u.s.declared_special = true; XBARE_SYMBOL (sym)->u.s.redirect = SYMBOL_FORWARDED; SET_SYMBOL_FWD (XBARE_SYMBOL (sym), o_fwd); } void defvar_lisp (struct Lisp_Fwd const *o_fwd, char const *namestring) { eassert (o_fwd->type == Lisp_Fwd_Obj); defvar_lisp_nopro (o_fwd, namestring); staticpro (o_fwd->u.objvar); } (which are still different) because I remembered that the macros just called the functions. And your changes didn't remove defvar_lisp_nopro. Isn't that confusing? From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 15 16:04:27 2025 Received: (at 75521) by debbugs.gnu.org; 15 Jan 2025 21:04:27 +0000 Received: from localhost ([127.0.0.1]:58955 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tYAYt-0007tp-6c for submit@debbugs.gnu.org; Wed, 15 Jan 2025 16:04:27 -0500 Received: from mail-40131.protonmail.ch ([185.70.40.131]:57681) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tYAYq-0007tY-M6 for 75521@debbugs.gnu.org; Wed, 15 Jan 2025 16:04:25 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1736975057; x=1737234257; bh=GyxoUi403+KmiIA/R9FMzsvJ375R3zCJyR1nrc/hwwk=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector:List-Unsubscribe:List-Unsubscribe-Post; b=I1+/koWT/HaIk9nlsxeJQX+1dmZKkGtVqbTNcnfnCu5y64F1UFdB7XLjAGmoMM6ct 4Zkz/XiHjOU6ys80/n71suSV4JVUbJxOPy4tD2RhI8Wuay7QOi6hMv1nrVleR8Xq8E T4QLwV4FTtgpXkFm3a1z7x+lkSvni8bjIlE5U/PapUvpBSda5Q8PDpAUnBP9EHbEj2 BoRylBdv5YSe0gq7/KCheLn3iVoQCv4eijy/Zp47vCM5xv+UdWfAWUHFff1jPeWm0s 7xFSRSFmI5pShVLS4cr311vSjZWveGoqZynZQsEg5b2HqHXA+VbomMn9peTJAPD04d fkGJWOmoLORrw== Date: Wed, 15 Jan 2025 21:04:14 +0000 To: Eli Zaretskii From: Pip Cet Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX Message-ID: <87tt9zn60t.fsf@protonmail.com> In-Reply-To: <867c6vkekg.fsf@gnu.org> References: <86zfjutqy3.fsf@gnu.org> <86y0zet6md.fsf@gnu.org> <867c6wkwu1.fsf@gnu.org> <877c6wneww.fsf@protonmail.com> <867c6vkekg.fsf@gnu.org> Feedback-ID: 112775352:user:proton X-Pm-Message-ID: 3a1e5fd602fe26980818478820edf279d701f0ef MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -1.8 (-) X-Debbugs-Envelope-To: 75521 Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.8 (--) "Eli Zaretskii" writes: >> Date: Wed, 15 Jan 2025 17:52:13 +0000 >> From: Pip Cet >> Cc: Stefan Kangas , 75521@debbugs.gnu.org >> >> "Eli Zaretskii" writes: >> >> >> NSTATICS was last increased by Paul in 2013 (4195afc389bb). >> > >> > Actually, it was a year before, but I don't see how that changes the >> > fact that redundant protecting should be avoided. >> >> That sentence is the straw that broke the camel's back. >> >> It's not a fact, it's an individual opinion which virtually everyone >> else disagrees with (for very good reasons). I certainly do. Literally >> the only argument that has been advanced to support this *opinion* is >> that removing the *three* remaining _NOPROs (which are, at this point, >> NOT redundant, but buggy) would somehow cause us to run out of NSTATICS, >> which would mean more than doubling our staticpro calls overnight, >> adding more than a thousand staticpros. > > It isn't an opinion. Wasting memory is bad, period. This is too ridiculous to leave uncommented: staticpro does not allocate or increase memory usage in any way. No memory is wasted. staticvec has a static size, and memory in it that's unused is not available for other purposes. (Of course, both the existence of a separate _NOPRO macro and the now-redundant font_style_table vector do waste memory, which is one of the reasons why my patch, which is being rejected because "wasting memory is bad", removed them.) > All your other arguments are about something else, and are definitely > opinions. (Though I don't understand since when or why "opinion" > became a derogatory word around here.) You claimed your opinion was a fact. That might have been an honest mistake, but it was pointed out to you and you responded with another falsehood. There's only so much good faith one can assume. Pip From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 15 16:55:46 2025 Received: (at 75521) by debbugs.gnu.org; 15 Jan 2025 21:55:46 +0000 Received: from localhost ([127.0.0.1]:59038 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tYBMY-0001vZ-Ct for submit@debbugs.gnu.org; Wed, 15 Jan 2025 16:55:46 -0500 Received: from mail-ed1-x535.google.com ([2a00:1450:4864:20::535]:61859) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tYBMT-0001vF-RA for 75521@debbugs.gnu.org; Wed, 15 Jan 2025 16:55:43 -0500 Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-5d3d0205bd5so316727a12.3 for <75521@debbugs.gnu.org>; Wed, 15 Jan 2025 13:55:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1736978135; x=1737582935; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=0ZZq/oKl1e/3dHWxXoyc9nX8yNEyp/hIxy4xPCDUOTs=; b=I4aq04P0Os85TXlEceLYJhmvsH3kQz2hRSU3j43T0kgv8AO1v953iPxI7OL4iVU/qd xDUnIJdDYi0UBu4t5enFygYCUH7nT6Zcw13JJngu21GNXrk6hNX4pPU+ejvsuOmi/Y2E c8dUPNC6qmGKAbrCufvcimQOO3zQSiTE1bc9Pmp6BN+5jecFKiybRozNZmCo5gzjo6Gu FNG1urAxnOFbktTgl3kM8RjVI3yhGbsbU1yf6d6wGeAoifi8let9rPnmGvNaJkb7dv8O 933kQY9ZlU94O3+V85uIoGvtD8CiRrpo9Fw0iaICIY1vS8RQ2a2hy6moSpd4RTmVvJD3 BXLw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736978135; x=1737582935; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=0ZZq/oKl1e/3dHWxXoyc9nX8yNEyp/hIxy4xPCDUOTs=; b=kVxQWZOPiiRs1BNfjwzEBk6ea1mZm69TpoB3EuqMTkVqBm1Bj+nLX4onNt7gav3IXL qvjS1o8zWumAFjWg0ivKNs06rJukHm6yRSPAgU1T/D7UyIwQjSMpINHwgYX3xXqZOXc0 8QjFaJFwl/e3xSXTRJo4FnsyrjqeQVlWKGGyIwEg70UxeZIHIvo87a/khTPUHv3UcrP4 eOv9vYgD2A6pU+zXlIBCzRgppvt7HFbiHDJbSu2GVYCA3gjM7NW/0hpqHUnoiaN20pP9 HcfoEV8eUDGpA0MUcYSfvqC9UrwxrmUH+EqGx5BnAZzwPtoP/FsLsAKZrWkZPxyGuqLg VAHw== X-Forwarded-Encrypted: i=1; AJvYcCUIMFXWu/9JJ95VLxc9fBEwXvlrgdLkA1j8lrMCTlqGfY+z9YCcSxccXjOvz2s0F/zvysDFOg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YybAegbBjMRYdSSp10mAhL4sIZ4m4UTFnTXX78JkRZR79rgyqkB Ppj605J2UvO9yjH82gODb/mPExB2QHSzYwTpfNxZQw/lNiWV1WkI7/lN9IgsmTOKRTs8KxRvOfD GWx5ZikTAXnsR7KGOlKEqEvRGaGM= X-Gm-Gg: ASbGnctXRkVkrffuDNVHX2+qHR5KoV1d+FEbJZXkHKCrjZBOvf79K+NtcnBu/9BeF1J FvZQPI9nwPvyspXMFG0CWs1P6Tm+sRAgW0iUNeIb9 X-Google-Smtp-Source: AGHT+IHkNSIuIZimaNnthTXuN6Az68jpHpTe4NkGtFUCkJMGRHEcQfpEABBsV1HugEOqQJYaZgakzHOmcTwU3Q72eMQ= X-Received: by 2002:a05:6402:1d50:b0:5da:ba6:3a3e with SMTP id 4fb4d7f45d1cf-5da0ba65cd7mr4139752a12.7.1736978135376; Wed, 15 Jan 2025 13:55:35 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Wed, 15 Jan 2025 13:55:35 -0800 From: Stefan Kangas In-Reply-To: <865xmfkdr2.fsf@gnu.org> References: <87r057tzjg.fsf@protonmail.com> <865xmiv81s.fsf@gnu.org> <86zfjutqy3.fsf@gnu.org> <86y0zet6md.fsf@gnu.org> <867c6wkwu1.fsf@gnu.org> <865xmfkdr2.fsf@gnu.org> MIME-Version: 1.0 Date: Wed, 15 Jan 2025 13:55:35 -0800 X-Gm-Features: AbW1kvZkrrreOtI5_uU7Q2ej3LBKS7pC-Gw24WWT2skX1LMC1eqkCxb3F23Rmjg Message-ID: Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX To: Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 1.0 (+) X-Debbugs-Envelope-To: 75521 Cc: 75521@debbugs.gnu.org, pipcet@protonmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Stefan Kangas >> Date: Wed, 15 Jan 2025 19:45:55 +0000 >> Cc: pipcet@protonmail.com, 75521@debbugs.gnu.org >> > Too bad you did that while we are still discussing the issue. Why the > haste? The result is that we now have confusing code, see below. Sorry, I thought we had agreed already. See below. > Heh, I was looking at these: > > void > defvar_lisp_nopro (struct Lisp_Fwd const *o_fwd, char const *namestring) > { > eassert (o_fwd->type == Lisp_Fwd_Obj); > Lisp_Object sym = intern_c_string (namestring); > XBARE_SYMBOL (sym)->u.s.declared_special = true; > XBARE_SYMBOL (sym)->u.s.redirect = SYMBOL_FORWARDED; > SET_SYMBOL_FWD (XBARE_SYMBOL (sym), o_fwd); > } > > void > defvar_lisp (struct Lisp_Fwd const *o_fwd, char const *namestring) > { > eassert (o_fwd->type == Lisp_Fwd_Obj); > defvar_lisp_nopro (o_fwd, namestring); > staticpro (o_fwd->u.objvar); > } > > (which are still different) because I remembered that the macros just > called the functions. And your changes didn't remove > defvar_lisp_nopro. Isn't that confusing? Aha, okay. I misunderstood your question. I didn't think it was worth ifdef'ing those two functions for HAVE_MPS, as I didn't consider that someone might find it confusing. Do you think it would be better if we did? From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 16 01:07:33 2025 Received: (at 75521) by debbugs.gnu.org; 16 Jan 2025 06:07:33 +0000 Received: from localhost ([127.0.0.1]:59698 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tYJ2T-0008Se-9k for submit@debbugs.gnu.org; Thu, 16 Jan 2025 01:07:33 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:58434) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tYJ2Q-0008SJ-OK for 75521@debbugs.gnu.org; Thu, 16 Jan 2025 01:07:31 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tYJ2K-0003JD-Vk; Thu, 16 Jan 2025 01:07:25 -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=tPoygf/kKVNkzUL6A16/H7RZE3CSES7Yr/PegNVA3Dw=; b=KxYUp468ik/a la+CCl4I4uNUFwu3rEE+VgU4wHs0Xse/8zD0WPOrlMMGqboRNzqYJCFY1awjTCI9Nw9LOl2hk+qDi 61mDMJxX6S/bgTOrQgEEfqBbq1KI9+mCqulwY2sNOw6OU38siQpL/fyELMA7Pvo7pHFMxWahKZxfC HC2Am3Ghogt/01szx5k/Q79dt/BNzHF5qUGOPudRgm3d1U7UmZZIHfJksFZa3X3CVJbq8JKsCSckA E5hDjwN+8qeHm7zW0UbLgcX2tN+FxV2dnejBgVPK/8J08OqZ84Jig0p1CIDc/qeuBTyB7OVMCKeni tPavc9xcS0CGY/MxPqv7SQ==; Date: Thu, 16 Jan 2025 08:07:20 +0200 Message-Id: <86y0zbi95z.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <87tt9zn60t.fsf@protonmail.com> (message from Pip Cet on Wed, 15 Jan 2025 21:04:14 +0000) Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX References: <86zfjutqy3.fsf@gnu.org> <86y0zet6md.fsf@gnu.org> <867c6wkwu1.fsf@gnu.org> <877c6wneww.fsf@protonmail.com> <867c6vkekg.fsf@gnu.org> <87tt9zn60t.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75521 Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Wed, 15 Jan 2025 21:04:14 +0000 > From: Pip Cet > Cc: stefankangas@gmail.com, 75521@debbugs.gnu.org > > "Eli Zaretskii" writes: > > >> It's not a fact, it's an individual opinion which virtually everyone > >> else disagrees with (for very good reasons). I certainly do. Literally > >> the only argument that has been advanced to support this *opinion* is > >> that removing the *three* remaining _NOPROs (which are, at this point, > >> NOT redundant, but buggy) would somehow cause us to run out of NSTATICS, > >> which would mean more than doubling our staticpro calls overnight, > >> adding more than a thousand staticpros. > > > > It isn't an opinion. Wasting memory is bad, period. > > This is too ridiculous to leave uncommented: Please be at least polite. > staticpro does not allocate or increase memory usage in any way. No > memory is wasted. staticvec has a static size, and memory in it > that's unused is not available for other purposes. AFAIU, it does increase memory because on modern OS only used memory is actually paged into the process. > (Of course, both the existence of a separate _NOPRO macro and the > now-redundant font_style_table vector do waste memory, which is one of > the reasons why my patch, which is being rejected because "wasting > memory is bad", removed them.) Memory "wasted" on code we need to have is not a waste. If we'd considered it to be a waste, none of the changes we install (including yours) will be acceptable, since almost all of them add code and/or data. > You claimed your opinion was a fact. That might have been an honest > mistake, but it was pointed out to you and you responded with another > falsehood. > > There's only so much good faith one can assume. Yes, and you are dangerously close to overstep that line. So please re-read all your recent messages, which almost always include some unwarranted personal attack on me, and try to find a way of arguing about technical matters without ad-hominem. GNU Kind Communications guidelines are in effect here, mandatory for all of us. From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 16 01:34:59 2025 Received: (at 75521) by debbugs.gnu.org; 16 Jan 2025 06:35:00 +0000 Received: from localhost ([127.0.0.1]:59732 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tYJT1-0001Ug-Ij for submit@debbugs.gnu.org; Thu, 16 Jan 2025 01:34:59 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:39548) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tYJSy-0001UQ-Li for 75521@debbugs.gnu.org; Thu, 16 Jan 2025 01:34:57 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tYJSs-0008Lb-UW; Thu, 16 Jan 2025 01:34:51 -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=zMOBdBVXszKi89Fde17pSOMbuEfOf7/qtZ+Fx5VmuAg=; b=OR1YLZQYbIDv DaehhRRpef9w81NgzLy0gUo4njZEVtTeIlLXvDfNKizECmgj33cgnt/Z0XFiKv0RW7riFwAAb6M3z gA9ZPeSR5r4oyW7BL6L1ucGPOY767JmaksBjUSdpWkYpxpGJBNSDcPfoX2cpvuNPqSsJBRKJZgyfX hS+ON/17twrpF4oEIzdg5Bv7xEikgJVtflwGA3hwkosQ+joDg3ORjAafY8goYVmBBwS7LERBsOOvC ijS+WuQTo6coYGaobWpTSP0IeJJMMoNOeTwJA4oQ170W2OYdkOnRebw4wuTGc2q9LKRG8ysFPXMk7 l6F9RocBLRZDkEiQrNqwhw==; Date: Thu, 16 Jan 2025 08:34:46 +0200 Message-Id: <86sepji7w9.fsf@gnu.org> From: Eli Zaretskii To: Stefan Kangas In-Reply-To: (message from Stefan Kangas on Wed, 15 Jan 2025 13:55:35 -0800) Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX References: <87r057tzjg.fsf@protonmail.com> <865xmiv81s.fsf@gnu.org> <86zfjutqy3.fsf@gnu.org> <86y0zet6md.fsf@gnu.org> <867c6wkwu1.fsf@gnu.org> <865xmfkdr2.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75521 Cc: 75521@debbugs.gnu.org, pipcet@protonmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Kangas > Date: Wed, 15 Jan 2025 13:55:35 -0800 > Cc: pipcet@protonmail.com, 75521@debbugs.gnu.org > > I didn't think it was worth ifdef'ing those two functions for HAVE_MPS, > as I didn't consider that someone might find it confusing. Do you think > it would be better if we did? I think defvar_lisp_nopro should be a static function in the HAVE_MPS build, since it will not be called from anywhere but defvar_lisp. And its commentary should be changed accordingly. I'd also appreciate a comment for DEFVAR_LISP_NOPRO in lisp.h, explaining what it does and saying that it is only used in non-MPS build. I can make these changes myself, if you prefer. From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 16 10:54:55 2025 Received: (at 75521) by debbugs.gnu.org; 16 Jan 2025 15:54:55 +0000 Received: from localhost ([127.0.0.1]:34311 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tYSCt-00047C-G2 for submit@debbugs.gnu.org; Thu, 16 Jan 2025 10:54:55 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:43666) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1tYSCq-00046r-NU for 75521@debbugs.gnu.org; Thu, 16 Jan 2025 10:54:53 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tYSCl-0007TU-84; Thu, 16 Jan 2025 10:54:47 -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=qkWFvQ3XkdWAe00uaSQ6LbhNVnHD9b+39suNsZsXYAg=; b=Mr8ZtDgKdwco VGFNXgXsf6kX6UHn+1Vc+86NVhK7asYpWQ6Qk7tFMkzwuI57otmOxcNzQg77u3WceUI0kI1i8A2US qHCvK0ohyIAbssYVUKxYPhKSaaZ3T7UYF7Iw1tDUBqjmFDt/2xUQFdRwkKlywuFXc4eztFzDuRxND wD2sZQBi9qUGhcDyJKNpY3R30MZxp6G7ID+rD5mAPxXLUvpkRyFjvXImn7Zcu+fLTIHJsGBUmN2TD L0R3r7F9+EpYKITa7inCuZ9lNY7EZ/NxpYux1p6A1PtQrWN75Se4ktBy3cWFrl1csSzKIJ+E4uZO/ NWQYI7RD7zQZP6SSDTCBZw==; Date: Thu, 16 Jan 2025 17:54:14 +0200 Message-Id: <86a5bqhhzt.fsf@gnu.org> From: Eli Zaretskii To: Pip Cet In-Reply-To: <877c6xoy65.fsf@protonmail.com> (message from Pip Cet on Tue, 14 Jan 2025 21:58:37 +0000) Subject: Re: bug#75521: scratch/igc: Delete unused macro DEFVAR_LISP_NOPROX References: <867c6yv910.fsf@gnu.org> <87ldveseso.fsf@protonmail.com> <864j22v76f.fsf@gnu.org> <87cygqsd0q.fsf@protonmail.com> <861px6v5om.fsf@gnu.org> <86cygptmhi.fsf@gnu.org> <87y0zdpbvd.fsf@protonmail.com> <865xmht854.fsf@gnu.org> <877c6xoy65.fsf@protonmail.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 75521 Cc: 75521@debbugs.gnu.org, stefankangas@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Tue, 14 Jan 2025 21:58:37 +0000 > From: Pip Cet > Cc: stefankangas@gmail.com, 75521@debbugs.gnu.org > > > I was asking about the problem where that code makes the values of > > Vfont_weight_table and its 2 brethren vulnerable to being GC'ed. > > That's the only problem I tried to solve with that patch. That > > Vfont_weight_table etc. are also updated to reflect the changes in > > font_style_table is a nice benefit. > > Not really a benefit: updating the variables might expose other > (crashable) bugs more. > > > If you agree that this problem will be solved by the patch, then I'd > > like to install it, because it's very simple and localized, so the > > risk to break something is IMO very low. > > It introduces what are effectively new crashable bugs by attempting to > fix old ones. I'm neutral: installing this patch won't improve things > significantly, but if you think there might be a slight improvement, you > probably have your reasons. Thanks, so I've now installed the patch on the master branch. From unknown Tue Jun 17 01:43:53 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 14 Feb 2025 12:24:13 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator