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: Mon, 20 Feb 2012 20:20:52 +0100 Message-ID: References: <20120219211800.0000558f@unknown> <834numv7js.fsf@gnu.org> <4F428780.8070902@cs.ucla.edu> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=00151747bbcc8eb61304b96a3292 X-Trace: dough.gmane.org 1329795913 10549 80.91.229.3 (21 Feb 2012 03:45:13 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 21 Feb 2012 03:45:13 +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 Tue Feb 21 04:45:11 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Rzgf4-00049H-Ix for ged-emacs-devel@m.gmane.org; Tue, 21 Feb 2012 04:45:06 +0100 Original-Received: from localhost ([::1]:50569 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rzgf3-0003TG-Cx for ged-emacs-devel@m.gmane.org; Mon, 20 Feb 2012 22:45:05 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:60093) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RzYnV-0006b9-7M for emacs-devel@gnu.org; Mon, 20 Feb 2012 14:21:18 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RzYnU-0006Zm-73 for emacs-devel@gnu.org; Mon, 20 Feb 2012 14:21:17 -0500 Original-Received: from mail-bk0-f41.google.com ([209.85.214.41]:39266) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RzYnR-0006ZB-VH; Mon, 20 Feb 2012 14:21:14 -0500 Original-Received: by bkty12 with SMTP id y12so5860305bkt.0 for ; Mon, 20 Feb 2012 11:21:12 -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=pokwVzgo7XVdyxLMGsC+bH1E9WyCCu8pLFDvH1OoVng=; b=IHXoRaemDy1eoVfajI8WS9dT1AwDaJf6HnlV3w0YrhjJ0lh/avkaVLp9KRH9oGNeKJ 2cTJoz6Pgz7SydjBJNNifJu8wcGtj7is1ND8BpILu6Zr8/7/IJmgC4R9EhTMe9hA7AVR n/UT+EOOYzsrZtC8WlZiQFjCUB1Myv7ABmjMk= Original-Received: by 10.204.129.7 with SMTP id m7mr9305345bks.13.1329765672727; Mon, 20 Feb 2012 11:21:12 -0800 (PST) Original-Received: by 10.204.231.142 with HTTP; Mon, 20 Feb 2012 11:20:52 -0800 (PST) In-Reply-To: <4F428780.8070902@cs.ucla.edu> X-Google-Sender-Auth: je3fRrIs500LP6Zvy57sXH0sFQI 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: Mon, 20 Feb 2012 22:45:02 -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:148689 Archived-At: --00151747bbcc8eb61304b96a3292 Content-Type: text/plain; charset=ISO-8859-1 > > with 'size_t' or 'uintptr_t' as appropriate, but other > type replacements are dubious and should generally be omitted. > I don't think so. Windows and Linux does not follow the same 64 bits rules (LLP64 vs LP64). > For example: > > - int i = 0, aligned = (intptr_t) ABLOCKS_BUSY (abase); > + int i = 0; > + intptr_t aligned = (intptr_t) ABLOCKS_BUSY (abase); > Here, the value of 'aligned' is either 0 or 1, so there's > no need to change its type. > It is kinf of strange to cast to intptr_t to store the result in a variable of different type ? > The changes to src/m/amdx86-64.h would break GNU/Linux and > need to be backed out and redone. > This mishandles Emacs integers outside the signed 32-bit range: > > -#define XFASTINT(a) ((a) + 0) > +#define XFASTINT(a) ((int)((a) + 0)) > I'll look into these ones. -- Fabrice --00151747bbcc8eb61304b96a3292 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
with 'size_t&= #39; or 'uintptr_t' as appropriate, but other
type replacements are dubious and should generally be omitted.

I don't think so. Windows and Lin= ux does not follow the same 64 bits rules (LLP64 vs LP64).
=A0
For example:

- =A0 =A0 =A0int i =3D 0, aligned =3D (intptr_t) ABLOCKS_BUSY (abase);
+ =A0 =A0 =A0int i =3D 0;
+ =A0 =A0 =A0intptr_t aligned =3D (intptr_t) ABLOCKS_BUSY (abase);
=A0
Here, the value of 'aligned' is either 0 or 1, so there's
no need to change its type.

It is kinf = of strange to cast to intptr_t to store the result in a variable of differe= nt type ?
=A0
=A0
The changes to src/m/amdx86-64.h would break GNU/Linux and
need to be backed out and redone.
=A0
This mishandles Emacs integers outside the signed 32-bit range:

-#define XFASTINT(a) ((a) + 0)
+#define XFASTINT(a) ((int)((a) + 0))

I'll look into these ones.

--
Fabrice
--00151747bbcc8eb61304b96a3292--