[quake3] first win64 patch

[James Lacey]

-----Original Message-----
From: Ludwig Nussel [mailto:ludwig.nussel at suse.de] 
Sent: Monday, February 13, 2006 12:32 PM
To: quake3 at icculus.org
Subject: Re: [quake3] first win64 patch

James Lacey wrote:
> -----Original Message-----
> From: Ludwig Nussel [mailto:ludwig.nussel at suse.de] 
> Sent: Monday, February 13, 2006 10:23 AM
> To: quake3 at icculus.org
> Subject: Re: [quake3] first win64 patch
> 
> On Monday 13 February 2006 05:19, James Lacey wrote:
> > Here is my first Win64 Quake 3 patch. A couple of notes:
> 
> - Are all those int -> size_t (ie signed 32bit -> unsigned 64bit)
>   changes actually needed? Did you verify they don't break stuff by
>   looking at the code or by running the game? E.g. the loop in
>   SV_Status_f, l could become negative (yeah the code is broken
>   anyways)?
> 
> I did verify that the int -> size_t changes don't break anything as far as
I
> have played a couple of maps and everything seems to work fine. There was
> one bug I can think of that was caused this way because of a for loop
> "counting backwards" i.e. for(int i = SOME_NUMBER; i >= 0; i--). A lot of
> the int to size_t changes were for file system and memory functions. Not
> that realistically Quake 3 needs to address more than 4 GB of memory but I
> made the changes so that it was clean 64-bit code. Besides, isn't it good
> practice to use size_t for things like length and size?

> Yes it is but personally I'm not very keen to debug the non obvious
> problems it causes when blindly changing the existing (and working!)
> code. There is btw also no need to use a 64bit type if a 32bit one
> suffices. On x86_64 the code size to process 64bit integers is
> larger than for 32bit integers.

Perhaps this is just a matter of personal taste. I don't really think it
makes debugging that much harder because if all you did was change int to
size_t and something stops working, after you identify where the failure is,
all you have to do is change it back. The reason I made the changes was
because keeping things as int instead of size_t opened the door for possible
(but not probable) data truncation.

I don't know enough to dispute you, but why would the code size to process
64 bit integers be larger than 32 bit integers on a 64 bit CPU? 8 bytes
would be the machine word. Nevertheless, since I don't really know, I will
take your word for it.

James