From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Old topic(s) again [was: Re: Proposal: immediate strings] Date: Wed, 04 Jul 2012 09:08:30 -0400 Message-ID: References: <4FBB51E7.6080601@yandex.ru> <4FC472E6.5020005@yandex.ru> <4FC47CE1.6050901@cs.ucla.edu> <4FC4D025.9020608@yandex.ru> <4FC4EA10.702@cs.ucla.edu> <4FC739B4.30408@yandex.ru> <4FC79DAD.5040904@cs.ucla.edu> <4FCEF52E.9090801@yandex.ru> <4FCEFB8F.8080106@cs.ucla.edu> <4FCF06EB.8030109@yandex.ru> <83ipf4wk00.fsf@gnu.org> <4FF3FE6E.8080202@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1341407329 25745 80.91.229.3 (4 Jul 2012 13:08:49 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 4 Jul 2012 13:08:49 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Antipov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 04 15:08:47 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1SmPK2-00007a-4g for ged-emacs-devel@m.gmane.org; Wed, 04 Jul 2012 15:08:46 +0200 Original-Received: from localhost ([::1]:60994 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SmPK0-0007sq-VG for ged-emacs-devel@m.gmane.org; Wed, 04 Jul 2012 09:08:44 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:43922) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SmPJu-0007sh-I5 for emacs-devel@gnu.org; Wed, 04 Jul 2012 09:08:42 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SmPJp-0001iR-Gs for emacs-devel@gnu.org; Wed, 04 Jul 2012 09:08:38 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.182]:13455) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SmPJp-0001iK-CE for emacs-devel@gnu.org; Wed, 04 Jul 2012 09:08:33 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAG6Zu09MCquH/2dsb2JhbABEtBGBCIIVAQEEAScvIwULCw4mEhQYDSSIHAW6CZBEA6MzgViDBQ X-IronPort-AV: E=Sophos;i="4.75,637,1330923600"; d="scan'208";a="192643098" Original-Received: from 76-10-171-135.dsl.teksavvy.com (HELO pastel.home) ([76.10.171.135]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 04 Jul 2012 09:08:30 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id 5946B58FD2; Wed, 4 Jul 2012 09:08:30 -0400 (EDT) In-Reply-To: <4FF3FE6E.8080202@yandex.ru> (Dmitry Antipov's message of "Wed, 04 Jul 2012 12:27:26 +0400") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.1.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.182 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:151414 Archived-At: > 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