Coverity doing scans of Wine codebase!

Tom Spear speeddymon at
Fri Apr 7 11:25:13 CDT 2006

On 4/7/06, James Hawkins <truiken at> wrote:
> On 4/7/06, Tom Spear (Dustin Booker, Dustin Navea) <speeddymon at>
> wrote:
> > >
> > > if (srclen < 0) srclen = strlenW(src) + 1;
> > >
> > > so we never access the string with a negative index.
> > >
> >
> > Umm, all that does is increment it by 1...  What if _somehow_ (dont ask
> > me how, just venturing a guess) a bogus number is passed by strlenW(src)
> > like -3789246?  Then you end up with srclen == -3789245...
> >
> strlen returns a value of type size_t, which is an unsigned value, so
> this is always going to be positive.
> > > * Negative value can be returned and we don't check for it.
> > >
> > I could be wrong, but wouldnt it be (theoretically speaking) possible
> > for a program to force a negative number out of it (even though it isnt
> > supposed to be able to), since it IS an int, regardless of the return
> > value type?
> >
> If I write a function foo(x,y) that returns a signed int, but I only
> ever return a value >= 0, then no matter what input the user gives for
> x and y, a negative value can never be returned.  The problem is that
> MS decided to make the return type of WideCharToMultiByte int instead
> of unsigned int, which we can't change.  Let's say hypothetically that
> a negative value can be returned in our implementation, then it's
> still a bug in WideCharToMultiByte and these Coverity bugs are still
> false positives.
> That is true, but we also need to make sure that since we are going for
conformity (including conforming to MS's bugs) we don't fix a bug in our
code that is reported by Coverity, but that is also a bug in MS code..  So
if a game has to work around a bug in MS code, then our code should still
have that bug (so the game will work correctly), even if Coverity picks it

-------------- next part --------------
An HTML attachment was scrubbed...

More information about the wine-devel mailing list