2010/1/8 Paul Vriens :
> -i = memcmp(decl, vertex_decl, sizeof(vertex_decl));
> +i = memcmp(decl, vertex_decl, sizeof(*vertex_decl));
I think that should be "num_elements * sizeof(*vertex_decl)" even.
On Fri, Jan 08, 2010 at 10:17:59AM -0600, Austin English wrote:
> On Fri, Jan 8, 2010 at 2:42 AM, Paul Vriens
> wrote:
> > Hi,
> >
> > Just wanted to mention the fact that Marcus (almost single-handedly for the
> > last months) got the number of issues below 300.
>
> Thanks Marcus!
No worries.
James Hawkins wrote:
Write and submit tests that show the correct behavior, then submit a
patch that makes Wine match that behavior. In general, questions like
"What's the right fix?" can be answered by thorough, well-thought out
tests.
I can write tests for the cases I just described and my f
On Fri, Jan 8, 2010 at 12:40 PM, Julius Schwartzenberg
wrote:
> Hi,
>
> Maybe you know, I hope to submit several fixes and tests for avifile soon.
> Vitaliy Margolen pointed out I should be create proper temporary files in
> the system's tmp directory so I implemented this. This actually showed a
Hi,
Maybe you know, I hope to submit several fixes and tests for avifile
soon. Vitaliy Margolen pointed out I should be create proper temporary
files in the system's tmp directory so I implemented this. This actually
showed a new bug in Wine's avifile:
Wine's avifile does not handle normal a
On Fri, Jan 8, 2010 at 11:28 AM, Alexandre Julliard wrote:
> The Wine development release 1.1.36 is now available.
>
> What's new in this release (see below for details):
> - Completion of the 16-bit separation.
Congrats Alexandre and co.!
--
James Hawkins
Thanks for the suggestions, André, Erich, and Reece. Got a few more
ideas at least, though I still haven't found the answer.
Reece Dunn wrote:
The code above is using different methods to locate an IHlinkTarget
object, and then calling the Navigate method on that (and presumably
returning the
On 1/8/2010 21:52, James Hawkins wrote:
On Fri, Jan 8, 2010 at 10:08 AM, Nikolay Sivov wrote:
Free descriptor if it isn't returned from GetSecurityInfo() (Valgrind).
This is very wrong :-) You should read the comment above the test
that causes the leak. Dan has notice to suppress
On Fri, Jan 8, 2010 at 10:08 AM, Nikolay Sivov wrote:
> Free descriptor if it isn't returned from GetSecurityInfo() (Valgrind).
>
This is very wrong :-) You should read the comment above the test
that causes the leak. Dan has notice to suppress this valgrind error,
so it shouldn't show up in th
On Fri, Jan 8, 2010 at 2:42 AM, Paul Vriens wrote:
> Hi,
>
> Just wanted to mention the fact that Marcus (almost single-handedly for the
> last months) got the number of issues below 300.
Thanks Marcus!
> Only 11 of those are marked as either a bug or are pending. The rest is
> either false (Cov
On Fri, Jan 8, 2010 at 6:52 AM, Alexandre Julliard wrote:
> There's no reason that RtlGetNtGlobalFlags would need the TEB at all.
Well, that's where native puts the flags. OK, I'll put them elsewhere.
Dan Kegel writes:
> Posting a working if suboptimal implementation
> is a clear way of framing questions sometimes,
> but I guess when I do that it should be to wine-devel.
Questions and RFCs should go to wine-devel. Sending to wine-patches
means "I believe this is good enough to be committed".
On Fri, Jan 8, 2010 at 6:41 AM, Dan Kegel wrote:
> Maybe what we want is a safe implementation of RtlGetNtGlobalFlags(), one
> that returns zero if it's not safe to call NtCurrentTeb().
> We could store the global flags in a plain old global variable,
> and copy it in to the peb but never referenc
On Fri, Jan 8, 2010 at 2:08 AM, Alexandre Julliard wrote:
>> To check whether we're too early in process setup to
>> check global flags, I compare the arguments of RtlCreateHeap
>> with the ones used by the call in virtual_init(). This is
>> not especially clean, but I couldn't think of anything
Dan Kegel, you wrote:
To check whether we're too early in process setup to
check global flags, I compare the arguments of RtlCreateHeap
with the ones used by the call in virtual_init(). This is
not especially clean, but I couldn't think of anything
better.
I was thinking, couldn't you place the
2010/1/8 Wolfram Sang :
> Geoffrey Hausheer wrote:
>
>> Would someone mind reviewing this for style/content? I still have no
>
> Can't say much about the content, but stylewise the pointer handling
> could be improved. For example,
>
> + if ( (iface==0) || (ppvObject==0) )
>
> should at least u
Dan Kegel writes:
> To check whether we're too early in process setup to
> check global flags, I compare the arguments of RtlCreateHeap
> with the ones used by the call in virtual_init(). This is
> not especially clean, but I couldn't think of anything
> better. I can hear Alexandre hitting the
Geoffrey Hausheer wrote:
> Would someone mind reviewing this for style/content? I still have no
Can't say much about the content, but stylewise the pointer handling
could be improved. For example,
+if ( (iface==0) || (ppvObject==0) )
should at least use NULL instead of 0 as both are pointe
Dan Kegel writes:
> @@ -1254,14 +1291,20 @@ HANDLE WINAPI RtlCreateHeap( ULONG flags, PVOID addr,
> SIZE_T totalSize, SIZE_T c
> {
> SUBHEAP *subheap;
>
> -/* Allocate the heap block */
> +/* Check global flags unless we're being called in virtual_init before
> they
> + * ar
Peter Dons Tychsen writes:
> @@ -85,6 +85,17 @@ BOOL set_capture_window( HWND hwnd, UINT gui_flags, HWND
> *prev_ret )
> HWND previous = 0;
> UINT flags = 0;
> BOOL ret;
> +GUITHREADINFO info;
> +if(!GetGUIThreadInfo(GetCurrentThreadId(), &info))
> +{
> +return
Hi,
Just wanted to mention the fact that Marcus (almost single-handedly for
the last months) got the number of issues below 300.
Only 11 of those are marked as either a bug or are pending. The rest is
either false (Coverity thinks there is an error, but we don't) or to be
ignored (for exampl
21 matches
Mail list logo
