GNU bug report logs - #5114
23.1.50; (string-to-number (number-to-string most-positive-fixnum))

Previous Next

Full log

Message #30 received at 5114 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Helmut Eller <eller.helmut <at> gmail.com>, 5114 <at> debbugs.gnu.org
Subject: Re: bug#5114: 23.1.50;	(string-to-number (number-to-string most-positive-fixnum))
Date: Sat, 05 Dec 2009 18:44:42 +0200

> From: Helmut Eller <eller.helmut <at> gmail.com>
> Date: Sat, 05 Dec 2009 16:18:13 +0100
> Cc: 
> 
> * Eli Zaretskii [2009-12-05 15:25+0100] writes:
> 
> >> From: Helmut Eller <eller.helmut <at> gmail.com>
> >> Date: Sat, 05 Dec 2009 13:36:41 +0100
> >> Cc: 5114 <at> emacsbugs.donarmstrong.com
> >> 
> >> +  else {
> >> +    unsigned long u = 0;
> >
> > This assumes that `unsigned long' is the same width as EMACS_INT.
> > This could be false, e.g., with 64-bit MS-Windows.  Isn't it better to
> > use EMACS_INT instead?
> 
> Using EMACS_UINT wouldn't hurt.  Does MOST_POSITIVE_FIXNUM not fit in a
> unsigned long on Windows?

In the 32-bit Windows build, it does.  In the 64-bit Windows build
(which does not yet exist, since we don't yet support it), it will
not, because MS in their infinite wisdom (probably because backward
compatibility considerations wrt existing source code and headers)
decided to use the LLP64 programming model.

> I assumed that longs are supposed to be as wide as pointers.

Not on 64-bit Windows, they don't.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.