From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Paul Eggert Newsgroups: gmane.emacs.devel Subject: Re: Old topic(s) again [was: Re: Proposal: immediate strings] Date: Wed, 04 Jul 2012 12:32:34 -0700 Organization: UCLA Computer Science Department Message-ID: <4FF49A52.3060102@cs.ucla.edu> 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; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1341430366 13468 80.91.229.3 (4 Jul 2012 19:32:46 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 4 Jul 2012 19:32:46 +0000 (UTC) Cc: Dmitry Antipov , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 04 21:32:46 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 1SmVJb-0002f9-AM for ged-emacs-devel@m.gmane.org; Wed, 04 Jul 2012 21:32:43 +0200 Original-Received: from localhost ([::1]:59514 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SmVJa-0000jb-Av for ged-emacs-devel@m.gmane.org; Wed, 04 Jul 2012 15:32:42 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:58796) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SmVJW-0000j1-Jg for emacs-devel@gnu.org; Wed, 04 Jul 2012 15:32:39 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SmVJU-0003jY-Sr for emacs-devel@gnu.org; Wed, 04 Jul 2012 15:32:38 -0400 Original-Received: from smtp.cs.ucla.edu ([131.179.128.62]:54505) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SmVJU-0003jU-KR for emacs-devel@gnu.org; Wed, 04 Jul 2012 15:32:36 -0400 Original-Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 9A25639E8008; Wed, 4 Jul 2012 12:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Original-Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ol70H4EnrZg2; Wed, 4 Jul 2012 12:32:33 -0700 (PDT) Original-Received: from [192.168.1.4] (pool-108-23-119-2.lsanca.fios.verizon.net [108.23.119.2]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 2FB46A60002; Wed, 4 Jul 2012 12:32:33 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20120615 Thunderbird/13.0.1 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 131.179.128.62 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:151425 Archived-At: On 07/04/2012 06:08 AM, Stefan Monnier wrote: >> +dnl Determine the basic type of ptrdiff_t. >> +AC_CHECK_SIZEOF([int]) >> +... > > I really would much rather avoid such things. Why do we need it? We shouldn't need it. Instead of sizeof (TYPE_PTRDIFF_T), the code can use sizeof (ptrdiff_t). And instead of a member declaration: unsigned TYPE_PTRDIFF_T size : BITS_PER_PTRDIFF_T - 1; the code should be able to use size_t: size_t size : BITS_PER_PTRDIFF_T - 1; The C standard doesn't guarantee this to work, but compilers generally support it and if we run into any exceptions we can deal with them the same way that ENUM_BF deals with enum bitfields. > 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. There's no guarantee. The only guarantees are that members are laid out in increasing address order, that they're aligned, and that the first member is at offset zero. There's no guarantee about where later members are placed: there can be padding pretty much anywhere after the first member. We can easily verify at compile-time that the two layouts have the same overall size and alignment; that should catch many potential errors in this area, though not all. I did not review the meat of the patch carefully, but I noticed some minor Emacs style indenting issues, e.g.: nbytes = s->u.imm.size_byte == STRING_UNIBYTE_IMM_MARK ? s->u.imm.size : s->u.imm.size_byte; should be: nbytes = (s->u.imm.size_byte == STRING_UNIBYTE_IMM_MARK ? s->u.imm.size : s->u.imm.size_byte);