Do the cast warning messages I see when compiling previously 32 bit applications on the amd64 really mean all that much?
Now I understand that you do not want to store an 8 byte pointer into a 4 byte variable or get a 8 byte pointer from a 4 byte variable. If the code underlying the calls does the "right thing" (e.g., defines the actual storage space with something like "void *" or "long"), then is there really a problem underlying the cast warnings? That is, is it worth the pain to go fix things so that the cast messages do not occur?
I went to some effort to clean up nessus so building it had no cast messages. But was it worth it. As I am rebuilding some of the i386 updated packages on the amd64, I am seeing cast messages in existing packages that seem to work OK (e.g., ethereal).
So again, is it worth much effort to clean these up other than having clean (no warning) compiles. For example, you have a function which extracts something from an array/table and may return a pointer sometimes and other times an integer. If you know that when you call it in a certain manner it will return an integer, then what does the cast warning matter?
On Wed, Jan 28, 2004 at 12:57:41PM -0500, Gene C. wrote:
Do the cast warning messages I see when compiling previously 32 bit applications on the amd64 really mean all that much?
It depends. They range from "hard to avoid noise" to "indicators of killer bugs". You can tell only on a case-by-case basis.
Now I understand that you do not want to store an 8 byte pointer into a 4 byte variable or get a 8 byte pointer from a 4 byte variable. If the code underlying the calls does the "right thing" ...
If the code does really then "right thing" then you do not have a warning; but sometimes it may be difficult to do that without extensive rewrites.
That is, is it worth the pain to go fix things so that the cast messages do not occur?
Usually yes, in my experience; to an extent. It helps immensly to catch remaining bugs if a code is clean. Very often doing that just simply fixes nasty bugs.
Some "fun" things to trip you include a global variable for which some library provided only an 'int' storage but you are writing 'long' there. You will crash, or not, in an unrelated place depending on what and when you overwrote in "other" four bytes. Or things which change size in a way hard to notice across a function call boundary, or places which rely implicitely and silently on a sign extension which will not work the same in 32 and 64 bits. Or ... If you are using C++ then opportunities for various size abuses, and difficulties of finding these, go up exponentially.
I went to some effort to clean up nessus so building it had no cast messages. But was it worth it.
Here you are. :-)
For example, you have a function which extracts something from an array/table and may return a pointer sometimes and other times an integer.
Then really union should have been used; but sources of X, for example, are chock-full of such junk and that's life.
Michal
On Wednesday 28 January 2004 15:34, Michal Jaegermann wrote:
On Wed, Jan 28, 2004 at 12:57:41PM -0500, Gene C. wrote:
I went to some effort to clean up nessus so building it had no cast messages. But was it worth it.
Here you are. :-)
My effort were to get rid of the cast messages and not to really fix the code (see below). I did check the underlying code of the called function and it is going to work. Nessus keeps a lot of its data in tables where an element "value" may contain a pointer or an integer having various meanings depending on the setting of another int variable in the element. The storage for the "value" is defined as "void *" so the right size will be allocated.
For example, you have a function which extracts something from an array/table and may return a pointer sometimes and other times an integer.
Then really union should have been used; but sources of X, for example, are chock-full of such junk and that's life.
Yes, sigh, you are right. Doing things the right way would involve using a union.
If I was the owner of a package, I might (almost assuredly would) do it the right way. But, for many upstream package owners/originators/maintainers, they are more interested in package functionality than in doing things "the right way" so that the "right thing" is done regardless of the architecture/platform and moving to a system with 128 bit address still works.
If a package owner decides to do things "the right way", then it will likely get down. For someone downstream to submit (likely extensive) patches is a whole different situation. I will need to think about whether it is worth the attempt.
Thanks for your comment ... it clarified things for me. The use of unions had occurred to me but I rejected it as too intrusive into the package owners efforts.
how can i set apt to use fedora core 2 rawhide??
Alex Thomsen Leth
Alex Thomsen Leth wrote :
how can i set apt to use fedora core 2 rawhide??
You can use ayo.freshrpms.net. Just replace "1" in the sources.list for the "core" component by "development" and you'll be all set. See the sources.list linked at the bottom of the page if you're not already using that repository.
Matthias
PS: There seems to be some lag for the development rpms on the main ayo server currently, you can try ayo.us.freshrpms.net if it's still the case.
-
Alex Thomsen Leth -
Gene C. -
Matthias Saou -
Michal Jaegermann -
Satish Balay