How many bugs out there?
-
Hey, but it works on my machine.
It is a crappy thing, but it's life -^ Carlo Pallini
Rajesh R Subramanian wrote:
Hey, but it works on my machine.
Put that Mac down!
I wanna be a eunuchs developer! Pass me a bread knife!
-
Well, this is my first post. I was thinking about the Windows bug caused by a forgotten "&". It made me think that the compiler would raise a warning in a such situation. So, they must have ignored it. A lame coder like me wants a clean(no warnings at all, even in C++) code, but a Microsoft team probably ignored warnings. You know warnings are there to warn coders against potential bugs. Well, they must have pretty much warnings so they ignored that. OK, my question comes: How many warnings, do you think, Windows source code gives when compiling? And please specify the version ;) Oh, my bet: Vista, compiling on a 32-bit machine, warning count causes an integer overflow :P Have a good day!
Could someone post also a link about this Microsoft bug? TIA
-
Rajesh R Subramanian wrote:
Hey, but it works on my machine.
Put that Mac down!
I wanna be a eunuchs developer! Pass me a bread knife!
Mark Wallace wrote:
Rajesh R Subramanian wrote: Hey, but it works on my machine. Put that Mac down!
Concur! -GateHawk
-
_fboy_ wrote:
I was thinking about the Windows bug caused by a forgotten "&". It made me think that the compiler would raise a warning in a such situation. So, they must have ignored it.
It wasn't a forgotten & - it was an extra one. Instead of passing a pointer, they passed the address of a pointer. Depending on function declarations, a compiler may not spot this, for the simple reason the types are the same. Passing the address of a pointer is fairly common in COM (see QueryInterface[^] for an example.
It depends on the signature of the function being called. If the pointer was LPVOID (for example) that may be the case, but if the pointer was to a concrete type (e.g. int) the & and && forms have different types, which the compiler should catch. Even if the compiler missed it I'd expect any of the major static analysis tools would be able to identify such an error.
Anna :rose: Having a bad bug day? Tech Blog | Anna's Place | Tears and Laughter "If mushy peas are the food of the devil, the stotty cake is the frisbee of God"
-
Why would you get unreachable code with conditional compilation? You shouldn't if you do it "right":
void Function()
{// do stuff
#if SILVERLIGHT
// do stuff
return;
#else
// do other stuff
return;
#endif
}
If you have unreachable code, just put it in an else block. I can't think of a situation where this doesn't work.
My bad - I wasn't thinking straight. The unreachable code warnings I encounter are mostly when I'm making a temporary change just to test something rather than conditional compilation. It can be an issue when using a constant flag to determine which path to take rather than a config setting or conditional compilation symbol, though I guess that is the wrong use of a const.
-
It depends on the signature of the function being called. If the pointer was LPVOID (for example) that may be the case, but if the pointer was to a concrete type (e.g. int) the & and && forms have different types, which the compiler should catch. Even if the compiler missed it I'd expect any of the major static analysis tools would be able to identify such an error.
Anna :rose: Having a bad bug day? Tech Blog | Anna's Place | Tears and Laughter "If mushy peas are the food of the devil, the stotty cake is the frisbee of God"
Maybe. A quick Google failed to turn up the offending source code. Have you seen the actual problem lines? It would be interesting to pass it through Lint (or a more "visual" version of it :-D )
-
It depends on the signature of the function being called. If the pointer was LPVOID (for example) that may be the case, but if the pointer was to a concrete type (e.g. int) the & and && forms have different types, which the compiler should catch. Even if the compiler missed it I'd expect any of the major static analysis tools would be able to identify such an error.
Anna :rose: Having a bad bug day? Tech Blog | Anna's Place | Tears and Laughter "If mushy peas are the food of the devil, the stotty cake is the frisbee of God"
Anna-Jayne Metcalfe wrote:
Even if the compiler missed it I'd expect any of the major static analysis tools would be able to identify such an error.
Yeah - and what would you know about static analysis tools anyway? ;P
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
-
Maybe. A quick Google failed to turn up the offending source code. Have you seen the actual problem lines? It would be interesting to pass it through Lint (or a more "visual" version of it :-D )
I must admit I haven't - I'm just going on what I've learnt from experience. I could try it easily enough given the code - the value tracking in PC-lint 9.0 is pretty good, so even if it's an LPVOID there's a good chance it will spot it. I can't speak for PreFAST (which MS use internally), though when I've run that on some of our reference codebases it's missed some pretty basic stuff.
Anna :rose: Having a bad bug day? Tech Blog | Anna's Place | Tears and Laughter "If mushy peas are the food of the devil, the stotty cake is the frisbee of God"
-
Anna-Jayne Metcalfe wrote:
Even if the compiler missed it I'd expect any of the major static analysis tools would be able to identify such an error.
Yeah - and what would you know about static analysis tools anyway? ;P
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
Pete O'Hanlon wrote:
Yeah - and what would you know about static analysis tools anyway?
Guilty as charged! :-O Just for a change I'm knee-deep in refactoring at the moment. Boy is it fun... :doh:
Anna :rose: Having a bad bug day? Tech Blog | Anna's Place | Tears and Laughter "If mushy peas are the food of the devil, the stotty cake is the frisbee of God"
-
Anna-Jayne Metcalfe wrote:
Even if the compiler missed it I'd expect any of the major static analysis tools would be able to identify such an error.
Yeah - and what would you know about static analysis tools anyway? ;P
"WPF has many lovers. It's a veritable porn star!" - Josh Smith
As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
Ouch! Pete, that was harsh.
-
_fboy_ wrote:
I was thinking about the Windows bug caused by a forgotten "&". It made me think that the compiler would raise a warning in a such situation. So, they must have ignored it.
It wasn't a forgotten & - it was an extra one. Instead of passing a pointer, they passed the address of a pointer. Depending on function declarations, a compiler may not spot this, for the simple reason the types are the same. Passing the address of a pointer is fairly common in COM (see QueryInterface[^] for an example.
And I wonder how can you trust an interface called IUnknown? :laugh: