James Hawkins wrote:
On 4/8/06, Colin Wright <[EMAIL PROTECTED]> wrote:
So although it would always return 0 it could set a bogus error.
In the -1 example above we have same-sized buffers so the error is bogus.
Bug.
In the -2 example above we haven't even checked the strings so the error is
bo
On 4/8/06, Colin Wright <[EMAIL PROTECTED]> wrote:
>
> So although it would always return 0 it could set a bogus error.
> In the -1 example above we have same-sized buffers so the error is bogus.
> Bug.
>
> In the -2 example above we haven't even checked the strings so the error is
> bogus.
> Bug.
James Hawkins wrote:
> On 4/7/06, Colin Wright <[EMAIL PROTECTED]> wrote:
>>
>> #include
>> int main(void)
>> {
>>short int i;
>>unsigned short int j;
>>j = 65534;
>>i = j + 1;
>>printf("The result is %d\n", i);
>>return 0;
>> }
>>
>
> Thanks for the info, but I know C ba
On 4/7/06, Colin Wright <[EMAIL PROTECTED]> wrote:
>
> #include
> int main(void)
> {
>short int i;
>unsigned short int j;
>j = 65534;
>i = j + 1;
>printf("The result is %d\n", i);
>return 0;
> }
>
Thanks for the info, but I know C base types limits. If you'll take a
look
James Hawkins wrote:
On 4/7/06, Robert Shearman <[EMAIL PROTECTED]> wrote:
strlen returns a value of type size_t, which is an unsigned value, so
this is always going to be positive.
But strlenW returns an int. I think this is the thing that Coverity is
picking up on.
strlenW from include
Tom Spear wrote:
On 4/7/06, *Michael Stefaniuc* <[EMAIL PROTECTED]
I couldn't agree more. Matter of fact I recall that this is the reason
that the KLEZ virus from a few years ago was able to infect a linux
system running outlook express on wine, as well as why certain games
crash (they wor
On 4/7/06, Michael Stefaniuc <[EMAIL PROTECTED]> wrote:
Tom Spear wrote:>> 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 i
Tom Spear wrote:
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
On 4/7/06, James Hawkins <[EMAIL PROTECTED]> wrote:
On 4/7/06, Tom Spear (Dustin Booker, Dustin Navea) <[EMAIL PROTECTED]> 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 _so
If the function never checks that parameter for NULL, the checker won't
complain about it.
OK, I didn't realise that, thanks.
Please be careful before writing off a warning from the checker as "not
a bug".
I'll go back over the ones I marked as such and double check them for this.
On 4/7/06, Robert Shearman <[EMAIL PROTECTED]> wrote:
> >
> >strlen returns a value of type size_t, which is an unsigned value, so
> >this is always going to be positive.
> >
>
> But strlenW returns an int. I think this is the thing that Coverity is
> picking up on.
>
strlenW from include/wine/uni
James Hawkins wrote:
On 4/7/06, Tom Spear (Dustin Booker, Dustin Navea) <[EMAIL PROTECTED]> 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 ve
On 4/7/06, Tom Spear (Dustin Booker, Dustin Navea) <[EMAIL PROTECTED]> 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 gu
James Hawkins wrote:
On 4/6/06, Mike Hearn <[EMAIL PROTECTED]> wrote:
OK, that was a bit over-enthusiastic. A few of these are more tricky. EG:
Of the possible bugs I've seen so far, most of them are valid and
worth fixing, but the checker stumbles over WideCharToMultiByte. The
check
Mike McCormack wrote:
>
> Tomas Carnecky wrote:
>
>>> * Another (missing NULL ptr check in LoadTypeLibEx) is right, but, I
>>> don't
>>> think we want to add lots of missing NULL arg checks in the public
>>> API implementations. An application will never pass NULL to this
>>> function directly
Tomas Carnecky wrote:
* Another (missing NULL ptr check in LoadTypeLibEx) is right, but, I don't
think we want to add lots of missing NULL arg checks in the public API
implementations. An application will never pass NULL to this function
directly as otherwise it'd not work at all, so, a cr
Mike Hearn wrote:
>
> * Another (missing NULL ptr check in LoadTypeLibEx) is right, but, I don't
> think we want to add lots of missing NULL arg checks in the public API
> implementations. An application will never pass NULL to this function
> directly as otherwise it'd not work at all, so
When changing the status of an item in the Coverity database it would be
helpful if people making the change put in a comment to indicate the basis on
which the decision was made - much like an SCM commit log entry it will help
anybody else who ends up looking at the item later, whether to doubl
On 4/6/06, Troy Rollo <[EMAIL PROTECTED]> wrote:
> Some of the "bugs" it picks up are cases of defensive programming, such as
> checking for a NULL pointer even though the NULL pointer is impossible, given
> the functioning of routines that are being called. What should the policy be
> on such bugs
Some of the "bugs" it picks up are cases of defensive programming, such as
checking for a NULL pointer even though the NULL pointer is impossible, given
the functioning of routines that are being called. What should the policy be
on such bugs - should we remove the unnecessary check or keep the
On 4/6/06, Mike Hearn <[EMAIL PROTECTED]> wrote:
>
> OK, that was a bit over-enthusiastic. A few of these are more tricky. EG:
>
Of the possible bugs I've seen so far, most of them are valid and
worth fixing, but the checker stumbles over WideCharToMultiByte. The
checker reports two errors for (m
Mike Hearn wrote:
On Thu, 06 Apr 2006 20:39:00 +0100, Mike Hearn wrote:
Yes, this is awesome news, so far every one I have checked is a real bug.
OK, that was a bit over-enthusiastic. A few of these are more tricky. EG:
* One was wrong, it didn't track the fact that the given variabl
On Thu, 06 Apr 2006 22:04:14 +0200, Andreas Mohr wrote:
> Examples of real bugs here would be a missing NULL pointer in
> *Wine internal* code that really should have had a NULL pointer check
> since it's dealing with exclusively internal data (i.e. data that has a
> rather closed life cycle within
Hi,
On Thu, Apr 06, 2006 at 08:54:17PM +0100, Mike Hearn wrote:
> * Another (missing NULL ptr check in LoadTypeLibEx) is right, but, I don't
> think we want to add lots of missing NULL arg checks in the public API
> implementations. An application will never pass NULL to this function
> di
On Thu, 06 Apr 2006 20:39:00 +0100, Mike Hearn wrote:
> Yes, this is awesome news, so far every one I have checked is a real bug.
OK, that was a bit over-enthusiastic. A few of these are more tricky. EG:
* One was wrong, it didn't track the fact that the given variable was
initialized by a sub
Yes, this is awesome news, so far every one I have checked is a real bug.
Coverity seem to be getting great PR from this and rightly so, the
"Stanford Checker", whatever it is, seems very effective.
Anyway most of these look like easy bugs to fix. I see several of us
already have access - so, pat
* Dan Kegel <[EMAIL PROTECTED]> [05/04/06, 22:49:13]:
> See http://scan.coverity.com/
> They say they've found 830 potential bugs - that's quite a few.
> I haven't seen 'em yet, still waiting for my registration to come through.
>From the coverity post on the samba-technical list I gather that the
See http://scan.coverity.com/
They say they've found 830 potential bugs - that's quite a few.
I haven't seen 'em yet, still waiting for my registration to come through.
- Dan
--
Wine for Windows ISVs: http://kegel.com/wine/isv
28 matches
Mail list logo
