From: Paul Eggert <eggert@cs.ucla.edu>
To: 8600@debbugs.gnu.org
Subject: bug#8600: struct charset.code_space[15] contains garbage
Date: Sun, 01 May 2011 09:59:25 -0700 [thread overview]
Message-ID: <4DBD916D.6000804@cs.ucla.edu> (raw)
While testing the 32+64 port I noticed that a too-wide value
is stuffed into charset.code_space[15], which means that
slot has a garbage value (at least, it's garbage on typical
machines with 32-bit int). As far as I can see, the garbage
value is never used, so it's a bit cleaner to never compute
or store it.
I plan to install the following patch to do that.
This patch is relevant to ordinary 32- and 64-bit hosts, too,
so I'm separating it out.
* charset.h (struct charset.code_space): Now has 15 elements, not 16.
* charset.c (Fdefine_charset_internal): Don't initialize
charset.code_space[15]. The value was garbage, on hosts with
32-bit int.
=== modified file 'src/charset.c'
--- src/charset.c 2011-04-26 06:17:52 +0000
+++ src/charset.c 2011-05-01 06:28:23 +0000
@@ -869,7 +869,7 @@
ASET (attrs, charset_name, args[charset_arg_name]);
val = args[charset_arg_code_space];
- for (i = 0, dimension = 0, nchars = 1; i < 4; i++)
+ for (i = 0, dimension = 0, nchars = 1; ; i++)
{
int min_byte, max_byte;
@@ -880,10 +880,12 @@
charset.code_space[i * 4] = min_byte;
charset.code_space[i * 4 + 1] = max_byte;
charset.code_space[i * 4 + 2] = max_byte - min_byte + 1;
+ if (max_byte > 0)
+ dimension = i + 1;
+ if (i == 3)
+ break;
nchars *= charset.code_space[i * 4 + 2];
charset.code_space[i * 4 + 3] = nchars;
- if (max_byte > 0)
- dimension = i + 1;
}
val = args[charset_arg_dimension];
=== modified file 'src/charset.h'
--- src/charset.h 2011-04-11 06:48:18 +0000
+++ src/charset.h 2011-05-01 16:22:33 +0000
@@ -155,10 +155,11 @@
byte code of the (N+1)th dimension, <code_space>[4N+1] is a
maximum byte code of the (N+1)th dimension, <code_space>[4N+2] is
(<code_space>[4N+1] - <code_space>[4N] + 1), <code_space>[4N+3]
- is a number of characters containd in the first to (N+1)th
- dismesions. We get `char-index' of a `code-point' from this
+ is the number of characters contained in the first through (N+1)th
+ dimensions, except that there is no <code_space>[15].
+ We get `char-index' of a `code-point' from this
information. */
- int code_space[16];
+ int code_space[15];
/* If B is a byte of Nth dimension of a code-point, the (N-1)th bit
of code_space_mask[B] is set. This array is used to quickly
reply other threads:[~2011-05-01 16:59 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4DBD916D.6000804@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=8600@debbugs.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).