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: USE_LSB_TAG not supported on this platform Date: Tue, 9 Feb 2016 09:37:15 -0800 Organization: UCLA Computer Science Department Message-ID: <56BA23CB.4070001@cs.ucla.edu> References: <86powcjei0.wl-herbert@mailbox.org> <56B3F962.8010203@cs.ucla.edu> <86mvrejegc.wl-herbert@mailbox.org> <86si15ygd9.wl-herbert@mailbox.org> <85twlksgds.fsf@iznogoud.viz> <8660y0nqze.wl-herbert@mailbox.org> <56B8F03C.3010709@cs.ucla.edu> <83lh6vot83.fsf@gnu.org> <56B9A5B1.5080101@cs.ucla.edu> <83bn7pddlu.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1455039460 26078 80.91.229.3 (9 Feb 2016 17:37:40 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 9 Feb 2016 17:37:40 +0000 (UTC) Cc: m43cap@yandex.com, herbert@mailbox.org, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 09 18:37:31 2016 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 1aTCEF-0006qB-BU for ged-emacs-devel@m.gmane.org; Tue, 09 Feb 2016 18:37:31 +0100 Original-Received: from localhost ([::1]:58745 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aTCEE-0000EK-Ij for ged-emacs-devel@m.gmane.org; Tue, 09 Feb 2016 12:37:30 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58920) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aTCEA-0000Bj-CH for emacs-devel@gnu.org; Tue, 09 Feb 2016 12:37:27 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aTCE9-00072w-It for emacs-devel@gnu.org; Tue, 09 Feb 2016 12:37:26 -0500 Original-Received: from zimbra.cs.ucla.edu ([131.179.128.68]:37791) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aTCE2-00070o-B9; Tue, 09 Feb 2016 12:37:18 -0500 Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 2644B1601BD; Tue, 9 Feb 2016 09:37:16 -0800 (PST) Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id qi9rEb_Hsn0H; Tue, 9 Feb 2016 09:37:15 -0800 (PST) Original-Received: from localhost (localhost [127.0.0.1]) by zimbra.cs.ucla.edu (Postfix) with ESMTP id 6E17B160D25; Tue, 9 Feb 2016 09:37:15 -0800 (PST) X-Virus-Scanned: amavisd-new at zimbra.cs.ucla.edu Original-Received: from zimbra.cs.ucla.edu ([127.0.0.1]) by localhost (zimbra.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 6ahTSE3t8w4s; Tue, 9 Feb 2016 09:37:15 -0800 (PST) Original-Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200]) by zimbra.cs.ucla.edu (Postfix) with ESMTPSA id 5214D1601BD; Tue, 9 Feb 2016 09:37:15 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 In-Reply-To: <83bn7pddlu.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 131.179.128.68 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:199618 Archived-At: On 02/09/2016 08:59 AM, Eli Zaretskii wrote: > Thanks. Out of curiosity: which hosts can behave like that? 16-bit PDP-11s running 7th Edition Unix. malloc returned only a multiple of 2 there. :-) I think there were 32-bit platforms where malloc returned only a multiple of 4, but can't find any offhand now. For what it's worth, glibc documents a minimum of 8, for all glibc platforms. > Also, why are we sure that the loops will end at some point on those > hosts? Shouldn't we perhaps set a limit to the loop iterations, to be > sure we don't infloop there? We're not absolutely sure. Certainly the C standard doesn't guarantee it; malloc can return a pointer that is always odd, on weird platforms where alignof always returns 1. I view this as almost purely theoretical though, due to the practical performance benefit of alignment to at least sizeof(double). It's conceivable (though very unlikely) that Emacs will infloop on some truly oddball platform that does not care about performance; but if that happens it'll be OK, as the infloop would almost surely happen during a build and the builder would then send us a bug report and we can deal with it then. I think adding a counter would complicate the code (and possibly introduce bugs, in code that's never really exercised) for not enough benefit.