On Sun, 2006-03-12 at 04:13 +0100, Goswin von Brederlow wrote: > "David Mosberger-Tang" <[EMAIL PROTECTED]> writes: > > > On 3/11/06, Goswin von Brederlow <[EMAIL PROTECTED]> wrote: > > > >> > $ gcc-3.3 -c -g -O -Wall t.c > >> > t.c: In function `foo': > >> > t.c:4: warning: implicit declaration of function `strdup' > >> > t.c:4: warning: return makes pointer from integer without a cast > >> > >> (all asm is from amd64) > >> > >> 0000000000400500 <foo>: > >> 400500: 48 83 ec 08 sub $0x8,%rsp > >> 400504: 31 c0 xor %eax,%eax > >> 400506: e8 d5 fe ff ff callq 4003e0 <[EMAIL PROTECTED]> > >> 40050b: 48 83 c4 08 add $0x8,%rsp > >> 40050f: 48 98 cltq > >> 400511: c3 retq > >> > >> The return value of strdup is passed back unaltered. No crash. > > > > The context of this discussion was ia64, but I realize now that this > > probably wasn't obvious for debian-devel subscribers. I should have > > been clear about that. In any case, ia64 calling convention say that > > a 32-bit integer value in a (64-bit) register may contain garbage in > > the top 32 bits, hence the result from a function returning "int" will > > be sign- or zero-extended when converted to a 64-bit value, hence the > > crash. > > Ah, that explains it. On amd64 I believe the callee has to take care > of keeping the top 32bit clean, i.e. return values are already > extended to 64bit. Lucky us. > > Still, both original examples are harmfull and should be detected. A > crash is much simpler to detect than lost upper bits so I would > consider detecting the strlen case automaticaly much more > important. I bet the crash will get detected by itself.
Though this maybe out of scope for David's filter, I can certainly add additional filters to find other classes of bugs - assuming there are people who will do something with the results. Note that I'm currently only filtering the ia64 buildd logs. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
