Re: opendap is far from being 64-bit clean

[Hans de Goede <j w r degoede hhs nl>]

Unfortunatly quite a bit of software out there has not been reviewed for 
64 bit cleanness. It seems a lot of software which gets shipped as 64 
bit clean merely has been compiled and tested, but could still have 
quite a few (untested) code paths which contain 64 bit unclean code.

Even if you get rid of all warnings there is no guarante it will really 
be 64 bit safe, for example:

func(unsigned char *data)
{
   int i, offset = SOME_DEFINE;
   now read a bunch of 32 bit vars from the buf at offset */
   long vars[16];
   long *p = (long *)(data + offset);
   for(i=0; i<16; i++, p++)
      vars[i] = *p;
}

Won't generate warnings, but is plain wrong the long vars causes 16 * 64 
bit to be claimed on the stack, which although wastefull can't harm, but 
the long *p causes the 32 bit data to be walked in 64 bit steps, and 
read as 64 bits vars instead of 32 bit. Bug!

So besides fixing all ptr cast to int of difference size warnings you 
also need to check all uses of long, most need to be changed to int. 
Except where:
-64 bit is really needed (this should already use long long, or it will
 fail on 32 bit archs)
-you're dealing with memory addresses/sizes
-for addresses mostly physical mem (think X-drivers), other (virtual
 addresses storing of addresses in long int's is wrong and should really
 be changed to ptr's if possible. Also note that this always violates
 ansi-C.

No after scaring you a bit about the amount of work back to your 
original problem. It could be that the opendap maintainer doesn't have 
access to a 64 bit machine or doesn't have the required skills.

So it might me best for you todo this your self, or you could drop 
opendap support. Dropping opendap support however is not a way I would 
like to promote I have a 64 bit machine myself for a few months now, and 
I've noticed that although people claim linux has a big 64 bit lead on 
that other OS, there still is a lot of work to be done.

So I would like to advise you to just bite the bullet and fix opendap, 
working with upstream and the opendap maintainer. If you can get 
upstream aware of the problem and you're fixes intergrated then this is 
a onetime effort. If you don't get this intergrated upstream you will 
have to redo your work every release!

I've taken my own medicine for a number of packages I'm maintaining / 
trying to get into FE and it can be some work, also working with 
upstream is not always easy. But it really is the only way to make all 
the great opensource software ready for the 64 bit future. Remember if 
something itches scratch it :)

Regards,

Hans






Ed Hill wrote:
> Hi Tom,
>
> In order to build nco for FC-4, I've first been trying to get opendap to
> build.  The result is failures on x86_64 such as:
>
>   http://buildsys.fedoraproject.org/logs//4/337-
> opendap-3.4.4-8.fc4/x86_64/build.log
>
> Looking into the opendap code, I've found literally dozens of places
> where pointer differences like the one above are treated as 32-bit int
> values.
>
> So, here are my questions:
>
>  1) Is there some way to turn these errors into warnings and 
>     ignore them?  Is that what happens in FC-3?
>
>  2) If the answer to (1) is "NO", then I assume that the code needs 
>     to be cleaned up.  Do you (as the opendep maintainer) intend to 
>     fix them?
>
>  3) If the answer to (2) is "NO", then is it OK for me to remove 
>     opendap as a BuildRequires for nco since it is, after all, 
>     an optional feature?
>
> I don't mean to be a pain, I'm just a little overwhelmed by the work
> that appears to be be necessary to get opendap to build for FC-4 and
> FC-5, etc.  And all I really want is an nco built for FC-4 and I'm just
> not as concerned about having opendap support (although it would be
> nice).
>
> So what should we do?
>
> Ed