Re: [Condor-devel] Reserved swap space issue

["Matt Hope" <matthew.hope@xxxxxxxxx>]

On 2/21/06, Peter Keller <psilord@xxxxxxxxxxx> wrote:
> On Tue, Feb 21, 2006 at 10:47:00AM +0000, Matt Hope wrote:
> > As a suggestion for the condor dev team - is it worth replacing any
> > and all uses of int/unsigned int with long wherever it is used to
> > refer to a size in bytes...
> >
> > It strikes me that any change from signed to unsigned is only delaying
> > the inevitable by months given the adoption of 64bit OS's.
>
> Usually this type of problem only shows up when a previously 32 bit port
> goes to 64 bits, and the code in question only had compiled for the
> specific 32 bit port. Our codebase, in general, supports 64 bit OSes,
> and the circumstances under which this shows up are actually quite small.
>
> There are only a few places where a file size in bytes comes up in the
> codebase, the file transfer code (which already does the right thing),
> log size/rotation calculations, and condor_sysapi. The standard universe
> deals with it as well, but that is much harder to get right.

I figured a great deal of it had already been sorted out in 6.7
series. One issue is not the movement from a 32bit to 64bit
application but the movement of a 32bit app to a 64bit OS (which on
windows is very easy to do, thus it is going to happen a lot) where an
app which did not expect to ever see memory sizes beyond 4Gb may well
encounter them in response to system queries about available resources
(even though the OS happily handles 32bit pointers for it).

> So, I'd say that a large code cleaning would not only take a while (you
> have to find all of the places that deal with that type of information
> and they might not be obvious) but will probably introduce interesting
> bugs if not tested properly.

I just figured such a cleaning would be safer than waiting for nasty
"oops it went negative" bugs which might be hard to debug. I certainly
take your point about interesting bugs, I still maintain that anything
being changed from signed to unsigned is a candidate for just being
made a long (signed or otherwise) without seriously good reasons for
staying 32bits (network transferred structs for example)

> So, in short, if you're willing to provide patches for this type of thing,
> then make sure they are small so we can see the extant of them.

fair enough - I'll take a look at it next time I get the chance :¬)

Matt