opendap is far from being 64-bit clean
Hans de Goede
j.w.r.degoede at hhs.nl
Wed Aug 3 07:06:53 UTC 2005
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
>
More information about the fedora-extras-list
mailing list