From mboxrd@z Thu Jan  1 00:00:00 1970
Path: main.gmane.org!not-for-mail
From: Horsley Tom <Tom.Horsley@ccur.com>
Newsgroups: gmane.emacs.bugs
Subject: RE: unexelf.c maybe broke between 21.1 and 21.2
Date: Thu, 29 Aug 2002 08:35:34 -0400
Sender: bug-gnu-emacs-admin@gnu.org
Message-ID: <F5573A841216B94CB3CD1A7A0A1FD35612E51D@exchange.ccur.com>
NNTP-Posting-Host: localhost.gmane.org
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
X-Trace: main.gmane.org 1030624523 5455 127.0.0.1 (29 Aug 2002 12:35:23 GMT)
X-Complaints-To: usenet@main.gmane.org
NNTP-Posting-Date: Thu, 29 Aug 2002 12:35:23 +0000 (UTC)
Cc: "'bug-gnu-emacs@gnu.org'" <bug-gnu-emacs@gnu.org>
Return-path: <bug-gnu-emacs-admin@gnu.org>
Original-Received: from monty-python.gnu.org ([199.232.76.173])
	by main.gmane.org with esmtp (Exim 3.35 #1 (Debian))
	id 17kOW5-0001PQ-00
	for <gnu-bug-gnu-emacs@m.gmane.org>; Thu, 29 Aug 2002 14:35:17 +0200
Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org)
	by monty-python.gnu.org with esmtp (Exim 4.10)
	id 17kOXU-000095-00; Thu, 29 Aug 2002 08:36:44 -0400
Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10)
	id 17kOWX-00007a-00
	for bug-gnu-emacs@gnu.org; Thu, 29 Aug 2002 08:35:45 -0400
Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10)
	id 17kOWU-00007D-00
	for bug-gnu-emacs@gnu.org; Thu, 29 Aug 2002 08:35:44 -0400
Original-Received: from mail.ccur.com ([208.248.32.212] helo=exchange.ccur.com)
	by monty-python.gnu.org with esmtp (Exim 4.10)
	id 17kOWT-000073-00
	for bug-gnu-emacs@gnu.org; Thu, 29 Aug 2002 08:35:41 -0400
Original-Received: by exchange.ccur.com with Internet Mail Service (5.5.2653.19)
	id <R4GP0WNW>; Thu, 29 Aug 2002 08:35:40 -0400
Original-To: Horsley Tom <Tom.Horsley@ccur.com>, 'Eli Zaretskii'
	 <eliz@is.elta.co.il>
X-Mailer: Internet Mail Service (5.5.2653.19)
Errors-To: bug-gnu-emacs-admin@gnu.org
X-BeenThere: bug-gnu-emacs@gnu.org
X-Mailman-Version: 2.0.11
Precedence: bulk
List-Help: <mailto:bug-gnu-emacs-request@gnu.org?subject=help>
List-Post: <mailto:bug-gnu-emacs@gnu.org>
List-Subscribe: <http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs>,
	<mailto:bug-gnu-emacs-request@gnu.org?subject=subscribe>
List-Id: Bug reports for GNU Emacs,
	the Swiss army knife of text editors <bug-gnu-emacs.gnu.org>
List-Unsubscribe: <http://mail.gnu.org/mailman/listinfo/bug-gnu-emacs>,
	<mailto:bug-gnu-emacs-request@gnu.org?subject=unsubscribe>
List-Archive: <http://mail.gnu.org/pipermail/bug-gnu-emacs/>
Xref: main.gmane.org gmane.emacs.bugs:3355
X-Report-Spam: http://spam.gmane.org/gmane.emacs.bugs:3355

> Huh? The old section
> either started after the new section or it didn't.
> What on earth does rounding the offset up accomplish
> other than failing to move a section that should
> have been moved?

OK, I realize that question doesn't make sense either :-).
If I round up the address you'd think it would be more
likely to show up as following the new data section,
not less likely. Perhaps what really happened was
the new data section was rounded up more than the
if statement was rounding up the address of the old
section, so in this particular combination it didn't
look like it needed to be moved.

I still think the logic I replace the whole test with
make more sense :-).