Received: (at 80474) by debbugs.gnu.org; 28 Feb 2026 16:06:12 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 28 11:06:11 2026
Received: from localhost ([127.0.0.1]:37993 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vwMpX-0001F3-Ag
for submit <at> debbugs.gnu.org; Sat, 28 Feb 2026 11:06:11 -0500
Received: from mail-wm1-x330.google.com ([2a00:1450:4864:20::330]:55739)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <eller.helmut@HIDDEN>)
id 1vwMpU-0001Eq-2C
for 80474 <at> debbugs.gnu.org; Sat, 28 Feb 2026 11:06:09 -0500
Received: by mail-wm1-x330.google.com with SMTP id
5b1f17b1804b1-4836f363d0dso24850955e9.3
for <80474 <at> debbugs.gnu.org>; Sat, 28 Feb 2026 08:06:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1772294766; x=1772899566; 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=eV4SslCSGn0BNvKn8rKl7KqVWpTEi97SSfYey7lvKSI=;
b=k32WjFnOVA/iItCDOMMdOWiiF+xX7HDBtyntZOHhcyFlLR3wI3g6l8XKd4xtwOANTi
UbI1WFcqudSOvjBa0IFsJEsh1oSg85SZqizwUIXryOwQ5moeLU7iKnZNz3sbJNCQPV6u
otBGZkeFEbg4QKxF8PpWCSHZbywoJdcGSaWK8rlzaRjN3T+A7KjeOndPyaevrjz+Ud3r
5yZbvuYuJ/vq51xaW7wBu9G/7oWTNi2g0ByTfk/nCQulHNEj8BtblWvH1w0O9+WNctiK
q1Q8f4u3VSvNs3aK2HGQpHrgnm5vxdcBsVbYeWOExZGTXlCerTgXmTIXH3RnmVpH2sSZ
PkKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1772294766; x=1772899566;
h=mime-version:user-agent:message-id:date:references:in-reply-to
:subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject
:date:message-id:reply-to;
bh=eV4SslCSGn0BNvKn8rKl7KqVWpTEi97SSfYey7lvKSI=;
b=u+r7Va4Ye3tFsz6XD4XnezfUvPaslzLfKEWvaH3ap4BH03AVuC4MGEeG85QW3rPYIR
laDiiNcDB35jJ3VS58Q3PB6bm1yaAj2Pvy/KUoYXA3uOE6o8QWslZAYwFWJfyLtWtRcc
NGC55qcxLkpanGUuQxz9JCsI2NnWLoZsgKGr3XvboH4wBubJkQ8g2qmQFTYcJIamMoST
j4Q3y9CGryihPFdZxnvR0MO9y4bdkj3w6O9ioW6O4vUtHOorOFop+CeQX0imEpIMa35a
6fK4yMGbXgr65p0UGcyZMarAl/AvsQwzaaYMjvS0eZmpWSUdWz1WjPBvqdFx79uTKxvI
1PNA==
X-Forwarded-Encrypted: i=1;
AJvYcCVV1EPhOPcO+wTxRawIM3oMXSc7FtBswwsBf6ASYcTYOPGmo+Z61HoYInPQeYxi8EZ8nBfhxw==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YxPyCbOv1KLtB0DtLWGWGa4zhJ6IXGqVAtgTTvrq0OOQyGBTa3f
tKwpbfwwxoN6siJ/V7KN0bW4igi/7c1nV3yxlAa8IUnwBM5A0U4NNkDK
X-Gm-Gg: ATEYQzznuHLWRHi0gJsOfgGGvSaeCxUzYpjQ+A01arQUKr7o4GWw/4+A/Zf14nE9vj0
GXvjZzrRE9Zn0iwRklIsha//sAIOuvBoFX91F+ATMTop4sneA3r8+TMURIttZSeA779jzArdiJ+
eyrw0lh5PgPjy1Ioy3RLiX1zZxK65+Azd4gSutGLKLtVM1AsifHpprOR1kguiQCZNqmmuZpWi78
WccgXsf+i53wlGRlVWYV8m4SY6WBJq2yIBA72MZqjDuacXwNPF6gBxJ3wN1ZlQh4xxeVjqm3DPI
sDlgz060jwoiW7whBxJgr4iLanJsmz05pWbbbPTF7Z+wxPW3PNQXtyY25AjIXaba2SPGJhpEQm7
+HXHNVq/g+pY69r9Ilo0IAWj3AaYSIM19XXCXi1jovUlfV/wTwAACoPdsh7s4bllqvU4IAWTWm5
7WPYqzpXN1gc+R4wQR5Q==
X-Received: by 2002:a05:600c:4f07:b0:477:63a4:88fe with SMTP id
5b1f17b1804b1-483c9bb1c13mr127112945e9.2.1772294766277;
Sat, 28 Feb 2026 08:06:06 -0800 (PST)
Received: from caladan ([212.46.170.2]) by smtp.gmail.com with ESMTPSA id
ffacd0b85a97d-439b03db76bsm66534f8f.18.2026.02.28.08.06.05
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Sat, 28 Feb 2026 08:06:05 -0800 (PST)
From: Helmut Eller <eller.helmut@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: 31.0.50; [PATCH] charset_table split
In-Reply-To: <861pi43n9y.fsf@HIDDEN>
References: <871pia9y7m.fsf@HIDDEN> <86cy1u9lbe.fsf@HIDDEN>
<jwvtsv5c1kd.fsf-monnier+emacs@HIDDEN> <86h5r57zki.fsf@HIDDEN>
<87342nabs9.fsf@HIDDEN> <861pi77dq6.fsf@HIDDEN>
<87wlzxkx02.fsf@HIDDEN> <86bjh93yuv.fsf@HIDDEN>
<87bjh9krpb.fsf@HIDDEN> <86342l3vdp.fsf@HIDDEN>
<87sealjaci.fsf@HIDDEN> <861pi43n9y.fsf@HIDDEN>
Date: Sat, 28 Feb 2026 17:06:04 +0100
Message-ID: <87h5r0kg43.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 80474
Cc: handa@HIDDEN, 80474 <at> debbugs.gnu.org, eggert@HIDDEN,
monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)
On Sat, Feb 28 2026, Eli Zaretskii wrote:
>> From: Helmut Eller <eller.helmut@HIDDEN>
>> Cc: monnier@HIDDEN, handa@HIDDEN, 80474 <at> debbugs.gnu.org,
>> eggert@HIDDEN
>> Date: Sat, 28 Feb 2026 13:55:57 +0100
>>
>> On Sat, Feb 28 2026, Eli Zaretskii wrote:
>>
>> >> >> + if (charset_table.size > charset_table.used)
>> >> >> + {
>> >> >> + eassert (!pdumper_object_p (charset_table.start));
>> >> >> + charset_table.start
>> >> >> + = xnrealloc (charset_table.start, charset_table.used,
>> >> >> + sizeof *charset_table.start);
>> >> >
>> >> > Why the assertion there? what's wrong with having this in the pdumper
>> >> > file?
>> >>
>> >> xnrealloc doesn't work with pdumper objects. By contrast, the sequence
>> >> xmalloc/memcpy/xfree does because xfree ignores pdumper objects.
>> >
>> > I understand, but why cannot we support both cases, each one as it
>> > should be? Or am I missing something?
>>
>> In practice, the charset table only grows and size > used only happens
>> if it was xmalloc'd. Supporting the other case would be possible but
>> it's not needed and using xnrealloc, as Paul suggested, would then make
>> little sense.
>
> What if someone re-dumps Emacs?
>
> Yes, we don't currently support that yet in full, so in some cases
> this works and in others it doesn't. But I would like to at least not
> add to the problems we have in that area. So if re-dumping could
> trigger the assertion, I'd prefer a solution which won't.
That should be covered by the same argument. The dumper guarantees that
size == used. To have size > used, one must over-allocate via
Fdefine_charset_internal.
bug-gnu-emacs@HIDDEN:bug#80474; Package emacs.
Full text available.
Received: (at 80474) by debbugs.gnu.org; 28 Feb 2026 15:23:36 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 28 10:23:36 2026
Received: from localhost ([127.0.0.1]:37809 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vwMAJ-0006H4-Ji
for submit <at> debbugs.gnu.org; Sat, 28 Feb 2026 10:23:35 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:53778)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vwMAF-0006Gi-OT
for 80474 <at> debbugs.gnu.org; Sat, 28 Feb 2026 10:23:33 -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 <eliz@HIDDEN>)
id 1vwMA9-0007Th-79; Sat, 28 Feb 2026 10:23: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=ohrX1wgNEekWq8pwvLlhzp4n/BxAkH8I0c/mn7bAEIg=; b=UnZfUh/AP7Wg
EsreoBOk2kKETB49oBQwEo9/dQnUbhZOs/ujYtXKQdGOpIIYFDULI5lv3y5tAIkJYSmyq57hDhyLc
9cJX16HCEYKXTVlmtyye5zgzTk9UhdwScviNTWOgdFf9Cbik3H7L7W7CYTKCN0dG4If3OwLE9j/CR
ewgvk3eoiyTWjXMWmTMrBiXXwPPX7i9gHzeynl7uS2GfGIFas8wqUqOnbr+q6y01+ORePLZuixbxZ
krsuxFz0SJoTF6ZHOrH0rLwqgK76Ae4XbVA/V+UswFBC0O30Expm0LbaTLYgOHcAKzevefi/R5U2A
2o8hRv9RXsb1W15omX6kZQ==;
Date: Sat, 28 Feb 2026 17:23:21 +0200
Message-Id: <861pi43n9y.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Helmut Eller <eller.helmut@HIDDEN>
In-Reply-To: <87sealjaci.fsf@HIDDEN> (message from Helmut Eller on Sat, 28
Feb 2026 13:55:57 +0100)
Subject: Re: 31.0.50; [PATCH] charset_table split
References: <871pia9y7m.fsf@HIDDEN> <86cy1u9lbe.fsf@HIDDEN>
<jwvtsv5c1kd.fsf-monnier+emacs@HIDDEN> <86h5r57zki.fsf@HIDDEN>
<87342nabs9.fsf@HIDDEN> <861pi77dq6.fsf@HIDDEN>
<87wlzxkx02.fsf@HIDDEN> <86bjh93yuv.fsf@HIDDEN>
<87bjh9krpb.fsf@HIDDEN> <86342l3vdp.fsf@HIDDEN> <87sealjaci.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 80474
Cc: handa@HIDDEN, 80474 <at> debbugs.gnu.org, eggert@HIDDEN,
monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> From: Helmut Eller <eller.helmut@HIDDEN>
> Cc: monnier@HIDDEN, handa@HIDDEN, 80474 <at> debbugs.gnu.org,
> eggert@HIDDEN
> Date: Sat, 28 Feb 2026 13:55:57 +0100
>
> On Sat, Feb 28 2026, Eli Zaretskii wrote:
>
> >> >> + if (charset_table.size > charset_table.used)
> >> >> + {
> >> >> + eassert (!pdumper_object_p (charset_table.start));
> >> >> + charset_table.start
> >> >> + = xnrealloc (charset_table.start, charset_table.used,
> >> >> + sizeof *charset_table.start);
> >> >
> >> > Why the assertion there? what's wrong with having this in the pdumper
> >> > file?
> >>
> >> xnrealloc doesn't work with pdumper objects. By contrast, the sequence
> >> xmalloc/memcpy/xfree does because xfree ignores pdumper objects.
> >
> > I understand, but why cannot we support both cases, each one as it
> > should be? Or am I missing something?
>
> In practice, the charset table only grows and size > used only happens
> if it was xmalloc'd. Supporting the other case would be possible but
> it's not needed and using xnrealloc, as Paul suggested, would then make
> little sense.
What if someone re-dumps Emacs?
Yes, we don't currently support that yet in full, so in some cases
this works and in others it doesn't. But I would like to at least not
add to the problems we have in that area. So if re-dumping could
trigger the assertion, I'd prefer a solution which won't.
Thanks.
bug-gnu-emacs@HIDDEN:bug#80474; Package emacs.
Full text available.
Received: (at 80474) by debbugs.gnu.org; 28 Feb 2026 12:56:07 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 28 07:56:07 2026
Received: from localhost ([127.0.0.1]:35325 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vwJrb-0003QL-5T
for submit <at> debbugs.gnu.org; Sat, 28 Feb 2026 07:56:07 -0500
Received: from mail-wr1-x42a.google.com ([2a00:1450:4864:20::42a]:51534)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <eller.helmut@HIDDEN>)
id 1vwJrU-0003PZ-Ae
for 80474 <at> debbugs.gnu.org; Sat, 28 Feb 2026 07:56:05 -0500
Received: by mail-wr1-x42a.google.com with SMTP id
ffacd0b85a97d-436309f1ad7so2383732f8f.3
for <80474 <at> debbugs.gnu.org>; Sat, 28 Feb 2026 04:56:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1772283359; x=1772888159; 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=nYP6yDVXj9pn3fMu45ip4QcGr38KfTt0c/iMcWaxXgg=;
b=E5G5CDD8NnZX65amSoVS6Z9OFJte7+awaryfD/YA97sdexmatwZNcm/xb6CRcHDyBo
l65MpHVVQqBXtQFWGZnCBpvOUL+hwuh5Mb6G/ZXyXDjoD3Gx8I1gsefNdUcKo/mL33WU
Dhn3SsyirN4K9MKWo+bjq1BkPFLlxexGTCaR6Pxctd64yrf+0pqoVc0l7kXf+ak8Gwx3
9odbjOwecFgLqehF0aEUsm5ELuGJA/+tbp9eFdOQAR+/VUpuXyFZErEp+jxXd1yaSHI9
wfnR5wsiTWBCA8OJjQb9qq7Ez85p72HF9EqEKPKlhjVX1ZaXWOXaM4xLNuALg6X8y8WY
E+Yw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1772283359; x=1772888159;
h=mime-version:user-agent:message-id:date:references:in-reply-to
:subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject
:date:message-id:reply-to;
bh=nYP6yDVXj9pn3fMu45ip4QcGr38KfTt0c/iMcWaxXgg=;
b=XNTXBfiN+7cPHD5xa8MKAL/zn8VGNHVpX0rK16uZQAwQY4IA/jdYTMq2hA2sF4hGyv
t5RYHyBWh5g/YQX0RBTFm/AsKVYplUyFEzbHYsxg/0YNXjJYl9nAUR5fh8nkcbuF19cI
Ih804recBbigSNyGF2D0Jg4vNzdXZpA+L2g735Q/lWhDhi0OHDmVeFmprpQRVzvWPCj6
7hP0gB23rb3yHTDMYp2bO88VAilQzcfhKqWarlc8tbQC8D2Aob9fCifrof4i3KsH+rbk
fh6Cta0uAyWajlTfJKxoGnSGdS5pdrARmg7QxClA/dyNiBAGd+ND1f8mn76BqwDB16fK
NEWg==
X-Forwarded-Encrypted: i=1;
AJvYcCVfYxBI9OcHSXFvcjNEAJo/25w0CKLBDxnPwp5qoCbhrFaHaMHddKKLu1A2H9LQxedgQ+vp1A==@debbugs.gnu.org
X-Gm-Message-State: AOJu0Yxe+aje73tToEmu+FyUJXnvpPfrYI8tEJKCZAE+p0Sdn9ORxMEN
4DzCvXEKGpDTh0AHI4yjgX+jELIvRCjMdBFGUeXVyC2Ns58II5/rC2MW
X-Gm-Gg: ATEYQzxlPk6j+LiSrYJGrgZ+2SdZG2b/iKU65DBzqEprx8Qw7nc6mKTRsp0F92RMkkf
1EelBJdTQdbV2o8MVIZ+7afAW6ygwHaXZBRCL1krIMt/w1YDHYMJaDQpYFruHIrvPOqTpSdXi5C
/pinxtdj8jcp+aeNCd6oVkkIXWzjVf8nMgW6AajhbWfsJrgMpGS1JCXOKbfShvRY4WICyufvsSh
5ckoW0e6MM6b8/UbX2X9rWILxnAQXBJO7m1jbySeWZDYiZ6h7VBapNWU1F8J+/qYJAm8BBHuDno
iSs4e0/vznhROYCbV62hHN6nCmGrBWfmbEzvWMrecIAS7FXUg/BeyBY8jhgf1oPsQ8au1Qqe7fp
r2UsXNUBrsBylDf/FEuy/hDiFbPbLiMkPaTpUPJ6lm0Robnd30D1rAkm2gDIgwhgyDJhAtbfz7L
rzxhyKnT6gs2WlOijHZg==
X-Received: by 2002:a05:600c:4ed1:b0:483:7f4e:fef6 with SMTP id
5b1f17b1804b1-483c9bc58a3mr89504875e9.26.1772283358887;
Sat, 28 Feb 2026 04:55:58 -0800 (PST)
Received: from caladan ([212.46.170.2]) by smtp.gmail.com with ESMTPSA id
5b1f17b1804b1-483bd765604sm244233405e9.15.2026.02.28.04.55.57
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Sat, 28 Feb 2026 04:55:58 -0800 (PST)
From: Helmut Eller <eller.helmut@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: 31.0.50; [PATCH] charset_table split
In-Reply-To: <86342l3vdp.fsf@HIDDEN>
References: <871pia9y7m.fsf@HIDDEN> <86cy1u9lbe.fsf@HIDDEN>
<jwvtsv5c1kd.fsf-monnier+emacs@HIDDEN> <86h5r57zki.fsf@HIDDEN>
<87342nabs9.fsf@HIDDEN> <861pi77dq6.fsf@HIDDEN>
<87wlzxkx02.fsf@HIDDEN> <86bjh93yuv.fsf@HIDDEN>
<87bjh9krpb.fsf@HIDDEN> <86342l3vdp.fsf@HIDDEN>
Date: Sat, 28 Feb 2026 13:55:57 +0100
Message-ID: <87sealjaci.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 80474
Cc: handa@HIDDEN, 80474 <at> debbugs.gnu.org, eggert@HIDDEN,
monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)
On Sat, Feb 28 2026, Eli Zaretskii wrote:
>> >> + if (charset_table.size > charset_table.used)
>> >> + {
>> >> + eassert (!pdumper_object_p (charset_table.start));
>> >> + charset_table.start
>> >> + = xnrealloc (charset_table.start, charset_table.used,
>> >> + sizeof *charset_table.start);
>> >
>> > Why the assertion there? what's wrong with having this in the pdumper
>> > file?
>>
>> xnrealloc doesn't work with pdumper objects. By contrast, the sequence
>> xmalloc/memcpy/xfree does because xfree ignores pdumper objects.
>
> I understand, but why cannot we support both cases, each one as it
> should be? Or am I missing something?
In practice, the charset table only grows and size > used only happens
if it was xmalloc'd. Supporting the other case would be possible but
it's not needed and using xnrealloc, as Paul suggested, would then make
little sense.
bug-gnu-emacs@HIDDEN:bug#80474; Package emacs.
Full text available.
Received: (at 80474) by debbugs.gnu.org; 28 Feb 2026 12:28:30 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 28 07:28:30 2026
Received: from localhost ([127.0.0.1]:35256 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vwJQr-00077e-Tz
for submit <at> debbugs.gnu.org; Sat, 28 Feb 2026 07:28:30 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:54032)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vwJQp-00077K-KJ
for 80474 <at> debbugs.gnu.org; Sat, 28 Feb 2026 07:28:28 -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 <eliz@HIDDEN>)
id 1vwJQi-00044A-Vg; Sat, 28 Feb 2026 07:28:21 -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=aZ3PbWqQxgE4HH3WhaGtsfM6IWgM8GraYCeHhGmSo3U=; b=kjxNoljq6DPU
NBzx5XsvNN+4oGeBSLPhpuy7i+q+a+ZPobocaJzISeyildtPdl9JrIAGcgRNUYsecI5GyUS89iR8o
Wf0u8+nNWDim8DDaDZpg3JQs0P7C6vKoD5SkQhCEjKi0vVGzaldkyiSW0ztXERbQKVBfHwNU2HFle
7CoVu10TInp4S7xV3lLkvotUTeW1fw2MnQ10fH3i9ibO9v99DlWOtz+04oixwwWi6g1DFig0L4ycU
z6mfGubxMfKn33h536Ha/sQNhLPsQW6GEI0/Ftz7d/tVR3+XzC35Dlh1531UdBNiKi6PNTBJCJwpQ
FVMf4n6Mp7JJIuFpbKp4Hg==;
Date: Sat, 28 Feb 2026 14:28:18 +0200
Message-Id: <86342l3vdp.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Helmut Eller <eller.helmut@HIDDEN>
In-Reply-To: <87bjh9krpb.fsf@HIDDEN> (message from Helmut Eller on Sat, 28
Feb 2026 12:55:44 +0100)
Subject: Re: 31.0.50; [PATCH] charset_table split
References: <871pia9y7m.fsf@HIDDEN> <86cy1u9lbe.fsf@HIDDEN>
<jwvtsv5c1kd.fsf-monnier+emacs@HIDDEN> <86h5r57zki.fsf@HIDDEN>
<87342nabs9.fsf@HIDDEN> <861pi77dq6.fsf@HIDDEN>
<87wlzxkx02.fsf@HIDDEN> <86bjh93yuv.fsf@HIDDEN>
<87bjh9krpb.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 80474
Cc: handa@HIDDEN, 80474 <at> debbugs.gnu.org, eggert@HIDDEN,
monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> From: Helmut Eller <eller.helmut@HIDDEN>
> Cc: monnier@HIDDEN, handa@HIDDEN, 80474 <at> debbugs.gnu.org,
> eggert@HIDDEN
> Date: Sat, 28 Feb 2026 12:55:44 +0100
>
> On Sat, Feb 28 2026, Eli Zaretskii wrote:
>
> >> From: Helmut Eller <eller.helmut@HIDDEN>
> >> Cc: monnier@HIDDEN, handa@HIDDEN, 80474 <at> debbugs.gnu.org,
> >> eggert@HIDDEN
> >> Date: Sat, 28 Feb 2026 11:01:17 +0100
> >>
> >> Would it be ok to commit it with the additional patches below?
> >
> > Yes, but please wait for Stefan and Paul to review as well.
>
> Ok.
>
> >> + if (charset_table.size > charset_table.used)
> >> + {
> >> + eassert (!pdumper_object_p (charset_table.start));
> >> + charset_table.start
> >> + = xnrealloc (charset_table.start, charset_table.used,
> >> + sizeof *charset_table.start);
> >
> > Why the assertion there? what's wrong with having this in the pdumper
> > file?
>
> xnrealloc doesn't work with pdumper objects. By contrast, the sequence
> xmalloc/memcpy/xfree does because xfree ignores pdumper objects.
I understand, but why cannot we support both cases, each one as it
should be? Or am I missing something?
bug-gnu-emacs@HIDDEN:bug#80474; Package emacs.
Full text available.
Received: (at 80474) by debbugs.gnu.org; 28 Feb 2026 11:55:53 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 28 06:55:53 2026
Received: from localhost ([127.0.0.1]:34966 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vwIvI-0004dZ-Og
for submit <at> debbugs.gnu.org; Sat, 28 Feb 2026 06:55:53 -0500
Received: from mail-wm1-x336.google.com ([2a00:1450:4864:20::336]:48275)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <eller.helmut@HIDDEN>)
id 1vwIvF-0004dD-3e
for 80474 <at> debbugs.gnu.org; Sat, 28 Feb 2026 06:55:51 -0500
Received: by mail-wm1-x336.google.com with SMTP id
5b1f17b1804b1-483770e0b25so25584445e9.0
for <80474 <at> debbugs.gnu.org>; Sat, 28 Feb 2026 03:55:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1772279748; x=1772884548; 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=O9qQt3ecOf1AiVZAcOOWSReyC40ep+P/3fcNPj9BDq4=;
b=VkGjc+NwzUDowizlgOSv2urSgdT17GLgGvAM8SSuN5QTs79lXIxKuZBuFJgZN5qOuv
T5RyckNzD/EfaHrWGQ7OAXZLtQXzBIcHYSkJGKyHSHt5OOmLpIhbRa+th5UX4ZJHi4N2
onYT+23G+YgyViblqDXzJYscB/pNElKja9e/nhrHoo0m8DqMd0gCLs0AUOwgIuiMfMw8
iCA6D/woNe5s0jpvk/XzFYK+AEE/Mio1X9nMc/v3KBqaTW5igki7Vs0EsTO2NrVyXkcv
OxJJV6tYFPls8u66UyHqTQdrHlL4QJHN2P+b4PCGXnPWffTlDgim8v2AeFYmTmx+AObD
a0Gw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1772279748; x=1772884548;
h=mime-version:user-agent:message-id:date:references:in-reply-to
:subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject
:date:message-id:reply-to;
bh=O9qQt3ecOf1AiVZAcOOWSReyC40ep+P/3fcNPj9BDq4=;
b=Vh5yMO6cHrN2AC0aEnRLohexRA8I4KI79nYCkHQFBIesgOZqbzop1J7glxlSdbuu9a
CjSpManOxbn9KAxV7XxEup6Del/zX8dfDdrNRv6gNAnpzYMdbkitErlkDN/Vw00qNtqM
Ep/lN13738l91w/YdWiaFdDS2Q2xZL4jlwb8XomFsNMadqRb8txAHvthRQXR+dmPPkJn
dTfSTnOez4MrTO+9W2kVESIRxOTpd83lY4dEnrooP5arnqNdohwK83ywDYADVbj7H64X
tSW8xgY0WuovLf6pxZgYUBvRdKoIhpSnqAXofkS9KJQnwzFciwS/8/bGzg9nW4e8g3PL
lG3A==
X-Forwarded-Encrypted: i=1;
AJvYcCWL8F9tr/7TRWY4iIA7y3V5srE3zCNWrI98QUs9sva/mlojNcU5RusSgDCJzbbNraKJbD9MeQ==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YwepwM3RJ4gRqU9z8Un/0Jbv5b6CPk5gWf5jKZU0h5OhXhHk4VW
DeUqMhKzRfa3BkVzoe7jMgotdxXjTyFAzeVzzbkKERJiGJu3wEe0JtoD
X-Gm-Gg: ATEYQzzXIsexkzgBMHm5uaQDJCoZ9ivnGfE1bGJrVEFmL2ZNkCYVaEPWzZ8OyotmdSO
jqcH/w2JtenMNN9pek79+v58F5Yk66E+i7qMDVtEsG6CpHGGoupIq77kL1i1HqB728kY/CGWD8y
WeNi5jHMt6hoZpGrqFI4L5s9pMx7tDdoW6T4kmk+rTOQZpPZtK38IFTWehFNDdb0OjmdPj8blKQ
0rNQBkWmisF6oGz991C37rYsmHF5FmDE7CLv0QGc1COs7fui/ELWv9tw5NVMIn3Cb1/wRt8HM4O
Pu2bzYOuIV8O4maxLedwmEeq0KXzUkLtTwOkd0UKxsVamE7yakdoUGZZbgOXa7ttPIepK6wi6Mn
nEI01jT4oqw9QkHQAH+m0/etby6SDr3lMGrdoAJwW+Sr+VHwF+mnIVx6HkTn5qdY2f9jeZbYHJX
aTAHVBs12Z3QAP9Uk3SA==
X-Received: by 2002:a05:600c:4e51:b0:483:a27e:6706 with SMTP id
5b1f17b1804b1-483c9bdb288mr93013715e9.9.1772279747466;
Sat, 28 Feb 2026 03:55:47 -0800 (PST)
Received: from caladan ([212.46.170.2]) by smtp.gmail.com with ESMTPSA id
5b1f17b1804b1-483bfba9566sm127011575e9.3.2026.02.28.03.55.46
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Sat, 28 Feb 2026 03:55:46 -0800 (PST)
From: Helmut Eller <eller.helmut@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: 31.0.50; [PATCH] charset_table split
In-Reply-To: <86bjh93yuv.fsf@HIDDEN>
References: <871pia9y7m.fsf@HIDDEN> <86cy1u9lbe.fsf@HIDDEN>
<jwvtsv5c1kd.fsf-monnier+emacs@HIDDEN> <86h5r57zki.fsf@HIDDEN>
<87342nabs9.fsf@HIDDEN> <861pi77dq6.fsf@HIDDEN>
<87wlzxkx02.fsf@HIDDEN> <86bjh93yuv.fsf@HIDDEN>
Date: Sat, 28 Feb 2026 12:55:44 +0100
Message-ID: <87bjh9krpb.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 80474
Cc: handa@HIDDEN, 80474 <at> debbugs.gnu.org, eggert@HIDDEN,
monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)
On Sat, Feb 28 2026, Eli Zaretskii wrote:
>> From: Helmut Eller <eller.helmut@HIDDEN>
>> Cc: monnier@HIDDEN, handa@HIDDEN, 80474 <at> debbugs.gnu.org,
>> eggert@HIDDEN
>> Date: Sat, 28 Feb 2026 11:01:17 +0100
>>
>> Would it be ok to commit it with the additional patches below?
>
> Yes, but please wait for Stefan and Paul to review as well.
Ok.
>> + if (charset_table.size > charset_table.used)
>> + {
>> + eassert (!pdumper_object_p (charset_table.start));
>> + charset_table.start
>> + = xnrealloc (charset_table.start, charset_table.used,
>> + sizeof *charset_table.start);
>
> Why the assertion there? what's wrong with having this in the pdumper
> file?
xnrealloc doesn't work with pdumper objects. By contrast, the sequence
xmalloc/memcpy/xfree does because xfree ignores pdumper objects.
Helmut
bug-gnu-emacs@HIDDEN:bug#80474; Package emacs.
Full text available.
Received: (at 80474) by debbugs.gnu.org; 28 Feb 2026 11:13:27 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 28 06:13:27 2026
Received: from localhost ([127.0.0.1]:34673 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vwIGE-0001P5-UO
for submit <at> debbugs.gnu.org; Sat, 28 Feb 2026 06:13:27 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:47420)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vwIGB-0001Oc-Pi
for 80474 <at> debbugs.gnu.org; Sat, 28 Feb 2026 06:13: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 <eliz@HIDDEN>)
id 1vwIG5-0007WD-61; Sat, 28 Feb 2026 06:13:17 -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=qF+qtGQVceDkGPCUnHrSJy4CHEt27hZ5ychEyYACoAY=; b=Gv/iWGZcoLMV
R97cCJapjZD/rfLKDHoMhOxkahEQR4IdnOd6vEPOUfdbEVLYBFVzyaNjdv08RouLVJ0SNAtVd6nxy
ATe+uKSLJDB2Doiqis6BjnGhC7EgZsLqj5uMeyMDl+IvccOZIRJ7E+68fy/XS+knKvLmVirobfwr4
wn+NyFFLWMOA7HezAJms0apea/c1psLUfIdTF9ojS6nGbxGhCPj7xdCzZgQzH3ac4W4xo1QBC7De2
XM5l+CoNqmihRZZmUYotMWbTKHc6cGGI1R8tdZKOgR1urM2lh9we50VwWXPf2ahvweKMl0Ii/FwxM
XY1br4a1rU3aOM9b8zlQWw==;
Date: Sat, 28 Feb 2026 13:13:12 +0200
Message-Id: <86bjh93yuv.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Helmut Eller <eller.helmut@HIDDEN>
In-Reply-To: <87wlzxkx02.fsf@HIDDEN> (message from Helmut Eller on Sat, 28
Feb 2026 11:01:17 +0100)
Subject: Re: 31.0.50; [PATCH] charset_table split
References: <871pia9y7m.fsf@HIDDEN> <86cy1u9lbe.fsf@HIDDEN>
<jwvtsv5c1kd.fsf-monnier+emacs@HIDDEN> <86h5r57zki.fsf@HIDDEN>
<87342nabs9.fsf@HIDDEN> <861pi77dq6.fsf@HIDDEN> <87wlzxkx02.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 80474
Cc: handa@HIDDEN, 80474 <at> debbugs.gnu.org, eggert@HIDDEN,
monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> From: Helmut Eller <eller.helmut@HIDDEN>
> Cc: monnier@HIDDEN, handa@HIDDEN, 80474 <at> debbugs.gnu.org,
> eggert@HIDDEN
> Date: Sat, 28 Feb 2026 11:01:17 +0100
>
> Would it be ok to commit it with the additional patches below?
Yes, but please wait for Stefan and Paul to review as well.
> + if (charset_table.size > charset_table.used)
> + {
> + eassert (!pdumper_object_p (charset_table.start));
> + charset_table.start
> + = xnrealloc (charset_table.start, charset_table.used,
> + sizeof *charset_table.start);
Why the assertion there? what's wrong with having this in the pdumper
file?
bug-gnu-emacs@HIDDEN:bug#80474; Package emacs.
Full text available.
Received: (at 80474) by debbugs.gnu.org; 28 Feb 2026 10:01:28 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Feb 28 05:01:27 2026
Received: from localhost ([127.0.0.1]:34251 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vwH8Y-0001U6-2M
for submit <at> debbugs.gnu.org; Sat, 28 Feb 2026 05:01:27 -0500
Received: from mail-wm1-x333.google.com ([2a00:1450:4864:20::333]:51607)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <eller.helmut@HIDDEN>)
id 1vwH8V-0001Tj-5h
for 80474 <at> debbugs.gnu.org; Sat, 28 Feb 2026 05:01:24 -0500
Received: by mail-wm1-x333.google.com with SMTP id
5b1f17b1804b1-4837907f535so24845995e9.3
for <80474 <at> debbugs.gnu.org>; Sat, 28 Feb 2026 02:01:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1772272881; x=1772877681; 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=pqqG1GwYZR33ssNl6d5f47BVUU5Uoen6+5C2Ne8ZLfE=;
b=JgpOyd+LJKAox6b/9U/T77wNVbxINOrwaLoDFwQ9mOnVin+mVtjUbIxYQw0qNf7QU5
xsvKCW22tw2SIZmSJBB4qGx11ibhhK8PkkTtqZW4/3P10u8J9wKcmgAqGj3PEU12Tnd0
vk1333MhMVRW7nmEa1sVWrEC/obe/wlwAyQ3wu9+JPI0tJfz644TgP7/572olUTFpqFL
O/81pVCazo+RCQY2Ng+NYXtQ2AT0Ec+zTF65qGFZmxWmp2bzBEdX31qgQ8LuRgfeI/V4
CD+kVvLhIHfm7aylaEKa418Y3BXmSwUkVW5NFGXDyTuzURAwG0j5dhmF0o1d3kvyZypp
hbeA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1772272881; x=1772877681;
h=mime-version:user-agent:message-id:date:references:in-reply-to
:subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject
:date:message-id:reply-to;
bh=pqqG1GwYZR33ssNl6d5f47BVUU5Uoen6+5C2Ne8ZLfE=;
b=hh9c4ZP61ujpR6TY7fs4Rl6TKV+lZ6bL04NKuyx3+TSuO6SKS4+3ufGsyjxPIvniJ8
U+fYjFta3NeaLqSiyGWxMlfGWrkLaD8DPsa1tPYydjb8UZmrCbVwUsR4thkwyMMiaM7X
AzLbHp/4YfDjabE+Os93leXSKJ+AMvAmqWxcgE3fDwgXyGhQze4BL8DcNGuTT23AkVrt
/2BOTrxfuNQQ/KkhZnuTIAZEZVsXVq/xVTY+g/lG/1A6+3H0eh92yBxsJgaz4Wvx7PCs
8VOi9hF50xKClcv2Y5ueb5bJzxFJatcdLg3iF9a2AuTI7dgiVM0aP7kyzLPZfECriHRU
tLNg==
X-Forwarded-Encrypted: i=1;
AJvYcCUVtRhKnmehg+Q4wy9tD76CgLJn3atkb5BPDA01NRuX7I+t3zt4aHrq6Eo+H+sxEJOONX5sPA==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YwgM9Xuz+AvAgSuKz6p6TYwU+j2E5xyx5sIfjbvCL7lL61sZsm0
KI7JYCS+kzvj8duhquN0i/Z0otFOaggMEMdAUck9dtE3bOxY1qk+7xFJ
X-Gm-Gg: ATEYQzwWPClP6Yig9gNF1VbI6uzvsZEkas3EdPc4++VidomLWMDgtn/M4rzBXEExhbO
rHMaJvLBoGqc+IV2CbTCSFRRkFtKUVvBjRLPH2TPo6LuZ+/7tjnUJlE/Mo1ZUqUHltvouDB0Dp+
duIGJFH2SmOth4Em2CoJ0aWL3VsGtNq7ygWBsc2rnj7qvjrmFclQzu8UEMIGzrSvwTwzRHgt9k/
lvwNTfLYvssLjxcn+IpTBX/eCs0jcM66102AQ5KvkP1XFJmbjZjsQLljkj/NVw6BZqm0l69QWkO
c7AlA06vpmzjwIgnS4C7r254nl0t+BkaSpNSRlvNx76fCK+J7vt2MD90eitZR7Pmfyr4riEfXJ7
Uz6l0dQcYmVoPQ3u1piSYh/ieXq6SsqFDa6PN06ZpZyWYGYaGePBIlkJ/BB2458K85UIoWjyK5F
qt4V7TlB5K7lwn9evNvA==
X-Received: by 2002:a05:600c:1d1d:b0:480:6bef:63a0 with SMTP id
5b1f17b1804b1-483c9bbbe50mr92703075e9.21.1772272880780;
Sat, 28 Feb 2026 02:01:20 -0800 (PST)
Received: from caladan ([212.46.170.2]) by smtp.gmail.com with ESMTPSA id
5b1f17b1804b1-483bfba9a5esm182935155e9.4.2026.02.28.02.01.18
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Sat, 28 Feb 2026 02:01:18 -0800 (PST)
From: Helmut Eller <eller.helmut@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: 31.0.50; [PATCH] charset_table split
In-Reply-To: <861pi77dq6.fsf@HIDDEN>
References: <871pia9y7m.fsf@HIDDEN> <86cy1u9lbe.fsf@HIDDEN>
<jwvtsv5c1kd.fsf-monnier+emacs@HIDDEN> <86h5r57zki.fsf@HIDDEN>
<87342nabs9.fsf@HIDDEN> <861pi77dq6.fsf@HIDDEN>
Date: Sat, 28 Feb 2026 11:01:17 +0100
Message-ID: <87wlzxkx02.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 80474
Cc: handa@HIDDEN, 80474 <at> debbugs.gnu.org, eggert@HIDDEN,
monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)
--=-=-=
Content-Type: text/plain
On Thu, Feb 26 2026, Eli Zaretskii wrote:
>> From: Helmut Eller <eller.helmut@HIDDEN>
>> Cc: Stefan Monnier <monnier@HIDDEN>, handa@HIDDEN,
>> 80474 <at> debbugs.gnu.org, eggert@HIDDEN
>> Date: Thu, 26 Feb 2026 14:12:54 +0100
>>
>> On Wed, Feb 25 2026, Eli Zaretskii wrote:
>>
>> >> I don't see any problem splitting the charset objects into two (one
>> >> that contains no GC-traced fields while the other's field are GC-traced).
>> >> The "keep in sync" doesn't seem particularly onerous. It's akin to
>> >> a "struct of arrays" vs "array of structs".
>> >
>> > But what the patch proposes is neither. It creates two completely
>> > separate objects, so they need to be synchronized "by hand".
>>
>> I could take the separate global variables (charset_table,
>> charset_table_size, charset_table_used, and charset_attributes_table)
>> and put them in struct like so:
>>
>> struct charset_table
>> {
>> struct charset *start;
>> int size, used;
>> Lisp_Object attributes_table;
>> } charset_table;
>>
>> Would that be better?
>
> Yes, I think so. Stefan?
>
>> > At the very least IMO we should have macros that do that in a
>> > synchronized way, and we should have a prominent comment that warns
>> > against manipulating each object directly, bypassing the macros.
>>
>> The need to "do that in a synchronized way" arises in
>> Fdefine_charset_internal and when dumping/loading the charset_table. I
>> don't know any other place.
>>
>> Better than some comment would perhaps assertions. E.g.
>> charset_attributes_getter could check the ids:
>>
>> INLINE Lisp_Object
>> charset_attributes_getter (struct charset *charset)
>> {
>> eassert (ASIZE (charset_attributes_table) == charset_table_size);
>> Lisp_Object attrs = AREF (charset_attributes_table, charset->id);
>> eassert (XFIXNUM (CHARSET_ATTR_ID (attrs)) == charset->id);
>> return attrs;
>> }
>
> Yes, that should be good.
>
>> >> It would be a problem only if we exposed charset objects (as opposed to
>> >> merely the charset-IDs) to ELisp.
>> >
>> > Then IMO we should have a comment to that effect as well.
>>
>> You mean a comment for something that we don't do?
>
> A warning for when someone considers exposing this to Lisp, yes.
Would it be ok to commit it with the additional patches below?
--=-=-=
Content-Type: text/x-diff
Content-Disposition: attachment;
filename=0001-src-charset.h-charset_attributes_getter-Add-assertio.patch
From 5594581cb45eceed11446003d31dd16a0a9ac8ea Mon Sep 17 00:00:00 2001
From: Helmut Eller <eller.helmut@HIDDEN>
Date: Fri, 27 Feb 2026 16:23:30 +0100
Subject: [PATCH 1/4] * src/charset.h (charset_attributes_getter): Add
assertion.
---
src/charset.h | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/src/charset.h b/src/charset.h
index bf14b15beba..7cd2f8b70cd 100644
--- a/src/charset.h
+++ b/src/charset.h
@@ -291,7 +291,9 @@ #define CHARSET_SYMBOL_HASH_INDEX(symbol) \
charset_attributes_getter (struct charset *charset)
{
eassert (ASIZE (charset_attributes_table) == charset_table_size);
- return AREF (charset_attributes_table, charset->id);
+ Lisp_Object attrs = AREF (charset_attributes_table, charset->id);
+ eassert (XFIXNUM (CHARSET_ATTR_ID (attrs)) == charset->id);
+ return attrs;
}
/* Return the attribute vector of CHARSET. */
--
2.47.3
--=-=-=
Content-Type: text/x-diff
Content-Disposition: attachment;
filename=0002-Introduce-a-struct-charset_table.patch
From e86f882dd25124f6a5a035b5d005346e2d91c740 Mon Sep 17 00:00:00 2001
From: Helmut Eller <eller.helmut@HIDDEN>
Date: Fri, 27 Feb 2026 18:32:12 +0100
Subject: [PATCH 2/4] Introduce a struct charset_table
The fields of the new struct are what the global variables
charset_table, charset_table_size, charset_table_used, and
charset_attributes_table used to be. The struct should make it clearer
that those fields must be kept in sync.
* src/charset.h (struct charset_table): New struct.
(charset_attributes_getter): Adjust accordingly.
* src/charset.c (charset_table): Change type to struct charset_table.
(charset_table_size, charset_table_used, charset_attributes_table):
Moved to the struct.
(Fdefine_charset_internal, Ffind_charset_region, Ffind_charset_string)
(shrink_charset_table, syms_of_charset): Adjust to struct charset_table.
* src/pdumper.c (dump_charset, dump_charset_table): Adjust to struct
charset_table.
---
src/charset.c | 94 ++++++++++++++++++++++++---------------------------
src/charset.h | 30 +++++++++++-----
src/pdumper.c | 12 +++----
3 files changed, 72 insertions(+), 64 deletions(-)
diff --git a/src/charset.c b/src/charset.c
index ff501022af9..eae81d689b7 100644
--- a/src/charset.c
+++ b/src/charset.c
@@ -60,16 +60,8 @@ Copyright (C) 2003, 2004
charset symbols, and values are vectors of charset attributes. */
Lisp_Object Vcharset_hash_table;
-/* Table of struct charset. */
-struct charset *charset_table;
-int charset_table_size;
-int charset_table_used;
-
-/* Table of attribute vectors. charset_attributes_table[id] contains
- the attribute vector for the charset at charset_table[id].
-
- This is a separate vector to simplify GC. */
-Lisp_Object charset_attributes_table;
+/* The table of all charsets. */
+struct charset_table charset_table;
/* Special charsets corresponding to symbols. */
int charset_ascii;
@@ -1128,28 +1120,28 @@ DEFUN ("define-charset-internal", Fdefine_charset_internal,
else
{
hash_put (hash_table, args[charset_arg_name], attrs, hash_code);
- if (charset_table_used == charset_table_size)
+ if (charset_table.used == charset_table.size)
{
/* Ensure that charset IDs fit into 'int' as well as into the
restriction imposed by fixnums. Although the 'int' restriction
could be removed, too much other code would need altering; for
example, the IDs are stuffed into struct
coding_system.charbuf[i] entries, which are 'int'. */
- int old_size = charset_table_size;
+ int old_size = charset_table.size;
ptrdiff_t new_size = old_size;
struct charset *new_table
= xpalloc (0, &new_size, 1,
min (INT_MAX, MOST_POSITIVE_FIXNUM),
- sizeof *charset_table);
- memcpy (new_table, charset_table,
+ sizeof *charset_table.start);
+ memcpy (new_table, charset_table.start,
old_size * sizeof *new_table);
- charset_table = new_table;
- charset_table_size = new_size;
+ charset_table.start = new_table;
+ charset_table.size = new_size;
Lisp_Object new_attr_table = make_vector (new_size, Qnil);
for (size_t i = 0; i < old_size; i++)
ASET (new_attr_table, i,
- AREF (charset_attributes_table, i));
- charset_attributes_table = new_attr_table;
+ AREF (charset_table.attributes_table, i));
+ charset_table.attributes_table = new_attr_table;
/* FIXME: This leaks memory, as the old charset_table becomes
unreachable. If the old charset table is charset_table_init
then this leak is intentional; otherwise, it's unclear.
@@ -1158,20 +1150,20 @@ DEFUN ("define-charset-internal", Fdefine_charset_internal,
charset_table should be freed, by passing it as the 1st argument
to xpalloc and removing the memcpy. */
}
- id = charset_table_used++;
+ id = charset_table.used++;
new_definition_p = 1;
}
ASET (attrs, charset_id, make_fixnum (id));
charset.id = id;
- charset_table[id] = charset;
- ASET (charset_attributes_table, id, attrs);
- eassert (ASIZE (charset_attributes_table) == charset_table_size);
+ charset_table.start[id] = charset;
+ ASET (charset_table.attributes_table, id, attrs);
+ eassert (ASIZE (charset_table.attributes_table) == charset_table.size);
if (charset.method == CHARSET_METHOD_MAP)
{
load_charset (&charset, 0);
- charset_table[id] = charset;
+ charset_table.start[id] = charset;
}
if (charset.iso_final >= 0)
@@ -1566,7 +1558,7 @@ DEFUN ("find-charset-region", Ffind_charset_region, Sfind_charset_region,
from_byte = CHAR_TO_BYTE (from);
- charsets = make_nil_vector (charset_table_used);
+ charsets = make_nil_vector (charset_table.used);
while (1)
{
find_charsets_in_text (BYTE_POS_ADDR (from_byte), stop - from,
@@ -1582,9 +1574,9 @@ DEFUN ("find-charset-region", Ffind_charset_region, Sfind_charset_region,
}
val = Qnil;
- for (i = charset_table_used - 1; i >= 0; i--)
+ for (i = charset_table.used - 1; i >= 0; i--)
if (!NILP (AREF (charsets, i)))
- val = Fcons (CHARSET_NAME (charset_table + i), val);
+ val = Fcons (CHARSET_NAME (charset_table.start + i), val);
return val;
}
@@ -1599,14 +1591,14 @@ DEFUN ("find-charset-string", Ffind_charset_string, Sfind_charset_string,
{
CHECK_STRING (str);
- Lisp_Object charsets = make_nil_vector (charset_table_used);
+ Lisp_Object charsets = make_nil_vector (charset_table.used);
find_charsets_in_text (SDATA (str), SCHARS (str), SBYTES (str),
charsets, table,
STRING_MULTIBYTE (str));
Lisp_Object val = Qnil;
- for (int i = charset_table_used - 1; i >= 0; i--)
+ for (int i = charset_table.used - 1; i >= 0; i--)
if (!NILP (AREF (charsets, i)))
- val = Fcons (CHARSET_NAME (charset_table + i), val);
+ val = Fcons (CHARSET_NAME (charset_table.start + i), val);
return val;
}
@@ -2117,28 +2109,29 @@ DEFUN ("iso-charset", Fiso_charset, Siso_charset, 3, 3, 0,
return (id >= 0 ? CHARSET_NAME (CHARSET_FROM_ID (id)) : Qnil);
}
-/* Shrink charset_table to charset_table_used. */
+/* Shrink charset_table to charset_table.used. */
static void
shrink_charset_table (void)
{
- eassert (charset_table_size >= charset_table_used);
- eassert (ASIZE (charset_attributes_table) == charset_table_size);
+ eassert (charset_table.size >= charset_table.used);
+ eassert (ASIZE (charset_table.attributes_table)
+ == charset_table.size);
- struct charset *old = charset_table;
- size_t nbytes = charset_table_used * sizeof *old;
+ struct charset *old = charset_table.start;
+ size_t nbytes = charset_table.used * sizeof *old;
struct charset *new = xmalloc (nbytes);
memcpy (new, old, nbytes);
- charset_table = new;
+ charset_table.start = new;
xfree (old);
- Lisp_Object new_attr_table = make_vector (charset_table_used, Qnil);
- for (size_t i = 0; i < charset_table_used; i++)
- ASET (new_attr_table, i, AREF (charset_attributes_table, i));
- charset_attributes_table = new_attr_table;
-
- charset_table_size = charset_table_used;
+ Lisp_Object new_attr_table = make_vector (charset_table.used, Qnil);
+ for (size_t i = 0; i < charset_table.used; i++)
+ ASET (new_attr_table, i,
+ AREF (charset_table.attributes_table, i));
+ charset_table.attributes_table = new_attr_table;
- eassert (ASIZE (charset_attributes_table) == charset_table_size);
+ charset_table.size = charset_table.used;
+ eassert (ASIZE (charset_table.attributes_table) == charset_table.size);
}
DEFUN ("clear-charset-maps", Fclear_charset_maps, Sclear_charset_maps,
@@ -2400,16 +2393,17 @@ syms_of_charset (void)
staticpro (&Vcharset_hash_table);
Vcharset_hash_table = CALLN (Fmake_hash_table, QCtest, Qeq);
- charset_table_size = CHARSET_TABLE_INIT_SIZE;
- PDUMPER_REMEMBER_SCALAR (charset_table_size);
- charset_table
- = xmalloc (charset_table_size * sizeof *charset_table);
- charset_table_used = 0;
- PDUMPER_REMEMBER_SCALAR (charset_table_used);
+ charset_table.size = CHARSET_TABLE_INIT_SIZE;
+ PDUMPER_REMEMBER_SCALAR (charset_table.size);
+ charset_table.start
+ = xmalloc (charset_table.size * sizeof *charset_table.start);
+ charset_table.used = 0;
+ PDUMPER_REMEMBER_SCALAR (charset_table.used);
- charset_attributes_table = make_vector (charset_table_size, Qnil);
- staticpro (&charset_attributes_table);
+ charset_table.attributes_table
+ = make_vector (charset_table.size, Qnil);
+ staticpro (&charset_table.attributes_table);
defsubr (&Scharsetp);
defsubr (&Smap_charset_chars);
defsubr (&Sdefine_charset_internal);
diff --git a/src/charset.h b/src/charset.h
index 7cd2f8b70cd..f7cd08e3a88 100644
--- a/src/charset.h
+++ b/src/charset.h
@@ -243,14 +243,28 @@ #define EMACS_CHARSET_H
vectors. */
extern Lisp_Object Vcharset_hash_table;
-/* Table of struct charset. */
-extern struct charset *charset_table;
-extern int charset_table_size;
-extern int charset_table_used;
+/* A charset_table is an array of struct charset along with a
+ Lisp_Vector of charset attributes.
-extern Lisp_Object charset_attributes_table;
+ The charset_table.start field either points to xmalloced memory or to
+ the dump (i.e. pdumper_object_p (charset_table.start) can be true).
-#define CHARSET_FROM_ID(id) (charset_table + (id))
+ charset_table.attributes_table[id] contains the attribute vector for
+ the charset at charset_table.start[id].
+
+ We keep the attributes in a separate vector because that is
+ convenient for the GC. (We probably need to revise this decision, if
+ we ever expose struct charset as a Lisp level type.) */
+struct charset_table
+{
+ struct charset *start;
+ unsigned size, used;
+ Lisp_Object attributes_table;
+};
+
+extern struct charset_table charset_table;
+
+#define CHARSET_FROM_ID(id) (charset_table.start + (id))
extern Lisp_Object Vcharset_ordered_list;
extern Lisp_Object Vcharset_non_preferred_head;
@@ -290,8 +304,8 @@ #define CHARSET_SYMBOL_HASH_INDEX(symbol) \
INLINE Lisp_Object
charset_attributes_getter (struct charset *charset)
{
- eassert (ASIZE (charset_attributes_table) == charset_table_size);
- Lisp_Object attrs = AREF (charset_attributes_table, charset->id);
+ eassert (ASIZE (charset_table.attributes_table) == charset_table.size);
+ Lisp_Object attrs = AREF (charset_table.attributes_table, charset->id);
eassert (XFIXNUM (CHARSET_ATTR_ID (attrs)) == charset->id);
return attrs;
}
diff --git a/src/pdumper.c b/src/pdumper.c
index 6461ec170d0..b0f40c6e3ce 100644
--- a/src/pdumper.c
+++ b/src/pdumper.c
@@ -3214,10 +3214,10 @@ dump_charset (struct dump_context *ctx, int cs_i)
/* We can't change the alignment here, because ctx->offset is what
will be used for the whole array. */
eassert (ctx->offset % alignof (struct charset) == 0);
- const struct charset *cs = charset_table + cs_i;
+ const struct charset *cs = charset_table.start + cs_i;
struct charset out;
dump_object_start (ctx, &out, sizeof (out));
- if (cs_i < charset_table_used) /* Don't look at uninitialized data. */
+ if (cs_i < charset_table.used) /* Don't look at uninitialized data. */
{
DUMP_FIELD_COPY (&out, cs, id);
DUMP_FIELD_COPY (&out, cs, dimension);
@@ -3244,7 +3244,7 @@ dump_charset (struct dump_context *ctx, int cs_i)
DUMP_FIELD_COPY (&out, cs, code_offset);
}
dump_off offset = dump_object_finish (ctx, &out, sizeof (out));
- if (cs_i < charset_table_used && cs->code_space_mask)
+ if (cs_i < charset_table.used && cs->code_space_mask)
dump_remember_cold_op (ctx, COLD_OP_CHARSET,
Fcons (dump_off_to_lisp (cs_i),
dump_off_to_lisp (offset)));
@@ -3260,8 +3260,8 @@ dump_charset_table (struct dump_context *ctx)
dump_off offset = ctx->offset;
if (dump_set_referrer (ctx))
ctx->current_referrer = build_string ("charset_table");
- eassert (charset_table_size == charset_table_used);
- for (int i = 0; i < charset_table_size; ++i)
+ eassert (charset_table.size == charset_table.used);
+ for (int i = 0; i < charset_table.size; ++i)
dump_charset (ctx, i);
dump_clear_referrer (ctx);
dump_emacs_reloc_to_dump_ptr_raw (ctx, &charset_table, offset);
@@ -3411,7 +3411,7 @@ dump_cold_charset (struct dump_context *ctx, Lisp_Object data)
(ctx,
cs_dump_offset + dump_offsetof (struct charset, code_space_mask),
ctx->offset);
- struct charset *cs = charset_table + cs_i;
+ struct charset *cs = charset_table.start + cs_i;
dump_write (ctx, cs->code_space_mask, 256);
}
--
2.47.3
--=-=-=
Content-Type: text/x-diff
Content-Disposition: attachment;
filename=0003-src-charset.c-shrink_charset_table-Simplify.patch
From 5bb6a90ddcefd5adc9c1f3c248f87c440fea3415 Mon Sep 17 00:00:00 2001
From: Helmut Eller <eller.helmut@HIDDEN>
Date: Sat, 28 Feb 2026 10:53:09 +0100
Subject: [PATCH 3/4] * src/charset.c (shrink_charset_table): Simplify.
---
src/charset.c | 31 ++++++++++++++++---------------
1 file changed, 16 insertions(+), 15 deletions(-)
diff --git a/src/charset.c b/src/charset.c
index eae81d689b7..2cca2222ec5 100644
--- a/src/charset.c
+++ b/src/charset.c
@@ -2117,21 +2117,22 @@ shrink_charset_table (void)
eassert (ASIZE (charset_table.attributes_table)
== charset_table.size);
- struct charset *old = charset_table.start;
- size_t nbytes = charset_table.used * sizeof *old;
- struct charset *new = xmalloc (nbytes);
- memcpy (new, old, nbytes);
- charset_table.start = new;
- xfree (old);
-
- Lisp_Object new_attr_table = make_vector (charset_table.used, Qnil);
- for (size_t i = 0; i < charset_table.used; i++)
- ASET (new_attr_table, i,
- AREF (charset_table.attributes_table, i));
- charset_table.attributes_table = new_attr_table;
-
- charset_table.size = charset_table.used;
- eassert (ASIZE (charset_table.attributes_table) == charset_table.size);
+ if (charset_table.size > charset_table.used)
+ {
+ eassert (!pdumper_object_p (charset_table.start));
+ charset_table.start
+ = xnrealloc (charset_table.start, charset_table.used,
+ sizeof *charset_table.start);
+
+ charset_table.attributes_table
+ = Fvector (charset_table.used,
+ xvector_contents (charset_table.attributes_table));
+
+ charset_table.size = charset_table.used;
+ }
+ eassert (charset_table.size == charset_table.used);
+ eassert (ASIZE (charset_table.attributes_table)
+ == charset_table.size);
}
DEFUN ("clear-charset-maps", Fclear_charset_maps, Sclear_charset_maps,
--
2.47.3
--=-=-=
Content-Type: text/x-diff
Content-Disposition: attachment;
filename=0004-src-charset.c-Fdefine_charset_internal-Fix-memory-le.patch
From ea1e13a7f620fcd0a92140407b090354f980e050 Mon Sep 17 00:00:00 2001
From: Helmut Eller <eller.helmut@HIDDEN>
Date: Sat, 28 Feb 2026 10:54:24 +0100
Subject: [PATCH 4/4] * src/charset.c (Fdefine_charset_internal): Fix memory
leak.
---
src/charset.c | 8 +-------
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/src/charset.c b/src/charset.c
index 2cca2222ec5..16ff09a48bf 100644
--- a/src/charset.c
+++ b/src/charset.c
@@ -1135,6 +1135,7 @@ DEFUN ("define-charset-internal", Fdefine_charset_internal,
sizeof *charset_table.start);
memcpy (new_table, charset_table.start,
old_size * sizeof *new_table);
+ xfree (charset_table.start);
charset_table.start = new_table;
charset_table.size = new_size;
Lisp_Object new_attr_table = make_vector (new_size, Qnil);
@@ -1142,13 +1143,6 @@ DEFUN ("define-charset-internal", Fdefine_charset_internal,
ASET (new_attr_table, i,
AREF (charset_table.attributes_table, i));
charset_table.attributes_table = new_attr_table;
- /* FIXME: This leaks memory, as the old charset_table becomes
- unreachable. If the old charset table is charset_table_init
- then this leak is intentional; otherwise, it's unclear.
- If the latter memory leak is intentional, a
- comment should be added to explain this. If not, the old
- charset_table should be freed, by passing it as the 1st argument
- to xpalloc and removing the memcpy. */
}
id = charset_table.used++;
new_definition_p = 1;
--
2.47.3
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#80474; Package emacs.
Full text available.
Received: (at 80474) by debbugs.gnu.org; 26 Feb 2026 14:59:59 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Feb 26 09:59:59 2026
Received: from localhost ([127.0.0.1]:41766 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vvcqN-00066o-1l
for submit <at> debbugs.gnu.org; Thu, 26 Feb 2026 09:59:59 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:60802)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vvcqK-00066U-3k
for 80474 <at> debbugs.gnu.org; Thu, 26 Feb 2026 09:59: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 <eliz@HIDDEN>)
id 1vvcqE-0000pE-JM; Thu, 26 Feb 2026 09:59:50 -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=s3LgDpqEPdXD9GDxlg+Hq/NPvgWN+7SbMe4xliVcmXY=; b=Bv896uxwUihM
eWT2nQCxRDhHkKzleUgdMdNNd5hMNpNIc388RmhSpGtMfgzOJFxDBNR9SZA03kvcvmQ6jnIT91Ich
RiRpGjIhbXREuT3aIotZRC96T7kgXiHyakaDppm5B6EjKUO4xU4/aguRwNrWtMzjXvc3d0lDiGUYV
VGti01yWfYTq1eYz4/eb+1KnlmeHjqVE9XPKBtSqM6FR47s2HQPn5U256uWrGRv/WmRPnKLsh2BuF
5sppRxMFpXdflTntbzKlRciuJIy2QZVCKFCD/AX+DSitAe3utWx9mHiHINSKQLpG5LN2RJL663WPs
pRzYJNGW2sAe1XWPaRtLmA==;
Date: Thu, 26 Feb 2026 16:59:13 +0200
Message-Id: <861pi77dq6.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
To: Helmut Eller <eller.helmut@HIDDEN>
In-Reply-To: <87342nabs9.fsf@HIDDEN> (message from Helmut Eller on Thu, 26
Feb 2026 14:12:54 +0100)
Subject: Re: 31.0.50; [PATCH] charset_table split
References: <871pia9y7m.fsf@HIDDEN> <86cy1u9lbe.fsf@HIDDEN>
<jwvtsv5c1kd.fsf-monnier+emacs@HIDDEN> <86h5r57zki.fsf@HIDDEN>
<87342nabs9.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 80474
Cc: handa@HIDDEN, 80474 <at> debbugs.gnu.org, eggert@HIDDEN,
monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> From: Helmut Eller <eller.helmut@HIDDEN>
> Cc: Stefan Monnier <monnier@HIDDEN>, handa@HIDDEN,
> 80474 <at> debbugs.gnu.org, eggert@HIDDEN
> Date: Thu, 26 Feb 2026 14:12:54 +0100
>
> On Wed, Feb 25 2026, Eli Zaretskii wrote:
>
> >> I don't see any problem splitting the charset objects into two (one
> >> that contains no GC-traced fields while the other's field are GC-traced).
> >> The "keep in sync" doesn't seem particularly onerous. It's akin to
> >> a "struct of arrays" vs "array of structs".
> >
> > But what the patch proposes is neither. It creates two completely
> > separate objects, so they need to be synchronized "by hand".
>
> I could take the separate global variables (charset_table,
> charset_table_size, charset_table_used, and charset_attributes_table)
> and put them in struct like so:
>
> struct charset_table
> {
> struct charset *start;
> int size, used;
> Lisp_Object attributes_table;
> } charset_table;
>
> Would that be better?
Yes, I think so. Stefan?
> > At the very least IMO we should have macros that do that in a
> > synchronized way, and we should have a prominent comment that warns
> > against manipulating each object directly, bypassing the macros.
>
> The need to "do that in a synchronized way" arises in
> Fdefine_charset_internal and when dumping/loading the charset_table. I
> don't know any other place.
>
> Better than some comment would perhaps assertions. E.g.
> charset_attributes_getter could check the ids:
>
> INLINE Lisp_Object
> charset_attributes_getter (struct charset *charset)
> {
> eassert (ASIZE (charset_attributes_table) == charset_table_size);
> Lisp_Object attrs = AREF (charset_attributes_table, charset->id);
> eassert (XFIXNUM (CHARSET_ATTR_ID (attrs)) == charset->id);
> return attrs;
> }
Yes, that should be good.
> >> It would be a problem only if we exposed charset objects (as opposed to
> >> merely the charset-IDs) to ELisp.
> >
> > Then IMO we should have a comment to that effect as well.
>
> You mean a comment for something that we don't do?
A warning for when someone considers exposing this to Lisp, yes.
bug-gnu-emacs@HIDDEN:bug#80474; Package emacs.
Full text available.
Received: (at 80474) by debbugs.gnu.org; 26 Feb 2026 13:13:00 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Feb 26 08:13:00 2026
Received: from localhost ([127.0.0.1]:40136 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vvbAq-0003TY-6t
for submit <at> debbugs.gnu.org; Thu, 26 Feb 2026 08:13:00 -0500
Received: from mail-wr1-x42e.google.com ([2a00:1450:4864:20::42e]:53309)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <eller.helmut@HIDDEN>)
id 1vvbAn-0003TI-On
for 80474 <at> debbugs.gnu.org; Thu, 26 Feb 2026 08:12:58 -0500
Received: by mail-wr1-x42e.google.com with SMTP id
ffacd0b85a97d-436356740e6so886077f8f.2
for <80474 <at> debbugs.gnu.org>; Thu, 26 Feb 2026 05:12:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1772111576; x=1772716376; 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=SQmZMKrN1oONgLOjsGaoTqDN8sVFpqni3IJnINzEkmM=;
b=N5FgJSW4YsyQizI6MXYM9wIzFDkYRcVsPOs5hP3Vd2fBIOli0SQ1yneGRSnYwt/NH+
QLCnIJKUVdelCJaIfm17tvTqBoeo70I7dnKNM1i3hfKwpJiFDK+fACpNfJTfygA8fH71
B9ujL4dszxhhgsrSxzNFCD7oeamV2UP2k1uoy2i0AbjL0eySh/gVsqQCE9k90vcxTIoC
1IRv7jEKmX2gSnSV3gOVQ0raad1O46xLxUqk23r/6tO6RbZ592nMu0YMiyj7IeZo3hRw
xTesWsZdPpx9lVVIjasOHOsTvvEfdvkswTNZ7wCBbel47WKTi1DqbdbxmZ5UCt5MQSPT
Sbaw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1772111576; x=1772716376;
h=mime-version:user-agent:message-id:date:references:in-reply-to
:subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject
:date:message-id:reply-to;
bh=SQmZMKrN1oONgLOjsGaoTqDN8sVFpqni3IJnINzEkmM=;
b=rBaHIFOzyXysgomapa1QR7WbO4si8pC3CFiT3HljNdWrdWtW90RpwLO1o5H2qBFq6C
JzvmOfr4WWZVOXAJppHJwXSkD0vNqHwGppToeuyYBSD1n3IiS2Ja5TbYcfIjKnvUr+G8
aBe0LEKJwz7O7qpnPpLpul2vVzRBeXqtnSC1TyxmgRGsNo0HqWqrS4v5p1ocoZFEN/OF
kglCixAKsxqfliQn4rm6XNC3NH9dAyTHLjq6Fvoyp79qVhGczGKUE3iQs7PHaMvlasPm
Mv/OaLCC40iVImluKc/gVCqfu1InUJ0lFm2iaV+xptJuxS8O7dZgaPuug98uKAyKYsCh
uCRw==
X-Forwarded-Encrypted: i=1;
AJvYcCXDB7OsLr00YUzoCEa0H4Yajywutlee5f15WkXgy72/49sI9ACG0Owmtmu+eaW/1utiqmGjAw==@debbugs.gnu.org
X-Gm-Message-State: AOJu0YwiE7T5BpUyqrBoCecAuWFBoWJY04SA6JlFTgvStSCzVsb1tfqK
HxNmVzVYKp0G21q0Q8sKQ2XBuh5iMiO8h7VDM0MDyIBoLCTJSNX//GCp
X-Gm-Gg: ATEYQzyaFsHkc1gpZPmCZ7hZgHfXI4vl5849ZrDoYNj1LbiMlQGtMavgLcM2O/HH2Wi
FtdXGqK8pqm57+hr4lejkCtVN4b2uIG4OyDbjvaXkhjgrkkMdGg1U6hiE3ZVqnYveRsWtytKKNr
hfx4qzfIVQqocZutMv3aT7tOOHGSlA+2xpmHQC2kcWpzf8sPFFXWEAcOBCvmSAVbMr+3MZGhQQj
OdQQmE4JHelldYVJAt3Wkyu0NXxWDePt0w4m9yL2h8ttQaorB3zVsxOh49nCGyjMIh+eANL3FqH
vrk9APROTGE6sN0XaHpb0KbDxd6FoQ/cQ3zQlLHkh98hb+nvQdapumJfJIOVaUUvJSgVRvkdODF
FRkqL8V3oZktljPMU0l06QAQ63kmTs0tF1I+G5CV93qzTjr3W2/F2se9CarsBo79CRQUTMl0taG
gVBXEkrZ9ja0KOeuxFFQ==
X-Received: by 2002:a05:6000:2c05:b0:439:8e3b:d069 with SMTP id
ffacd0b85a97d-439942e7284mr7492427f8f.38.1772111576189;
Thu, 26 Feb 2026 05:12:56 -0800 (PST)
Received: from caladan ([212.46.170.2]) by smtp.gmail.com with ESMTPSA id
ffacd0b85a97d-43970c00d95sm39422618f8f.13.2026.02.26.05.12.54
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Thu, 26 Feb 2026 05:12:55 -0800 (PST)
From: Helmut Eller <eller.helmut@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: 31.0.50; [PATCH] charset_table split
In-Reply-To: <86h5r57zki.fsf@HIDDEN>
References: <871pia9y7m.fsf@HIDDEN> <86cy1u9lbe.fsf@HIDDEN>
<jwvtsv5c1kd.fsf-monnier+emacs@HIDDEN> <86h5r57zki.fsf@HIDDEN>
Date: Thu, 26 Feb 2026 14:12:54 +0100
Message-ID: <87342nabs9.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 1.0 (+)
X-Debbugs-Envelope-To: 80474
Cc: handa@HIDDEN, 80474 <at> debbugs.gnu.org, eggert@HIDDEN,
Stefan Monnier <monnier@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.0 (/)
On Wed, Feb 25 2026, Eli Zaretskii wrote:
>> From: Stefan Monnier <monnier@HIDDEN>
>> Cc: "K. Handa" <handa@HIDDEN>, eller.helmut@HIDDEN,
>> 80474 <at> debbugs.gnu.org, eggert@HIDDEN
>> Date: Tue, 24 Feb 2026 15:50:45 -0500
>>
>> >> > > The first patch, splits the charset_table array into two parallel
>> >> > > arrays. The second array, the charset_attributes_table, holds what
>> >> > > was previously in the attribute field. That field was the only one of
>> >> > > concern to the GC. Keeping it separate makes some things easier for
>> >> > > the GC. Though, the arrays must be kept in sync.
>> >>
>> >> The field "attributes" of the struct "charset" was introduced by this
>> >> commit.
>> >> ------------------------------------------------------------
>> >> commit 33b8d5b6c5a22bab069cdac4bddda932b3d18b13
>> >> Author: Stefan Monnier <monnier@HIDDEN>
>> >> Date: Tue Jan 23 22:30:13 2024 -0500
>> >>
>> >> (struct charset): Remove dependency on hash-table internals
>> >>
>> >> `struct charset` kept an index into the internal `key_and_value` array
>> >> of hash tables, which only worked because of details of how
>> >> hash-tables are handled. Replace it with a reference to the
>> >> value stored at that location in the hash-table, which saves us an
>> >> indirection while at it.
>> >>
>> >> * src/charset.h (struct charset): Replace `hash_index` field with
>> >> `attributes` field.
>> >> (CHARSET_ATTRIBUTES): Simplify accordingly.
>> >> (CHARSET_HASH_INDEX): Delete unused macro.
>> >> * src/charset.c (Fdefine_charset_internal):
>> >> * src/pdumper.c (dump_charset): Adjust accordingly.
>> >> (dump_charset_table): Set the referrer since that's needed while
>> >> dumping Lisp_Object fields.
>> >> ------------------------------------------------------------
>> >> So, it is better to ask Stefan to comment on the change.
>>
>> I don't see any problem splitting the charset objects into two (one
>> that contains no GC-traced fields while the other's field are GC-traced).
>> The "keep in sync" doesn't seem particularly onerous. It's akin to
>> a "struct of arrays" vs "array of structs".
>
> But what the patch proposes is neither. It creates two completely
> separate objects, so they need to be synchronized "by hand".
I could take the separate global variables (charset_table,
charset_table_size, charset_table_used, and charset_attributes_table)
and put them in struct like so:
struct charset_table
{
struct charset *start;
int size, used;
Lisp_Object attributes_table;
} charset_table;
Would that be better?
> At the very least IMO we should have macros that do that in a
> synchronized way, and we should have a prominent comment that warns
> against manipulating each object directly, bypassing the macros.
The need to "do that in a synchronized way" arises in
Fdefine_charset_internal and when dumping/loading the charset_table. I
don't know any other place.
Better than some comment would perhaps assertions. E.g.
charset_attributes_getter could check the ids:
INLINE Lisp_Object
charset_attributes_getter (struct charset *charset)
{
eassert (ASIZE (charset_attributes_table) == charset_table_size);
Lisp_Object attrs = AREF (charset_attributes_table, charset->id);
eassert (XFIXNUM (CHARSET_ATTR_ID (attrs)) == charset->id);
return attrs;
}
>> It would be a problem only if we exposed charset objects (as opposed to
>> merely the charset-IDs) to ELisp.
>
> Then IMO we should have a comment to that effect as well.
You mean a comment for something that we don't do?
bug-gnu-emacs@HIDDEN:bug#80474; Package emacs.
Full text available.
Received: (at 80474) by debbugs.gnu.org; 25 Feb 2026 18:49:55 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Feb 25 13:49:55 2026
Received: from localhost ([127.0.0.1]:60658 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vvJxK-0002dR-Ug
for submit <at> debbugs.gnu.org; Wed, 25 Feb 2026 13:49:55 -0500
Received: from mail.cs.ucla.edu ([131.179.128.66]:45506)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eggert@HIDDEN>)
id 1vvJxJ-0002cq-4D
for 80474 <at> debbugs.gnu.org; Wed, 25 Feb 2026 13:49:53 -0500
Received: from localhost (localhost [127.0.0.1])
by mail.cs.ucla.edu (Postfix) with ESMTP id 4786C3C1082D2;
Wed, 25 Feb 2026 10:49:47 -0800 (PST)
Received: from mail.cs.ucla.edu ([127.0.0.1])
by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10032) with ESMTP
id Gg--JFjJvhic; Wed, 25 Feb 2026 10:49:47 -0800 (PST)
Received: from localhost (localhost [127.0.0.1])
by mail.cs.ucla.edu (Postfix) with ESMTP id 1B6233C1082DF;
Wed, 25 Feb 2026 10:49:47 -0800 (PST)
DKIM-Filter: OpenDKIM Filter v2.10.3 mail.cs.ucla.edu 1B6233C1082DF
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.ucla.edu;
s=9D0B346E-2AEB-11ED-9476-E14B719DCE6C; t=1772045387;
bh=1m275MaguOytS8ajP4eDH6ntoixEHeA2T7bCQN1edSg=;
h=Message-ID:Date:MIME-Version:To:From;
b=l1q2T2ol5IQkW6RbHpSVg+HVPG8WkUbov31y2tQibrczZqbjvaVxqvacSnqmpnJxi
+MEblicOiCVtNIT2MS5CDOzoJ66uId5UuAxJw3TG0I29OQdGQ3i6Wx9lvAdIrvuBGV
ceT2Ijoy58XJUQg4kDK1FaU8f8UGiqLAS729FNjlDaKM28yvhSOVzb66xfjCfeJJvi
BRjkJQAAeP3e9eB9JbeRrcpuM0t+SIN5ckoKeuTEJwEC5fDaSh/mHk/NzxYDnHNjbJ
+2V7HEWwPNghzXcrYKCz2arHnZvAV+dgBlkJd7d/KXjU772MGBZGtCClyVSJJkenGJ
Eb0YRfq1q6XRA==
X-Virus-Scanned: amavis at mail.cs.ucla.edu
Received: from mail.cs.ucla.edu ([127.0.0.1])
by localhost (mail.cs.ucla.edu [127.0.0.1]) (amavis, port 10026) with ESMTP
id MjpphOt6ACCj; Wed, 25 Feb 2026 10:49:46 -0800 (PST)
Received: from penguin.cs.ucla.edu
(47-154-25-30.fdr01.snmn.ca.ip.frontiernet.net [47.154.25.30])
by mail.cs.ucla.edu (Postfix) with ESMTPSA id DCD953C1082D2;
Wed, 25 Feb 2026 10:49:46 -0800 (PST)
Message-ID: <dda79cf5-7447-4d71-9ee5-53baec7d3c29@HIDDEN>
Date: Wed, 25 Feb 2026 10:49:46 -0800
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: 31.0.50; [PATCH] charset_table split
To: Eli Zaretskii <eliz@HIDDEN>, "K. Handa" <handa@HIDDEN>
References: <871pia9y7m.fsf@HIDDEN> <86cy1u9lbe.fsf@HIDDEN>
Content-Language: en-US
From: Paul Eggert <eggert@HIDDEN>
Organization: UCLA Computer Science Department
In-Reply-To: <86cy1u9lbe.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 1.4 (+)
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: On 2026-02-24 08:07, Eli Zaretskii wrote: > I hope Stefan
and Paul will look into this. The basic idea of the "Remove the
charset_table_init
array" patch looks OK to me. Although it would not have worked with the
traditional
unexec dumper, it should be OK now that we dump only with pdump [...]
Content analysis details: (1.4 points, 10.0 required)
pts rule name description
---- ---------------------- --------------------------------------------------
0.6 RCVD_IN_VALIDITY_CERTIFIED_BLOCKED RBL: ADMINISTRATOR NOTICE:
The query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[131.179.128.66 listed in sa-accredit.habeas.com]
0.7 RCVD_IN_VALIDITY_RPBL_BLOCKED RBL: ADMINISTRATOR NOTICE: The
query to Validity was blocked. See
https://knowledge.validity.com/hc/en-us/articles/20961730681243
for more information.
[131.179.128.66 listed in bl.score.senderscore.com]
0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record
-0.0 SPF_PASS SPF: sender matches SPF record
X-Debbugs-Envelope-To: 80474
Cc: 80474 <at> debbugs.gnu.org, eller.helmut@HIDDEN, monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.4 (/)
On 2026-02-24 08:07, Eli Zaretskii wrote:
> I hope Stefan and Paul will look into this.
The basic idea of the "Remove the charset_table_init array" patch looks
OK to me. Although it would not have worked with the traditional unexec
dumper, it should be OK now that we dump only with pdumper.
Some ideas for minor improvements:
> + struct charset *old = charset_table;
> + size_t nbytes = charset_table_used * sizeof *old;
> + struct charset *new = xmalloc (nbytes);
> + memcpy (new, old, nbytes);
> + charset_table = new;
Simpler and clearer would be:
charset_table = xnrealloc (charset_table,
charset_table_used, sizeof *charset_table);
> + Lisp_Object new_attr_table = make_vector (charset_table_used, Qnil);
> + for (size_t i = 0; i < charset_table_used; i++)
> + ASET (new_attr_table, i, AREF (charset_attributes_table, i));
> + charset_attributes_table = new_attr_table;
Simpler and faster would be:
charset_attributes_table
= Fvector (charset_table_used,
XVECTOR (charset_attributes_table)->contents);
bug-gnu-emacs@HIDDEN:bug#80474; Package emacs.
Full text available.Received: (at 80474) by debbugs.gnu.org; 25 Feb 2026 12:55:22 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Feb 25 07:55:22 2026 Received: from localhost ([127.0.0.1]:56092 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vvEQD-0004eK-Jn for submit <at> debbugs.gnu.org; Wed, 25 Feb 2026 07:55:22 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:40594) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vvEQA-0004dl-1L for 80474 <at> debbugs.gnu.org; Wed, 25 Feb 2026 07:55:19 -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 <eliz@HIDDEN>) id 1vvEQ3-0003ac-Ta; Wed, 25 Feb 2026 07:55:11 -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=XnlFAo+Qu/oaVlgsfl0O1puWC9Ay/cAnRp70nJi/L/w=; b=kNIp6yTDurvR NB+oXAOu4EbrjRJxbr5EA5Rv+mdO5TXcFcuCOjMFz9zRUXa4t4DkGoESiEvOcwqcTzUiteujhQ1mt xpt7xxSQ3ftZ4w2sbsN2Xf21mJB1b4vkjp6XOC9lk8dKkcvjiimoWFCmtFkN9ZV/Ar5qF25e+Pt0o NpTytBA7V90rTe1yCGifYOgeCCwiS4rJwU0nOT4IV1GnV5rqxfTyL7PFZAuSi3bWfqJe/bTb0ntDW swKNyRlKn5J2gYIz/NROm5kORcgj4cHwmw3fkRP8h71KMWRXgXA+6FH57yxitW4i8P2kCKCD1K85M 7oMv8gcLPwR0Rvc3IHgnsg==; Date: Wed, 25 Feb 2026 14:55:09 +0200 Message-Id: <86h5r57zki.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Stefan Monnier <monnier@HIDDEN> In-Reply-To: <jwvtsv5c1kd.fsf-monnier+emacs@HIDDEN> (message from Stefan Monnier on Tue, 24 Feb 2026 15:50:45 -0500) Subject: Re: 31.0.50; [PATCH] charset_table split References: <871pia9y7m.fsf@HIDDEN> <86cy1u9lbe.fsf@HIDDEN> <jwvtsv5c1kd.fsf-monnier+emacs@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80474 Cc: handa@HIDDEN, 80474 <at> debbugs.gnu.org, eggert@HIDDEN, eller.helmut@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Stefan Monnier <monnier@HIDDEN> > Cc: "K. Handa" <handa@HIDDEN>, eller.helmut@HIDDEN, > 80474 <at> debbugs.gnu.org, eggert@HIDDEN > Date: Tue, 24 Feb 2026 15:50:45 -0500 > > >> > > The first patch, splits the charset_table array into two parallel > >> > > arrays. The second array, the charset_attributes_table, holds what > >> > > was previously in the attribute field. That field was the only one of > >> > > concern to the GC. Keeping it separate makes some things easier for > >> > > the GC. Though, the arrays must be kept in sync. > >> > >> The field "attributes" of the struct "charset" was introduced by this > >> commit. > >> ------------------------------------------------------------ > >> commit 33b8d5b6c5a22bab069cdac4bddda932b3d18b13 > >> Author: Stefan Monnier <monnier@HIDDEN> > >> Date: Tue Jan 23 22:30:13 2024 -0500 > >> > >> (struct charset): Remove dependency on hash-table internals > >> > >> `struct charset` kept an index into the internal `key_and_value` array > >> of hash tables, which only worked because of details of how > >> hash-tables are handled. Replace it with a reference to the > >> value stored at that location in the hash-table, which saves us an > >> indirection while at it. > >> > >> * src/charset.h (struct charset): Replace `hash_index` field with > >> `attributes` field. > >> (CHARSET_ATTRIBUTES): Simplify accordingly. > >> (CHARSET_HASH_INDEX): Delete unused macro. > >> * src/charset.c (Fdefine_charset_internal): > >> * src/pdumper.c (dump_charset): Adjust accordingly. > >> (dump_charset_table): Set the referrer since that's needed while > >> dumping Lisp_Object fields. > >> ------------------------------------------------------------ > >> So, it is better to ask Stefan to comment on the change. > > I don't see any problem splitting the charset objects into two (one > that contains no GC-traced fields while the other's field are GC-traced). > The "keep in sync" doesn't seem particularly onerous. It's akin to > a "struct of arrays" vs "array of structs". But what the patch proposes is neither. It creates two completely separate objects, so they need to be synchronized "by hand". At the very least IMO we should have macros that do that in a synchronized way, and we should have a prominent comment that warns against manipulating each object directly, bypassing the macros. > It would be a problem only if we exposed charset objects (as opposed to > merely the charset-IDs) to ELisp. Then IMO we should have a comment to that effect as well. > > I'm particularly bothered by the need to "keep the two arrays in > > sync", for all the possible uses and varieties of char-tables, so I > > hope the guilty parties will comment on that and state their views and > > opinions. > > Hmm... now I'm confused. I thought this was about charsets, not > char-tables. Sorry for my confusion. But the rest of the comments still stand.
bug-gnu-emacs@HIDDEN:bug#80474; Package emacs.
Full text available.Received: (at 80474) by debbugs.gnu.org; 24 Feb 2026 20:51:04 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 24 15:51:04 2026 Received: from localhost ([127.0.0.1]:46589 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vuzN0-0003zC-6W for submit <at> debbugs.gnu.org; Tue, 24 Feb 2026 15:51:03 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:45933) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <monnier@HIDDEN>) id 1vuzMt-0003wp-AX for 80474 <at> debbugs.gnu.org; Tue, 24 Feb 2026 15:50:58 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id D12EF81C46; Tue, 24 Feb 2026 15:50:47 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1771966246; bh=aiUz9QEpV3PVGWQ4RZgt+b4d4TlPe7HBCnroryewlPE=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=J9orbAG+2ejImpi3B41h2pBeOoUMqFN9eFlMCJwIRNx6HmFTv5rqnOxqSjXMrvgSf HFa1aePIaCb05GuiDNtJOKvInQD1gnJVMYYU9/wIH7q4NuMTbW6eHSMoDhKtdvL2yR +szXh25IkgrUNXSoDrwVcnAAdVWjzg9TEYMqe/7AAlV19ZOj/BwmXHGzc48LaZtutK XwBDBshECHEU/IciEGpN5zfhId6S9fw+/3rMNW3HrlyD+83UADwZDqlA8zrKokD7U7 47LA5TOuWD8pBm1+2akiBXkD7V61nODJjjxv6FJF3HuUfphNBicBLgLtr2J9MYKUnB RufVSwxY6Rsrg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 06DFC81707; Tue, 24 Feb 2026 15:50:46 -0500 (EST) Received: from alfajor (modemcable209.196-177-173.mc.videotron.ca [173.177.196.209]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D344A120185; Tue, 24 Feb 2026 15:50:45 -0500 (EST) From: Stefan Monnier <monnier@HIDDEN> To: Eli Zaretskii <eliz@HIDDEN> Subject: Re: 31.0.50; [PATCH] charset_table split In-Reply-To: <86cy1u9lbe.fsf@HIDDEN> Message-ID: <jwvtsv5c1kd.fsf-monnier+emacs@HIDDEN> References: <871pia9y7m.fsf@HIDDEN> <86cy1u9lbe.fsf@HIDDEN> Date: Tue, 24 Feb 2026 15:50:45 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.592 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from domain KAM_ASCII_DIVIDERS 0.8 Email that uses ascii formatting dividers and possible spam tricks X-SPAM-LEVEL: X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: 80474 Cc: "K. Handa" <handa@HIDDEN>, 80474 <at> debbugs.gnu.org, eggert@HIDDEN, eller.helmut@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.3 (--) >> > > The first patch, splits the charset_table array into two parallel >> > > arrays. The second array, the charset_attributes_table, holds what >> > > was previously in the attribute field. That field was the only one of >> > > concern to the GC. Keeping it separate makes some things easier for >> > > the GC. Though, the arrays must be kept in sync. >> >> The field "attributes" of the struct "charset" was introduced by this >> commit. >> ------------------------------------------------------------ >> commit 33b8d5b6c5a22bab069cdac4bddda932b3d18b13 >> Author: Stefan Monnier <monnier@HIDDEN> >> Date: Tue Jan 23 22:30:13 2024 -0500 >> >> (struct charset): Remove dependency on hash-table internals >> >> `struct charset` kept an index into the internal `key_and_value` array >> of hash tables, which only worked because of details of how >> hash-tables are handled. Replace it with a reference to the >> value stored at that location in the hash-table, which saves us an >> indirection while at it. >> >> * src/charset.h (struct charset): Replace `hash_index` field with >> `attributes` field. >> (CHARSET_ATTRIBUTES): Simplify accordingly. >> (CHARSET_HASH_INDEX): Delete unused macro. >> * src/charset.c (Fdefine_charset_internal): >> * src/pdumper.c (dump_charset): Adjust accordingly. >> (dump_charset_table): Set the referrer since that's needed while >> dumping Lisp_Object fields. >> ------------------------------------------------------------ >> So, it is better to ask Stefan to comment on the change. I don't see any problem splitting the charset objects into two (one that contains no GC-traced fields while the other's field are GC-traced). The "keep in sync" doesn't seem particularly onerous. It's akin to a "struct of arrays" vs "array of structs". It would be a problem only if we exposed charset objects (as opposed to merely the charset-IDs) to ELisp. > I'm particularly bothered by the need to "keep the two arrays in > sync", for all the possible uses and varieties of char-tables, so I > hope the guilty parties will comment on that and state their views and > opinions. Hmm... now I'm confused. I thought this was about charsets, not char-tables. === Stefan
bug-gnu-emacs@HIDDEN:bug#80474; Package emacs.
Full text available.Received: (at 80474) by debbugs.gnu.org; 24 Feb 2026 16:08:02 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 24 11:08:02 2026 Received: from localhost ([127.0.0.1]:44156 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vuux8-0001cQ-10 for submit <at> debbugs.gnu.org; Tue, 24 Feb 2026 11:08:02 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:40844) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vuux4-0001bp-UA for 80474 <at> debbugs.gnu.org; Tue, 24 Feb 2026 11:07:59 -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 <eliz@HIDDEN>) id 1vuuwy-0003MF-Rt; Tue, 24 Feb 2026 11:07:52 -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=60w+el2PTUUxZftVU6yqSXiGtl+GqjIDSv8Gm7EVn0A=; b=e4YkUvpeu0mp m/O3wwgL9ynBLT+Tv77kvbCRyOFaTmQv5yOivATPSgMVlWdNvDj1jmbj1zMAKUGI7Cnjiv4xRDYL+ m+PPwk7m7YFxFex0f5PGSfT8YfAlIZazGMBSY4QYt9P0tV+wOkAyPAs2pNwudZD/udS7f0HzEa9Be 5Ud5WbRp1T4TItrvIAkURpFj1bHJRdBmIKR93QzJAZJbmKUZOXU0OGtVmmFhA3qdQ4tOlM1gA/2Sg ispkB+vPtSoQlRfLTja2bhEy+5WFFdSZQI1I9Ks22WsjSVQYVGYx/MYSDkEOs8Oh+D/hSNINxforc UbsnvjaPdd5EK+V0HW2zdA==; Date: Tue, 24 Feb 2026 18:07:49 +0200 Message-Id: <86cy1u9lbe.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: "K. Handa" <handa@HIDDEN> In-Reply-To: <871pia9y7m.fsf@HIDDEN> (handa@HIDDEN) Subject: Re: 31.0.50; [PATCH] charset_table split References: <871pia9y7m.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80474 Cc: 80474 <at> debbugs.gnu.org, eggert@HIDDEN, eller.helmut@HIDDEN, monnier@HIDDEN X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: "K. Handa" <handa@HIDDEN> > Cc: eller.helmut@HIDDEN, 80474 <at> debbugs.gnu.org, monnier@HIDDEN, > eggert@HIDDEN > Date: Tue, 24 Feb 2026 20:29:17 +0900 > > Hi, > > > > From: Helmut Eller <eller.helmut@HIDDEN> > > > CC: Eli Zaretskii <eliz@HIDDEN> > > > Date: Mon, 23 Feb 2026 10:44:27 +0100 > > > > > > Here are two other patches that can go into master before the igc > > > merge. > > Both patches change codes that were intruduced after I originally wrote > charset.[ch]. > > (1) > > > The first patch, splits the charset_table array into two parallel > > > arrays. The second array, the charset_attributes_table, holds what > > > was previously in the attribute field. That field was the only one of > > > concern to the GC. Keeping it separate makes some things easier for > > > the GC. Though, the arrays must be kept in sync. > > The field "attributes" of the struct "charset" was introduced by this > commit. > ------------------------------------------------------------ > commit 33b8d5b6c5a22bab069cdac4bddda932b3d18b13 > Author: Stefan Monnier <monnier@HIDDEN> > Date: Tue Jan 23 22:30:13 2024 -0500 > > (struct charset): Remove dependency on hash-table internals > > `struct charset` kept an index into the internal `key_and_value` array > of hash tables, which only worked because of details of how > hash-tables are handled. Replace it with a reference to the > value stored at that location in the hash-table, which saves us an > indirection while at it. > > * src/charset.h (struct charset): Replace `hash_index` field with > `attributes` field. > (CHARSET_ATTRIBUTES): Simplify accordingly. > (CHARSET_HASH_INDEX): Delete unused macro. > * src/charset.c (Fdefine_charset_internal): > * src/pdumper.c (dump_charset): Adjust accordingly. > (dump_charset_table): Set the referrer since that's needed while > dumping Lisp_Object fields. > ------------------------------------------------------------ > So, it is better to ask Stefan to comment on the change. > > (2) > > > The second patch, removes the statically allocated charset_table_init > > > array. With that, the charset_table gets resized dynamically and only > > > the used part gets dumped. > > The array "charset_table_init" was intruduced by this commit. > ------------------------------------------------------------ > commit f701dc2abbcfb64c0c4d02ac899dccb03ee2b246 > Author: Paul Eggert <eggert@HIDDEN> > Date: Fri Sep 30 10:07:40 2011 -0700 > > Remove dependency on glibc malloc internals. > > * alloc.c (XMALLOC_OVERRUN_CHECK_OVERHEAD, XMALLOC_OVERRUN_CHECK_SIZE): > Move back here from lisp.h, but with their new implementations. > (XMALLOC_BASE_ALIGNMENT, COMMON_MULTIPLE, XMALLOC_HEADER_ALIGNMENT) > (XMALLOC_OVERRUN_SIZE_SIZE): Move these new lisp.h macros here. > * charset.c (charset_table_init): New static var. > (syms_of_charset): Use it instead of xmalloc. This removes a > dependency on glibc malloc internals. See Eli Zaretskii's comment in > <http://lists.gnu.org/archive/html/emacs-devel/2011-09/msg00815.html>. > * lisp.h (XMALLOC_OVERRUN_CHECK_OVERHEAD, XMALLOC_OVERRUN_CHECK_SIZE): > Move back to alloc.c. > (XMALLOC_BASE_ALIGNMENT, COMMON_MULTIPLE, XMALLOC_HEADER_ALIGNMENT) > (XMALLOC_OVERRUN_SIZE_SIZE): Move to alloc.c. > ------------------------------------------------------------ > So, it is better to ask Paul to comment on the change. Thanks. So I hope Stefan and Paul will look into this. I'm particularly bothered by the need to "keep the two arrays in sync", for all the possible uses and varieties of char-tables, so I hope the guilty parties will comment on that and state their views and opinions.
bug-gnu-emacs@HIDDEN:bug#80474; Package emacs.
Full text available.
Received: (at 80474) by debbugs.gnu.org; 24 Feb 2026 11:29:37 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 24 06:29:37 2026
Received: from localhost ([127.0.0.1]:40238 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vuqbg-0006BC-L3
for submit <at> debbugs.gnu.org; Tue, 24 Feb 2026 06:29:37 -0500
Received: from eggs.gnu.org ([2001:470:142:3::10]:54064)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <handa@HIDDEN>) id 1vuqbd-0006Aw-T3
for 80474 <at> debbugs.gnu.org; Tue, 24 Feb 2026 06:29:34 -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 <handa@HIDDEN>)
id 1vuqbX-0005iW-79; Tue, 24 Feb 2026 06:29:27 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=MIME-Version:Date:In-Reply-To:Subject:To:From:
references; bh=G9jSlOAmtZKfpHZM+2Jj/qQircaCjco1yLofVVZJm54=; b=IXDUtttgY97kYJ
lFINjcsUArKBo9b3eBLrmzn2k3k9rGYMTZDB1k7n3j9Gd5TtLXqZsAtWZ49+BWR1VbmVXMTuHsb0e
+7W0xTH4P4blASN0JFpVK0nlvrXIuRGS9JeU7a3NmO+pWamXYP58NZQPDPTWF7lzqRHVg5V/Zav+6
OpNs1HIaZHGwZTjBacGMh4ZHLqcocBU5p2FIwH5Z7s73a0pS31/BhcsFAI5X/ILP3Iph2DkFGrqsB
/hBxImwJfF4D4AusO+FFPag1WSkgYVcsqzDq02N1j2tGTBnnFBoImg9zjw0P7ibG6UHFH5ExHtMbE
jbHE+pw03PcE7dmurByw==;
From: "K. Handa" <handa@HIDDEN>
To: Eli Zaretskii <eliz@HIDDEN>
Subject: Re: 31.0.50; [PATCH] charset_table split
In-Reply-To: <86ikbnbd8l.fsf@HIDDEN> (message from Eli Zaretskii on Mon, 23
Feb 2026 19:07:06 +0200)
Date: Tue, 24 Feb 2026 20:29:17 +0900
Message-ID: <871pia9y7m.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 80474
Cc: 80474 <at> debbugs.gnu.org, eggert@HIDDEN, eller.helmut@HIDDEN,
monnier@HIDDEN
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
Hi,
> > From: Helmut Eller <eller.helmut@HIDDEN>
> > CC: Eli Zaretskii <eliz@HIDDEN>
> > Date: Mon, 23 Feb 2026 10:44:27 +0100
> >
> > Here are two other patches that can go into master before the igc
> > merge.
Both patches change codes that were intruduced after I originally wrote
charset.[ch].
(1)
> > The first patch, splits the charset_table array into two parallel
> > arrays. The second array, the charset_attributes_table, holds what
> > was previously in the attribute field. That field was the only one of
> > concern to the GC. Keeping it separate makes some things easier for
> > the GC. Though, the arrays must be kept in sync.
The field "attributes" of the struct "charset" was introduced by this
commit.
------------------------------------------------------------
commit 33b8d5b6c5a22bab069cdac4bddda932b3d18b13
Author: Stefan Monnier <monnier@HIDDEN>
Date: Tue Jan 23 22:30:13 2024 -0500
(struct charset): Remove dependency on hash-table internals
`struct charset` kept an index into the internal `key_and_value` array
of hash tables, which only worked because of details of how
hash-tables are handled. Replace it with a reference to the
value stored at that location in the hash-table, which saves us an
indirection while at it.
* src/charset.h (struct charset): Replace `hash_index` field with
`attributes` field.
(CHARSET_ATTRIBUTES): Simplify accordingly.
(CHARSET_HASH_INDEX): Delete unused macro.
* src/charset.c (Fdefine_charset_internal):
* src/pdumper.c (dump_charset): Adjust accordingly.
(dump_charset_table): Set the referrer since that's needed while
dumping Lisp_Object fields.
------------------------------------------------------------
So, it is better to ask Stefan to comment on the change.
(2)
> > The second patch, removes the statically allocated charset_table_init
> > array. With that, the charset_table gets resized dynamically and only
> > the used part gets dumped.
The array "charset_table_init" was intruduced by this commit.
------------------------------------------------------------
commit f701dc2abbcfb64c0c4d02ac899dccb03ee2b246
Author: Paul Eggert <eggert@HIDDEN>
Date: Fri Sep 30 10:07:40 2011 -0700
Remove dependency on glibc malloc internals.
* alloc.c (XMALLOC_OVERRUN_CHECK_OVERHEAD, XMALLOC_OVERRUN_CHECK_SIZE):
Move back here from lisp.h, but with their new implementations.
(XMALLOC_BASE_ALIGNMENT, COMMON_MULTIPLE, XMALLOC_HEADER_ALIGNMENT)
(XMALLOC_OVERRUN_SIZE_SIZE): Move these new lisp.h macros here.
* charset.c (charset_table_init): New static var.
(syms_of_charset): Use it instead of xmalloc. This removes a
dependency on glibc malloc internals. See Eli Zaretskii's comment in
<http://lists.gnu.org/archive/html/emacs-devel/2011-09/msg00815.html>.
* lisp.h (XMALLOC_OVERRUN_CHECK_OVERHEAD, XMALLOC_OVERRUN_CHECK_SIZE):
Move back to alloc.c.
(XMALLOC_BASE_ALIGNMENT, COMMON_MULTIPLE, XMALLOC_HEADER_ALIGNMENT)
(XMALLOC_OVERRUN_SIZE_SIZE): Move to alloc.c.
------------------------------------------------------------
So, it is better to ask Paul to comment on the change.
---
K. Handa
handa@HIDDEN
bug-gnu-emacs@HIDDEN:bug#80474; Package emacs.
Full text available.Received: (at 80474) by debbugs.gnu.org; 23 Feb 2026 17:07:18 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 23 12:07:18 2026 Received: from localhost ([127.0.0.1]:56244 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vuZOv-0006wl-51 for submit <at> debbugs.gnu.org; Mon, 23 Feb 2026 12:07:18 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:54978) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vuZOs-0006vC-0X for 80474 <at> debbugs.gnu.org; Mon, 23 Feb 2026 12:07:15 -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 <eliz@HIDDEN>) id 1vuZOm-000164-Gc; Mon, 23 Feb 2026 12:07:08 -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=pkfdrTjoSkZO2tZCZV8HvoXZyFt5Ny+MhxklXArhB7s=; b=i6tEVDdxQPqg F9pkMwlKK25UXlHJrdlYGH21YBDA6VK66/KFNN3rQtEdPDg5hQ6Iq4d2ZNuqJIOFPBSfgw8j1PVpJ cDEyZAVKz8STD0Pf5WmTKJjCamdZdgxWGjsXqqLvrWkcPfrRiJa923i5upqYoL+KZ971KGnqpqr3M 0p28qV71XI5XdR8ZtdH8pTZVFwQ2pWjVN8dYtPbCAUhkxQv6jeqTQPLkCho4RBVeytcpjfNwDK8WC SyK3497xr12s9v6l4lIaqm0zU8+SwrydsbELo3XdEKxsq/pZhoivHUB+WJZHTrVJnlSXQ8DLbfs43 quhJ19NXSmOKv14CoXqoPg==; Date: Mon, 23 Feb 2026 19:07:06 +0200 Message-Id: <86ikbnbd8l.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Helmut Eller <eller.helmut@HIDDEN>, Kenichi Handa <handa@HIDDEN> In-Reply-To: <87a4wzdcas.fsf@HIDDEN> (message from Helmut Eller on Mon, 23 Feb 2026 10:44:27 +0100) Subject: Re: 31.0.50; [PATCH] charset_table split References: <87a4wzdcas.fsf@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 80474 Cc: 80474 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > From: Helmut Eller <eller.helmut@HIDDEN> > CC: Eli Zaretskii <eliz@HIDDEN> > Date: Mon, 23 Feb 2026 10:44:27 +0100 > > Here are two other patches that can go into master before the igc > merge. > > The first patch, splits the charset_table array into two parallel > arrays. The second array, the charset_attributes_table, holds what > was previously in the attribute field. That field was the only one of > concern to the GC. Keeping it separate makes some things easier for > the GC. Though, the arrays must be kept in sync. > > The second patch, removes the statically allocated charset_table_init > array. With that, the charset_table gets resized dynamically and only > the used part gets dumped. > > I suppose Eli is the person in charge for this area? Sadly, it's much worse: we don't have anyone on-board who is familiar enough with the character-table stuff in Emacs to ask to review such significant changes in char-tables. In particular, there's the uniprop tables that are even more black-magic than the rest. The only person who could meaningfully review and comment on this is Handa-san (CC'ed), if he could find time to do so, since he designed and wrote most of this stuff to begin with. Failing that, I'd rather not make such changes, unless the gains are really enormous. Sorry.
bug-gnu-emacs@HIDDEN:bug#80474; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 23 Feb 2026 09:44:47 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Feb 23 04:44:46 2026
Received: from localhost ([127.0.0.1]:50666 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vuSUf-0001NS-Nm
for submit <at> debbugs.gnu.org; Mon, 23 Feb 2026 04:44:46 -0500
Received: from lists.gnu.org ([2001:470:142::17]:42144)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <eller.helmut@HIDDEN>)
id 1vuSUc-0001N7-Qj
for submit <at> debbugs.gnu.org; Mon, 23 Feb 2026 04:44:43 -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 <eller.helmut@HIDDEN>)
id 1vuSUT-00032f-MB
for bug-gnu-emacs@HIDDEN; Mon, 23 Feb 2026 04:44:33 -0500
Received: from mail-wm1-x335.google.com ([2a00:1450:4864:20::335])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.90_1) (envelope-from <eller.helmut@HIDDEN>)
id 1vuSUR-0006VG-EY
for bug-gnu-emacs@HIDDEN; Mon, 23 Feb 2026 04:44:33 -0500
Received: by mail-wm1-x335.google.com with SMTP id
5b1f17b1804b1-4807068eacbso32352205e9.2
for <bug-gnu-emacs@HIDDEN>; Mon, 23 Feb 2026 01:44:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1771839869; x=1772444669; darn=gnu.org;
h=mime-version:user-agent:message-id:date:cc:subject:to:from:from:to
:cc:subject:date:message-id:reply-to;
bh=N95ugQsV3MR/ERqHsb2TpKxPSjlz1luCoC2YWQQXu4o=;
b=YCoVqz3X+HcL4DERLe9nFbpHm5ovpUSD+N15MkRKk7M/psqGMgwpohSoCc3F6X0bn3
2vI7QRq11QCT1AUkLy2mEI2F/TvoCP1dIqS0xWCB46ZPTeIMqfYZb0ByUAkFRZxIgRJW
AzYUykI3Rdmi/tQGB88QQZopfSX5KVFXfXzqnZy1Ks+Phufn8J3IlSE23idU58DiXTTe
Ro1RbbCnAGY9ysOxB0f42wJaNu220WnvB1a+BxVLSpUWZvPWopJAsgbkBrAolDl7mNb0
YV2zJkJOXYlOGdcRZiaEOnjw+KnXQN5Nz5ZwOQPrFo6qK+XkVGvJv3hE3wXB9OLK3Stv
eWKg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1771839869; x=1772444669;
h=mime-version:user-agent:message-id:date:cc:subject:to:from:x-gm-gg
:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
bh=N95ugQsV3MR/ERqHsb2TpKxPSjlz1luCoC2YWQQXu4o=;
b=fxNye4pvTlOMZb11cXbkZ01gBiIm3dr3SEZ6jQNqUWQTdCCjKZX3UKHq0rTtN5W3iC
qRWivXN1gUNkA9eX52dzPGbIVR9AKyWo/MI0dtNS81cwfbmSGDJtdaXQ1YbhOXMLAsre
xVZO6X2VSpx4ooBcZVoXkkPAa9osO11D68XR72lC/Ul2qhJ7chKwIKoQSy0vf5Ub50ji
ltovVhQImuZVl4yrMjGVKGkuQVMa255iX4RwNvJZ8jAWtSdDLygqrSwjoUeiicexlPWz
udyYWJ3wqCdLTqOy0dVcFG0GR9vUXtkSMpSiNMxhwQR8JNK/ADfB5hKQ6Zmt5Sjl5tmZ
s//A==
X-Gm-Message-State: AOJu0YyPaXCrTeYyXLvsJMAaMEJ4sMfy5O7d5nqPHszIkBgzvxKYbbzj
fCbllF7oNkZMPtAfJQhYeBLG7pyDE/GTGt4yj80/g5uXFQ8TP+HFP86l
X-Gm-Gg: AZuq6aJywxvOtxnZ0vFmd06CAAj/wSGF/3uBTzcEsKc7Ff2YmqT3mwDP87eaONFuNJ0
nUA1RpGRK2Uty42EhXvjoAOYkcEpy35PiSPyCN3Olmn7cSN7b3TrosfUI8OuVf6CthyAVK9rXod
LRDRNRjih6V1sEzu8ExWB1arDPEc3LLTW4JBU4Qj4VLb+dl6GjIgLOgx4aI2gYEFcVuyTAjgx5I
JHP3WsG+z9I7K91l6KWCyqsQwCN+3MTjnpMhU9Sqs6T4xfIqNjeFrhzUvq5sCyiQIlhKUKYN0q5
+PKtv2XN83suCmNgyDx9zouYMtfPTV/x0/XjT7JRvEQGx++z6vKihL1xtDg5O7qgL9pR4RWIBDS
mJraE7C7h05sVJX8Nr7YrSpUiKYE+peZbWZhoOCbRhJGZlJoTChXuu0cxJInh9xMn1udIbc3yE+
SoBePVZo4NXqjbF/5YqeJosFYLx8dt
X-Received: by 2002:a05:600c:4e8a:b0:47b:e2a9:2bd7 with SMTP id
5b1f17b1804b1-483a95decc5mr117993695e9.19.1771839869091;
Mon, 23 Feb 2026 01:44:29 -0800 (PST)
Received: from caladan ([212.46.170.2]) by smtp.gmail.com with ESMTPSA id
5b1f17b1804b1-483a31f9af5sm237826025e9.12.2026.02.23.01.44.28
(version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
Mon, 23 Feb 2026 01:44:28 -0800 (PST)
From: Helmut Eller <eller.helmut@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: 31.0.50; [PATCH] charset_table split
X-Debbugs-Cc:
Date: Mon, 23 Feb 2026 10:44:27 +0100
Message-ID: <87a4wzdcas.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
Received-SPF: pass client-ip=2a00:1450:4864:20::335;
envelope-from=eller.helmut@HIDDEN; helo=mail-wm1-x335.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: 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: Here are two other patches that can go into master before
the igc merge. The first patch,
splits the charset_table array into two parallel
arrays. The second array, the charset_attributes_table,
holds what was previously
in the attribute field. That field was the only one [...]
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 (eller.helmut[at]gmail.com)
1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail)
1.0 FORGED_GMAIL_RCVD 'From' gmail.com does not match 'Received'
headers -0.0 SPF_HELO_PASS SPF: HELO matches SPF record
X-Debbugs-Envelope-To: submit
Cc: Eli Zaretskii <eliz@HIDDEN>
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.0 (+)
--=-=-=
Content-Type: text/plain
Here are two other patches that can go into master before the igc
merge.
The first patch, splits the charset_table array into two parallel
arrays. The second array, the charset_attributes_table, holds what
was previously in the attribute field. That field was the only one of
concern to the GC. Keeping it separate makes some things easier for
the GC. Though, the arrays must be kept in sync.
The second patch, removes the statically allocated charset_table_init
array. With that, the charset_table gets resized dynamically and only
the used part gets dumped.
I suppose Eli is the person in charge for this area?
--=-=-=
Content-Type: text/x-diff
Content-Disposition: attachment;
filename=0001-Move-the-attribute-field-of-charsets-to-a-separate-v.patch
From a53975721a8979953fb867e3c534c3653c969cd2 Mon Sep 17 00:00:00 2001
From: Helmut Eller <eller.helmut@HIDDEN>
Date: Tue, 28 Oct 2025 09:21:23 +0100
Subject: [PATCH 1/2] Move the attribute field of charsets to a separate vector
This simplifies the GC code, as this was the only field in the charset
struct that referenced the GC heap. Without it, we no longer need to
trace the charset_table.
* src/charset.h (struct charset.attributes): Removed.
(charset_attributes_getter): New helper.
(CHARSET_ATTRIBUTES): Use it.
* src/charset.c (charset_attributes_table): New.
(Fdefine_charset_internal): Place attrs in charset_attributes_table.
(syms_of_charset): Initialize charset_attributes_table.
(mark_charset): Deleted.
* src/pdumper.c (dump_charset): Skip attributes field.
* src/lisp.h (mark_charset): Deleted.
* src/alloc.c (garbage_collect): mark_charset no longer needed.
---
src/alloc.c | 1 -
src/charset.c | 39 +++++++++++++++++++++++----------------
src/charset.h | 12 +++++++++---
src/lisp.h | 1 -
src/pdumper.c | 3 +--
5 files changed, 33 insertions(+), 23 deletions(-)
diff --git a/src/alloc.c b/src/alloc.c
index c0c24c65737..5da38cadb5d 100644
--- a/src/alloc.c
+++ b/src/alloc.c
@@ -5866,7 +5866,6 @@ garbage_collect (void)
mark_terminals ();
mark_kboards ();
mark_threads ();
- mark_charset ();
mark_composite ();
mark_profiler ();
#ifdef HAVE_PGTK
diff --git a/src/charset.c b/src/charset.c
index 42dc6a60367..11d181d4032 100644
--- a/src/charset.c
+++ b/src/charset.c
@@ -65,6 +65,12 @@ Copyright (C) 2003, 2004
int charset_table_size;
int charset_table_used;
+/* Table of attribute vectors. charset_attributes_table[id] contains
+ the attribute vector for the charset at charset_table[id].
+
+ This is a separate vector to simplify GC. */
+Lisp_Object charset_attributes_table;
+
/* Special charsets corresponding to symbols. */
int charset_ascii;
int charset_eight_bit;
@@ -1131,13 +1137,19 @@ DEFUN ("define-charset-internal", Fdefine_charset_internal,
coding_system.charbuf[i] entries, which are 'int'. */
int old_size = charset_table_size;
ptrdiff_t new_size = old_size;
- struct charset *new_table =
- xpalloc (0, &new_size, 1,
- min (INT_MAX, MOST_POSITIVE_FIXNUM),
- sizeof *charset_table);
- memcpy (new_table, charset_table, old_size * sizeof *new_table);
- charset_table = new_table;
+ struct charset *new_table
+ = xpalloc (0, &new_size, 1,
+ min (INT_MAX, MOST_POSITIVE_FIXNUM),
+ sizeof *charset_table);
+ memcpy (new_table, charset_table,
+ old_size * sizeof *new_table);
+ charset_table = new_table;
charset_table_size = new_size;
+ Lisp_Object new_attr_table = make_vector (new_size, Qnil);
+ for (size_t i = 0; i < old_size; i++)
+ ASET (new_attr_table, i,
+ AREF (charset_attributes_table, i));
+ charset_attributes_table = new_attr_table;
/* FIXME: This leaks memory, as the old charset_table becomes
unreachable. If the old charset table is charset_table_init
then this leak is intentional; otherwise, it's unclear.
@@ -1152,8 +1164,9 @@ DEFUN ("define-charset-internal", Fdefine_charset_internal,
ASET (attrs, charset_id, make_fixnum (id));
charset.id = id;
- charset.attributes = attrs;
charset_table[id] = charset;
+ ASET (charset_attributes_table, id, attrs);
+ eassert (ASIZE (charset_attributes_table) == charset_table_size);
if (charset.method == CHARSET_METHOD_MAP)
{
@@ -2272,15 +2285,6 @@ DEFUN ("sort-charsets", Fsort_charsets, Ssort_charsets, 1, 1, 0,
return charsets;
}
-/* Not strictly necessary, because all charset attributes are also
- reachable from `Vcharset_hash_table`. */
-void
-mark_charset (void)
-{
- for (int i = 0; i < charset_table_used; i++)
- mark_object (charset_table[i].attributes);
-}
-
void
init_charset (void)
@@ -2383,6 +2387,9 @@ syms_of_charset (void)
charset_table_used = 0;
PDUMPER_REMEMBER_SCALAR (charset_table_used);
+ charset_attributes_table = make_vector (charset_table_size, Qnil);
+ staticpro (&charset_attributes_table);
+
defsubr (&Scharsetp);
defsubr (&Smap_charset_chars);
defsubr (&Sdefine_charset_internal);
diff --git a/src/charset.h b/src/charset.h
index 56ed62b4473..0738217dc0c 100644
--- a/src/charset.h
+++ b/src/charset.h
@@ -150,8 +150,6 @@ #define EMACS_CHARSET_H
/* Index to charset_table. */
int id;
- Lisp_Object attributes;
-
/* Dimension of the charset: 1, 2, 3, or 4. */
int dimension;
@@ -250,6 +248,8 @@ #define EMACS_CHARSET_H
extern int charset_table_size;
extern int charset_table_used;
+extern Lisp_Object charset_attributes_table;
+
#define CHARSET_FROM_ID(id) (charset_table + (id))
extern Lisp_Object Vcharset_ordered_list;
@@ -287,8 +287,14 @@ #define CHARSET_SYMBOL_ID(symbol) \
#define CHARSET_SYMBOL_HASH_INDEX(symbol) \
hash_find (XHASH_TABLE (Vcharset_hash_table), symbol)
+INLINE Lisp_Object
+charset_attributes_getter (struct charset *charset)
+{
+ return AREF (charset_attributes_table, charset->id);
+}
+
/* Return the attribute vector of CHARSET. */
-#define CHARSET_ATTRIBUTES(charset) (charset)->attributes
+#define CHARSET_ATTRIBUTES(charset) (charset_attributes_getter (charset))
#define CHARSET_ID(charset) ((charset)->id)
#define CHARSET_DIMENSION(charset) ((charset)->dimension)
diff --git a/src/lisp.h b/src/lisp.h
index 8c9ba6c5fde..2f5c39bb031 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -4226,7 +4226,6 @@ #define CONS_TO_INTEGER(cons, type, var) \
extern void syms_of_character (void);
/* Defined in charset.c. */
-extern void mark_charset (void);
extern void init_charset (void);
extern void init_charset_once (void);
extern void syms_of_charset (void);
diff --git a/src/pdumper.c b/src/pdumper.c
index c21af24d9f1..3f338db33c6 100644
--- a/src/pdumper.c
+++ b/src/pdumper.c
@@ -3208,7 +3208,7 @@ dump_object_for_offset (struct dump_context *ctx, Lisp_Object object)
static dump_off
dump_charset (struct dump_context *ctx, int cs_i)
{
-#if CHECK_STRUCTS && !defined (HASH_charset_E31F4B5D96)
+#if CHECK_STRUCTS && !defined (HASH_charset_C9F4DCA7A7)
# error "charset changed. See CHECK_STRUCTS comment in config.h."
#endif
/* We can't change the alignment here, because ctx->offset is what
@@ -3220,7 +3220,6 @@ dump_charset (struct dump_context *ctx, int cs_i)
if (cs_i < charset_table_used) /* Don't look at uninitialized data. */
{
DUMP_FIELD_COPY (&out, cs, id);
- dump_field_lv (ctx, &out, cs, &cs->attributes, WEIGHT_NORMAL);
DUMP_FIELD_COPY (&out, cs, dimension);
memcpy (out.code_space, &cs->code_space, sizeof (cs->code_space));
if (cs->code_space_mask)
--
2.47.3
--=-=-=
Content-Type: text/x-diff
Content-Disposition: attachment;
filename=0002-Remove-the-charset_table_init-array.patch
From 476b36809e144401ebb90ecea4a08fd1bca327f9 Mon Sep 17 00:00:00 2001
From: Helmut Eller <eller.helmut@HIDDEN>
Date: Sat, 1 Nov 2025 19:13:06 +0100
Subject: [PATCH 2/2] Remove the charset_table_init array
Determining the best size for a static array seems difficult; so
allocate it dynamically.
* src/charset.c (CHARSET_TABLE_INIT_SIZE): New constant.
(syms_of_charset): Malloc charset_table here.
(charset_table_init): Removed.
(shrink_charset_table): New function.
(Fclear_charset_maps): Call it.
* src/charset.h (charset_table_init): Removed.
(charset_attributes_getter): Add an assertion.
* src/pdumper (dump_charset_table): Assert that charset_table_size ==
charset_table_used.
---
src/charset.c | 46 +++++++++++++++++++++++++++++++++-------------
src/charset.h | 1 +
src/pdumper.c | 5 +----
3 files changed, 35 insertions(+), 17 deletions(-)
diff --git a/src/charset.c b/src/charset.c
index 11d181d4032..ff501022af9 100644
--- a/src/charset.c
+++ b/src/charset.c
@@ -2117,6 +2117,29 @@ DEFUN ("iso-charset", Fiso_charset, Siso_charset, 3, 3, 0,
return (id >= 0 ? CHARSET_NAME (CHARSET_FROM_ID (id)) : Qnil);
}
+/* Shrink charset_table to charset_table_used. */
+static void
+shrink_charset_table (void)
+{
+ eassert (charset_table_size >= charset_table_used);
+ eassert (ASIZE (charset_attributes_table) == charset_table_size);
+
+ struct charset *old = charset_table;
+ size_t nbytes = charset_table_used * sizeof *old;
+ struct charset *new = xmalloc (nbytes);
+ memcpy (new, old, nbytes);
+ charset_table = new;
+ xfree (old);
+
+ Lisp_Object new_attr_table = make_vector (charset_table_used, Qnil);
+ for (size_t i = 0; i < charset_table_used; i++)
+ ASET (new_attr_table, i, AREF (charset_attributes_table, i));
+ charset_attributes_table = new_attr_table;
+
+ charset_table_size = charset_table_used;
+
+ eassert (ASIZE (charset_attributes_table) == charset_table_size);
+}
DEFUN ("clear-charset-maps", Fclear_charset_maps, Sclear_charset_maps,
0, 0, 0,
@@ -2135,6 +2158,8 @@ DEFUN ("clear-charset-maps", Fclear_charset_maps, Sclear_charset_maps,
if (CHAR_TABLE_P (Vchar_unify_table))
Foptimize_char_table (Vchar_unify_table, Qnil);
+ shrink_charset_table ();
+
return Qnil;
}
@@ -2344,17 +2369,11 @@ init_charset_once (void)
PDUMPER_REMEMBER_SCALAR (charset_ksc5601);
}
-/* Allocate an initial charset table that is large enough to handle
- Emacs while it is bootstrapping. As of September 2011, the size
- needs to be at least 166; make it a bit bigger to allow for future
- expansion.
-
- Don't make the value so small that the table is reallocated during
- bootstrapping, as glibc malloc calls larger than just under 64 KiB
- during an initial bootstrap wreak havoc after dumping; see the
- M_MMAP_THRESHOLD value in alloc.c, plus there is an extra overhead
- internal to glibc malloc and perhaps to Emacs malloc debugging. */
-static struct charset charset_table_init[180];
+/* Intitial value for charset_table_size. As of October 2025, the
+ charset table uses 179 entries. charset_table grows if needed and
+ we only dump the used entries; so getting the initial value right
+ is not overly important. */
+#define CHARSET_TABLE_INIT_SIZE 190
void
syms_of_charset (void)
@@ -2381,9 +2400,10 @@ syms_of_charset (void)
staticpro (&Vcharset_hash_table);
Vcharset_hash_table = CALLN (Fmake_hash_table, QCtest, Qeq);
- charset_table = charset_table_init;
- charset_table_size = ARRAYELTS (charset_table_init);
+ charset_table_size = CHARSET_TABLE_INIT_SIZE;
PDUMPER_REMEMBER_SCALAR (charset_table_size);
+ charset_table
+ = xmalloc (charset_table_size * sizeof *charset_table);
charset_table_used = 0;
PDUMPER_REMEMBER_SCALAR (charset_table_used);
diff --git a/src/charset.h b/src/charset.h
index 0738217dc0c..bf14b15beba 100644
--- a/src/charset.h
+++ b/src/charset.h
@@ -290,6 +290,7 @@ #define CHARSET_SYMBOL_HASH_INDEX(symbol) \
INLINE Lisp_Object
charset_attributes_getter (struct charset *charset)
{
+ eassert (ASIZE (charset_attributes_table) == charset_table_size);
return AREF (charset_attributes_table, charset->id);
}
diff --git a/src/pdumper.c b/src/pdumper.c
index 3f338db33c6..6461ec170d0 100644
--- a/src/pdumper.c
+++ b/src/pdumper.c
@@ -3260,10 +3260,7 @@ dump_charset_table (struct dump_context *ctx)
dump_off offset = ctx->offset;
if (dump_set_referrer (ctx))
ctx->current_referrer = build_string ("charset_table");
- /* We are dumping the entire table, not just the used slots, because
- otherwise when we restore from the pdump file, the actual size of
- the table will be smaller than charset_table_size, and we will
- crash if/when a new charset is defined. */
+ eassert (charset_table_size == charset_table_used);
for (int i = 0; i < charset_table_size; ++i)
dump_charset (ctx, i);
dump_clear_referrer (ctx);
--
2.47.3
--=-=-=--
Helmut Eller <eller.helmut@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#80474; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.