Mention 68k-specific bits of this problem
converted to 1.6 markup
|Deletions are marked like this.||Additions are marked like this.|
|Line 12:||Line 12:|
|A debbugs [http://email@example.com;which=tag&data=implicit-pointer-conversion&archive=no summary page], filtered on my implicit-pointer-conversion usertag.||A debbugs [[http://firstname.lastname@example.org;which=tag&data=implicit-pointer-conversion&archive=no|summary page]], filtered on my implicit-pointer-conversion usertag.|
Packages with implicit pointer conversion warnings. (As reported by feeding the build log to http://people.debian.org/~dannf/check-implicit-pointer-functions)
When gcc doesn't know the return type of a function (e.g., no prototype is defined for it), it will assume it is an integer. This will cause gcc to print a warning about an implicitly converted pointer.
On architectures such as i386, the size of a pointer is the same as the size of an int. So if the actual return value is a pointer and the compiler converts it to a pointer, there's really no harm done. However, on architectures where the size of a pointer is greater than the size of an integer, truncation will occur. Also, architectures such as m68k have different modes for pointers and integers; having the compiler think a function returns an integer when it actually returns a pointer will cause the compiled code to go looking for the return value in the wrong place.
Sometimes this doesn't cause a problem - for example, if the first 32 bits of the pointer are 0s then the truncation won't actually break anything. This is often the case on some architectures, e.g. amd64. This will never be the case for other architectures, e.g. ia64, which will always break (segfault) if the pointer is dereferenced.
As of late August 2007, the ia64 buildds will automatically fail builds that fail this build log filter.
A debbugs summary page, filtered on my implicit-pointer-conversion usertag.