From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Proposal: block-based vector allocator Date: Sat, 02 Jun 2012 10:41:25 +0300 Message-ID: <83ipfacg9m.fsf@gnu.org> References: <4EDDA68B.5050601@yandex.ru> <4FB4AFA4.7020601@yandex.ru> <4FBA32D9.5090704@yandex.ru> <4FC775B5.30904@yandex.ru> <4FC79188.4070200@cs.ucla.edu> <4FC8500F.6000109@yandex.ru> <4FC856A5.9000306@cs.ucla.edu> <4FC88610.6000005@yandex.ru> <4FC95F36.5060403@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: dough.gmane.org 1338622902 31017 80.91.229.3 (2 Jun 2012 07:41:42 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 2 Jun 2012 07:41:42 +0000 (UTC) Cc: dmantipov@yandex.ru, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Jun 02 09:41:38 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 1Saixm-0001pH-7Y for ged-emacs-devel@m.gmane.org; Sat, 02 Jun 2012 09:41:30 +0200 Original-Received: from localhost ([::1]:52108 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Saixm-0006x3-0u for ged-emacs-devel@m.gmane.org; Sat, 02 Jun 2012 03:41:30 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:49123) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Saixi-0006wO-Bu for emacs-devel@gnu.org; Sat, 02 Jun 2012 03:41:28 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Saixg-0000XQ-CP for emacs-devel@gnu.org; Sat, 02 Jun 2012 03:41:25 -0400 Original-Received: from mtaout22.012.net.il ([80.179.55.172]:57909) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Saixg-0000Wa-4u for emacs-devel@gnu.org; Sat, 02 Jun 2012 03:41:24 -0400 Original-Received: from conversion-daemon.a-mtaout22.012.net.il by a-mtaout22.012.net.il (HyperSendmail v2007.08) id <0M4Z00900BXDR400@a-mtaout22.012.net.il> for emacs-devel@gnu.org; Sat, 02 Jun 2012 10:41:22 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.210.75]) by a-mtaout22.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0M4Z009M3C0XK030@a-mtaout22.012.net.il>; Sat, 02 Jun 2012 10:41:22 +0300 (IDT) In-reply-to: <4FC95F36.5060403@cs.ucla.edu> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.172 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:150723 Archived-At: > Date: Fri, 01 Jun 2012 17:32:54 -0700 > From: Paul Eggert > CC: Dmitry Antipov , emacs-devel@gnu.org, > Eli Zaretskii > > This whole area is in a bit of a mess. It's not just > that comment. While looking into this and cleaning it up > I also found the following: > > * The union data structure depends on WORDS_BIGENDIAN > for no particularly good reason nowadays, and this just > confuses things. > > * The w32heap code is confused about this, and thinks that > USE_LISP_UNION_TYPE invalidates USE_LSB_TAG, which maybe > used to be true but is no longer true. > > * There's no way for the builder to force a build > without USE_LSB_TAG (Dmitry's point). > > * There are a few annoying warnings if you compile unions > with gcc -Wall. > > You can find the patch for all this at > . I'll CC: Eli > since this affects w32 code. Unfortunately, that patch does nothing IMO to reduce "the mess". To reduce the mess, we should add commentary that would replace wading through twisty macros all alike with reading clear descriptions in plain English. By contrast, the patch doesn't add any documentation, it actually _removes_ some of the comments. In this situation, saying that w32heap.c is "confused" is really being facetious, to say the least.