Differences between revisions 122 and 123
Revision 122 as of 2005-10-18 21:59:46
Size: 501
Editor: DannFrazier
Comment:
Revision 123 as of 2007-08-31 18:57:25
Size: 1391
Editor: DannFrazier
Comment: better describe the problem and note that the buildd will fail builds for it
Deletions are marked like this. Additions are marked like this.
Line 5: Line 5:
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.

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.
Line 6: Line 14:

I've deprecated the table here - usertags make this easy to track in the BTS -dannf

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.

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 [http://bugs.debian.org/cgi-bin/pkgreport.cgi?users=dannf@debian.org;which=tag&data=implicit-pointer-conversion&archive=no summary page], filtered on my implicit-pointer-conversion usertag.