From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Dmitry Antipov <dmantipov@yandex.ru>
Cc: emacs-devel@gnu.org
Subject: Re: Old topic(s) again [was: Re: Proposal: immediate strings]
Date: Wed, 04 Jul 2012 09:08:30 -0400 [thread overview]
Message-ID: <jwv3957ofn5.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <4FF3FE6E.8080202@yandex.ru> (Dmitry Antipov's message of "Wed, 04 Jul 2012 12:27:26 +0400")
> This feature is not thrown away, so I would like to get more comments
> around it.
I'm still not sure it's worth the trouble (although I've been running
here with a similar patch for the last several years).
A few comments below.
> +dnl Determine the basic type of ptrdiff_t.
> +AC_CHECK_SIZEOF([int])
> +AC_CHECK_SIZEOF([long])
> +AC_CHECK_SIZEOF([long long])
> +AC_CHECK_SIZEOF([ptrdiff_t])
> +AC_MSG_CHECKING([for the basic type of ptrdiff_t])
> +if test $ac_cv_sizeof_int = $ac_cv_sizeof_ptrdiff_t; then
> + emacs_cv_type_ptrdiff_t="int"
> +elif test $ac_cv_sizeof_long = $ac_cv_sizeof_ptrdiff_t; then
> + emacs_cv_type_ptrdiff_t="long"
> +elif test $ac_cv_sizeof_long_long = $ac_cv_sizeof_ptrdiff_t; then
> + emacs_cv_type_ptrdiff_t="long long"
> +else
> + emacs_cv_type_ptrdiff_t="unknown"
> +fi
> +AC_MSG_RESULT([$emacs_cv_type_ptrdiff_t])
> +if test $emacs_cv_type_ptrdiff_t != "unknown"; then
> + AC_DEFINE_UNQUOTED([TYPE_PTRDIFF_T], [$emacs_cv_type_ptrdiff_t],
> + [Define to the basic type of ptrdiff_t])
> +else
> + AC_MSG_ERROR([Unable to find the basic type of ptrdiff_t.])
> +fi
I really would much rather avoid such things. Why do we need it?
> - && ((struct Lisp_String *) p)->data != NULL);
> + && live_string_data_p ((struct Lisp_String *) p));
Why can't we keep using the same simple test (combined with testing
immbit, obviously)?
> -/* Convenience macros for dealing with Lisp strings. */
Why do you move this block of definitions?
> +{
> + /* Text properties in this string. Should be the first
> + member since NEXT_FREE_LISP_STRING from alloc.c uses it. */
> + INTERVAL intervals;
I don't understand this comment (you haven't changed
NEXT_FREE_LISP_STRING AFAICT, but the field is not first in the current
code).
> + union {
> + /* GC mark bit and subtype bit are in IMM just by convention - when
> + IMMBIT is 0, the DAT field is used except it's UNUSED field. */
This comment seems out of date: gcmarkbit seems to be in both `imm' and
`dat', and I don't see any "subtype" bit, especially not one that's only
in `imm'. Finally, I can't find any `unused' field either.
> + struct {
> + unsigned immbit : 1;
> + unsigned size : BITS_PER_CHAR - 1;
> + unsigned char data[STRING_IMM_SIZE];
> + unsigned size_byte : BITS_PER_CHAR - 1;
> + unsigned gcmarkbit : 1;
> + } imm;
> +
> + struct {
> + unsigned immbit : 1;
> + unsigned TYPE_PTRDIFF_T size : BITS_PER_PTRDIFF_T - 1;
> + unsigned char *data;
> + unsigned TYPE_PTRDIFF_T size_byte : BITS_PER_PTRDIFF_T - 1;
> + unsigned gcmarkbit : 1;
> + } dat;
> + } u;
> +};
The comment should explain here the use of STRING_UNIBYTE_IMM/DAT_MARK.
One more thing: while I'm quite willing to believe that this placement
of gcmarkbit at the end of both structs (placed after differently-sized
bit fields) works fine in practice, I'd be interested to know to what
extent the C language guarantees that it will work.
Stefan
next prev parent reply other threads:[~2012-07-04 13:08 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-05-22 8:44 Proposal: immediate strings Dmitry Antipov
2012-05-22 20:51 ` Miles Bader
2012-05-22 22:13 ` Paul Eggert
2012-05-24 5:17 ` Stefan Monnier
2012-05-24 5:41 ` Ken Raeburn
2012-05-24 5:50 ` Miles Bader
2012-05-24 6:08 ` Paul Eggert
2012-05-24 7:14 ` Stefan Monnier
2012-05-24 7:52 ` Paul Eggert
2012-05-24 12:51 ` Stefan Monnier
2012-05-24 16:35 ` Paul Eggert
2012-05-25 6:43 ` Dmitry Antipov
2012-05-25 7:30 ` Paul Eggert
2012-05-28 11:32 ` Dmitry Antipov
2012-05-28 14:25 ` Stefan Monnier
2012-05-29 6:55 ` Dmitry Antipov
2012-05-29 7:38 ` Paul Eggert
2012-05-29 13:33 ` Dmitry Antipov
2012-05-29 15:24 ` Paul Eggert
2012-05-31 9:28 ` Dmitry Antipov
2012-05-31 16:34 ` Paul Eggert
2012-06-06 6:14 ` Dmitry Antipov
2012-06-06 6:41 ` Paul Eggert
2012-06-06 7:29 ` Dmitry Antipov
2012-06-06 15:14 ` Eli Zaretskii
2012-06-06 21:44 ` Paul Eggert
2012-07-04 8:27 ` Old topic(s) again [was: Re: Proposal: immediate strings] Dmitry Antipov
2012-07-04 13:08 ` Stefan Monnier [this message]
2012-07-04 19:32 ` Paul Eggert
2012-05-29 7:38 ` Proposal: immediate strings Andreas Schwab
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=jwv3957ofn5.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=dmantipov@yandex.ru \
--cc=emacs-devel@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).