From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Fabrice Popineau Newsgroups: gmane.emacs.devel Subject: Re: Windows 64 port Date: Thu, 22 Mar 2012 18:39:30 +0100 Message-ID: References: <20120219211800.0000558f@unknown> <834numv7js.fsf@gnu.org> <4F428780.8070902@cs.ucla.edu> <4F4D507F.7030008@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=bcaec52d58f722ddf404bbd865ff X-Trace: dough.gmane.org 1332438028 10404 80.91.229.3 (22 Mar 2012 17:40:28 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Thu, 22 Mar 2012 17:40:28 +0000 (UTC) Cc: Eli Zaretskii , AJMR , emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 22 18:40:26 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 1SAlzl-0003qJ-0m for ged-emacs-devel@m.gmane.org; Thu, 22 Mar 2012 18:40:17 +0100 Original-Received: from localhost ([::1]:41747 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SAlzk-0001xP-Ai for ged-emacs-devel@m.gmane.org; Thu, 22 Mar 2012 13:40:16 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:56529) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SAlzd-0001tS-HH for emacs-devel@gnu.org; Thu, 22 Mar 2012 13:40:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SAlzV-00019G-Pl for emacs-devel@gnu.org; Thu, 22 Mar 2012 13:40:09 -0400 Original-Received: from mail-bk0-f41.google.com ([209.85.214.41]:44843) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SAlzN-00017J-T9; Thu, 22 Mar 2012 13:39:54 -0400 Original-Received: by bkwq16 with SMTP id q16so2421466bkw.0 for ; Thu, 22 Mar 2012 10:39:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=B3LtpKYhzWLTmzO6P2nuXrIoXexjbHdLi7rYuT1FiRc=; b=zxhSNYP+igD7cGwd66mAKpGEsv5u5FrTNkWgoyeS8OAxS2R4GJJnvpyNytWV+F2x6u ZJ3jnq/wwKI517NjvtT9Lrs1XVw9T6QBzrPEVT6SBaHjbMur+PZwSf6ZPJBRDbCtIjQu WkiMfyDqdvowVfd/W1lcHZ1RFMK9FCeyGhnPrJQFDSjQ3/omlyA+rUNiisPf1dVzuRuN q3eBPSquHGLMsGVYugK7FGvzyYCm5WSO0jPoEd8RmvnvMI7n0mp743U4GqEvyO1KWaZy XfSg6qbjwGMwkOxL4EAUYUmp+ANurXC18yxq34MjIBmrS8/W6Zot3D2CgpehmcAS4eQJ Fbzg== Original-Received: by 10.204.173.11 with SMTP id n11mr3419806bkz.120.1332437990956; Thu, 22 Mar 2012 10:39:50 -0700 (PDT) Original-Received: by 10.204.179.143 with HTTP; Thu, 22 Mar 2012 10:39:30 -0700 (PDT) In-Reply-To: <4F4D507F.7030008@cs.ucla.edu> X-Google-Sender-Auth: VkfIIF8L5Cnndy_6oAA1WA-CjLM X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.214.41 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:149176 Archived-At: --bcaec52d58f722ddf404bbd865ff Content-Type: text/plain; charset=ISO-8859-1 2012/2/28 Paul Eggert > > There is something wrong around lib/strftime.c:946 > > if (negative_number) > > u_number_value = - u_number_value; > > > > u_number_value being unsigned, this is wrong. > > I don't see anything wrong there. The value of > -X is well-defined if X is unsigned int; it's > equivalent to ~X + 1. Can you supply a test case > illustrating the actual bug? > > Please bear in mind that the code is already > tested to LP64 hosts. Any bug related to this > particular code would also be a bug on LP64 hosts, > no? So, it's not likely that any bug here is specific > to Windows 64. If there is a bug, it should be > describable and fixable independently of Windows 64. I don't see things that way. Some things that would pass on LP64 because ints are 64 bits may turn into a crash because of sign extension on Windows 64 promoting 32bits ints to 64bits ints. So I'm definitely more confident when ints are used without any abuse of any kind. I don't see the point with using an unsigned int to negate it. -- Fabrice --bcaec52d58f722ddf404bbd865ff Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

2012/2/28 Paul Eggert = <eggert@cs.ucla.edu>=
> There is something wrong around lib/strftime.c:946 > =A0 =A0 =A0 =A0 =A0 if (negative_number)
> =A0 =A0 =A0 =A0 =A0 =A0 u_number_value =3D - u_number_value;
>
> u_number_value being unsigned, this is wrong.

I don't see anything wrong there. =A0The value of
-X is well-defined if X is unsigned int; it's
equivalent to ~X + 1. =A0Can you supply a test case
illustrating the actual bug?

Please bear in mind that the code is already
tested to LP64 hosts. =A0Any bug related to this
particular code would also be a bug on LP64 hosts,
no? =A0So, it's not likely that any bug here is specific
to Windows 64. =A0If there is a bug, it should be
describable and fixable independently of Windows 64.

I don't see things that way. Some things that would pass on = LP64 because
ints are 64 bits may turn into a crash because of sign ext= ension on Windows 64
promoting 32bits ints to 64bits ints. So I'm definitely more confi= dent when ints are used=A0
without any abuse of any kind. I don&#= 39;t see the point with using an unsigned int to negate
it.

--
Fabrice

--bcaec52d58f722ddf404bbd865ff--