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
Lionel Ulmer wrote:
Well it's the same for memory: who in his right mind in modern operating
system still 'free's at exit all 'malloc'ed memory :-) ?
Somebody who thinks his code may be reused in a library one day?
Mike
On Thu, Apr 06, 2006 at 10:18:16AM +0200, Stefan Dösinger wrote:
> Because windows' ddraw.dll restores everything when the app exists. I've
> added
> some code to do that do my ddraw lib. I restore the screen mode when the
> ddraw object is released, and on the last DllMain() unload call, I loop
On Thu, Apr 06, 2006 at 10:23:11AM +0200, Stefan Dösinger wrote:
> That would be usefull too for multithreaded direct3d. Somehow we have to
> bring
> another thread to releasing the glxContext, so we can re-use it in a new
> thread.
After discussing this at length on IRC with another coder, we
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
<[EMAIL PROTECTED]> wrote:
A couple of suggestions about coding style:
+struct transition_s {
+BYTE wVk;
It would be more logical to use WORD for VK codes as everywhere else.
+BYTE before_state;
+BYTE _todo_wine;
+};
Same for _todo_wine, it should be BOOL.
+
+struct sendinpu
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
Ben Chelf wrote:
Hello Wine Developers,
As some of you may have heard, last month Coverity set up
http://scan.coverity.com as a site dedicated to scanning open source
projects for defects. In just 1 month, over 4500 defects have been
examined by various open source developers, and from what
Aric Stewart wrote:
if(fodInfos->unicode)
{
LPOPENFILENAMEW ofn = fodInfos->ofnInfos;
-strcpyW( ofn->lpstrFile, lpstrPathSpec);
-memcpy( ofn->lpstrFile + nSizePath, lpstrFileList, sizeUsed*sizeof(WCHAR)
);
+ if (nSizePath+sizeUsed > ofn->nMaxFile)
+ {
+
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
I thought INVALID_HANDLE_VALUE==-1 and not 0. Moreover, I can't see any
code path leading to ERR where handle is allocated (or assigned to) at
all so I think there is no need to close it.
Mike Hearn wrote:
Mike Hearn <[EMAIL PROTECTED]>
Don't close uninitialized handle on VXD error path
diff
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
Detlef Riekenberg <[EMAIL PROTECTED]> writes:
> "make etags" and "make ctags" are broken.
What's broken about them?
--
Alexandre Julliard
[EMAIL PROTECTED]
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
Stefan Dösinger a écrit :
So, i have just reported them the problem and explain that it works with
dri, so i hope they will make something to correct it
Don't expect too much from at :( Just have a look at the linux driver forum at
www.rage3d.com
I know that but if noone annoy them
Hi,
The 2006 SourceForge.net Community Choice Awards have
been announced ... and it seems the Desktop Winner is:
"WINE . for Darwin and Mac OS X"
Strangely enough, our project directly does not appear
to be listed at all in the "Desktop" category.
Still considering whether to be sad or happ
On Thu, Apr 06, 2006 at 01:49:52PM +1000, Troy Rollo wrote:
> The problem is due to an old version of fontforge. In Debian, version
> 0.0.20041218-0.1 generates incorrect ascent information for the Windows font
> header. Version 0.0.20051205-0.1 gets it right. For Debian users,
> 0.0.20051205-0.
Hello Wine Developers,
As some of you may have heard, last month Coverity set up
http://scan.coverity.com as a site dedicated to scanning open source
projects for defects. In just 1 month, over 4500 defects have been
examined by various open source developers, and from what we can tell,
it
On Thu, Apr 06, 2006 at 12:45:01PM +0100, Huw D M Davies wrote:
> Huw Davies <[EMAIL PROTECTED]>
> fonts: Add the Won Sign in place of the backslash for Korean fonts
Actually could you ignore this for the moment? Dmitry's got a patch
that's about to arrive that'll clash with this, and this one is
On Thu, Apr 06, 2006 at 01:49:52PM +1000, Troy Rollo wrote:
> On Thursday 06 April 2006 12:31, Troy Rollo wrote:
> > On Thursday 06 April 2006 11:06, Tom Spear (Dustin Booker, Dustin Navea)
> >
> > wrote:
> > > I dont know if this will help, but it is worth a shot... Install
> > > fontforge from fo
> The wineserver would have to trigger some code in the client, either by
> having a signal or a generic background thread that could do it on behalf
> of the other process.
>
> Such a scheme has been discussed before for things like CreateRemoteThread
> and friends.
That would be usefull too for
Hi,
> Haha well where that idea comes from is like when Diablo 2 gets the
> gamma error, it has already resized the resolution, but decides to
> quit and not resize it back. Not very nice, but games do funny things
> like that.
Because windows' ddraw.dll restores everything when the app exists. I'
26 matches
Mail list logo
