James Hawkins wrote:
On 4/7/06, Colin Wright [EMAIL PROTECTED] wrote:
#include stdio.h
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
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
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
On 4/7/06, Colin Wright [EMAIL PROTECTED] wrote:
#include stdio.h
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 into the
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, a
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
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 as otherwise
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
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 guess) a bogus
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
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/unicode.h
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, 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 _somehow_ (dont ask
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, 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 if a
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
* 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 they'd
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,
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
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 a
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
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 (most)
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, 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 -
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
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
26 matches
Mail list logo
