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: USE_LSB_TAG not supported on this platform Date: Tue, 09 Feb 2016 20:02:47 +0200 Message-ID: <83r3glbw3c.fsf@gnu.org> 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> <56BA23CB.4070001@cs.ucla.edu> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1455041016 23514 80.91.229.3 (9 Feb 2016 18:03:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 9 Feb 2016 18:03:36 +0000 (UTC) Cc: m43cap@yandex.com, herbert@mailbox.org, emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 09 19:03:28 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 1aTCdL-0007P1-Go for ged-emacs-devel@m.gmane.org; Tue, 09 Feb 2016 19:03:27 +0100 Original-Received: from localhost ([::1]:59094 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aTCdH-00083t-E4 for ged-emacs-devel@m.gmane.org; Tue, 09 Feb 2016 13:03:23 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40055) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aTCd3-00082N-KQ for emacs-devel@gnu.org; Tue, 09 Feb 2016 13:03:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aTCd2-0005zp-Mb for emacs-devel@gnu.org; Tue, 09 Feb 2016 13:03:09 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:45419) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aTCcw-0005z3-QP; Tue, 09 Feb 2016 13:03:02 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1323 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aTCcv-00040C-0D; Tue, 09 Feb 2016 13:03:02 -0500 In-reply-to: <56BA23CB.4070001@cs.ucla.edu> (message from Paul Eggert on Tue, 9 Feb 2016 09:37:15 -0800) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:199624 Archived-At: > Cc: herbert@mailbox.org, emacs-devel@gnu.org, m43cap@yandex.com > From: Paul Eggert > Date: Tue, 9 Feb 2016 09:37:15 -0800 > > 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. :-) There's only one 16-bit platform supported by Emacs: MS-DOS. And there the problem doesn't exist, because the library switches the CPU to 32-bit mode. > > 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. Maybe these considerations are worth having as comments near the loop, so that whoever bumps into the problem will know faster and better what to do. Thanks.