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: Tue, 28 Feb 2012 23:39:46 +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=0015175cd826a44b2b04ba0de833 X-Trace: dough.gmane.org 1330478041 5364 80.91.229.3 (29 Feb 2012 01:14:01 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 29 Feb 2012 01:14:01 +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 Wed Feb 29 02:14:00 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 1S2Y7D-0004ae-Mm for ged-emacs-devel@m.gmane.org; Wed, 29 Feb 2012 02:13:59 +0100 Original-Received: from localhost ([::1]:43132 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S2Y7C-0000z2-Td for ged-emacs-devel@m.gmane.org; Tue, 28 Feb 2012 20:13:58 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:53107) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S2ViR-0000xZ-Su for emacs-devel@gnu.org; Tue, 28 Feb 2012 17:40:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S2ViQ-0006cx-1e for emacs-devel@gnu.org; Tue, 28 Feb 2012 17:40:15 -0500 Original-Received: from mail-bk0-f41.google.com ([209.85.214.41]:38811) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S2ViM-0006bn-9S; Tue, 28 Feb 2012 17:40:10 -0500 Original-Received: by bkty12 with SMTP id y12so6514184bkt.0 for ; Tue, 28 Feb 2012 14:40:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=AS+StCEGbvJsPDR7qKUooNBBQRo1CVVgjtkDNmPBAU4=; b=aOjPIcZjZEP6OWUHX5rm1jbkFn8NAd2i57kOu+iV+kvkGr9rrZC3XQ6ayikTG4yxvL zVPsstPy7XXqz8oXqbCkKULmGfT4BNg+XPOcLh3l7JEbkcl/4btC7SQdl5zQq7XhnoNY 3jO5IAL6TUhLJ/Q2CBnJHdqvH9hI/TD7NJ36I= Original-Received: by 10.204.145.145 with SMTP id d17mr8786596bkv.77.1330468807264; Tue, 28 Feb 2012 14:40:07 -0800 (PST) Original-Received: by 10.204.60.3 with HTTP; Tue, 28 Feb 2012 14:39:46 -0800 (PST) In-Reply-To: <4F4D507F.7030008@cs.ucla.edu> X-Google-Sender-Auth: OAXnydAiFlIcRTzObsURaWTb_S0 X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 209.85.214.41 X-Mailman-Approved-At: Tue, 28 Feb 2012 20:13:43 -0500 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:148834 Archived-At: --0015175cd826a44b2b04ba0de833 Content-Type: text/plain; charset=ISO-8859-1 > > > > 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? > > When my compiler issues a warning like : unsigned.c unsigned.c(3) : warning C4146: unary minus operator applied to unsigned type, result still unsigned I tend to care about it. If it is on purpose, then I'm ok with it albeit I would have prefered something less error prone (I mean human interpretation error :-) ) > > In src/dispnew.c:6402, height and width should probably be unsigned. The > > checking by > > INT_ADD_RANGE_OVERFLOW results in a compiler warning about integral > > constant overflow > > because it tries to compute (INTMIN - 2) which obviously is out of range. > > The value is not used in this case, but the compiler may emit the warning > > anyway. > > We don't need to modify the mainline Emacs code in order to > pacify third-party compilers that issue incorrect warnings. > We can safely ignore these warnings and leave the code alone. > My past experience with stuff like pdftex (many years !) is that compiling with a completely different compiler may reveal useful to find errors in already tested source code. The cleaner, the safer. I don't know to which extent the FSF wants to support compilation of emacs x64 (but that applies to x86 too) with the MS tools (even if they are freely available). I did it because I'm using it this way, but that should be doable with MINGW x64 (or so I guess). With the MS tools, emacs does not compile out of the box. There are errors. There are also lots of warnings and when something does not work, I try to remove warnings first. All in all, at least for the record, it may help people who would need an emacs/x64/windows this way. Best regards, Fabrice --0015175cd826a44b2b04ba0de833 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

> 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?


When my compiler issues a warning like= :

unsigned.c
unsigned.c(3) : warning C4= 146: unary minus operator applied to unsigned type, result still unsigned

I tend to care about it. If it is on purpose, then I= 9;m ok with it albeit I would have prefered something less error prone
(I mean human interpretation error :-) )
=A0
> In src/dispnew.c:6402, height and width should probably be unsigned. T= he
> checking by
> INT_ADD_RANGE_OVERFLOW results in a compiler warning about integral > constant overflow
> because it tries to compute (INTMIN - 2) which obviously is out of ran= ge.
> The value is not used in this case, but the compiler may emit the warn= ing
> anyway.

We don't need to modify the mainline Emacs code in order to
pacify third-party compilers that issue incorrect warnings.
We can safely ignore these warnings and leave the code alone.

My past experience with stuff like pdftex (many year= s !)
is that compiling with a completely different=A0
compiler may = reveal useful to find errors in already tested source code.
The c= leaner, the safer.

I don't know to which extent the FSF wants to suppo= rt compilation of emacs
x64 (but that applies to x86 too) with th= e MS tools (even if they are freely available).
I did it because = I'm using it this way, but that should be doable with MINGW x64 (or so = I guess).
With the MS tools, emacs does not compile out of the box.=A0There are = errors.=A0
There are also lots of warnings=A0and when something d= oes not work, I try to remove warnings first.=A0
All in all, =A0a= t least for the record, it may help=A0people who would need an emacs/x64/wi= ndows this way.

Best regards,

Fabrice


--0015175cd826a44b2b04ba0de833--