> It looks like a good place to use broken().
I don't think it's broken on win98; it looks as though
they do 4 byte alignment prior to the data structure in win9x,
and winnt and on seem to do 8 byte alignment prior to the
data chunk. That results in a 4 byte difference.
Cheers,
Jeremy
On Wed, Dec 16, 2009 at 5:07 PM, Lei Zhang wrote:
> Hi, this is for bug 21045.
>
+SecurePackage *prev_package = NULL;
LIST_FOR_EACH_ENTRY(package, &packageTable->table,
SecurePackage, entry)
{
+if (prev_package)
+HeapFree(GetProcessHeap(), 0,
Hi Jeremy,
On 12/17/09 12:13 AM, Jeremy White wrote:
---
dlls/oleaut32/tests/usrmarshal.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/dlls/oleaut32/tests/usrmarshal.c b/dlls/oleaut32/tests/usrmarshal.c
index e9c53e9..1c770de 100644
--- a/dlls/oleaut32/test
On Tue, Dec 15, 2009 at 11:54 AM, Dan Kegel wrote:
> The total count of valgrind warnings in the wine test suite has gone down
> from about 2000 a month ago... to about 1000 today
http://kegel.com/wine/valgrind/logs/2009-12-16-09.22.errs.txt
1 Use of uninitialised value of size 4
2 In
2009/12/16 James Hawkins :
> Also, you should never pass a function to a macro. What if FAILED
> were defined as:
>
> FAILED(x) (x & MASK1) | (x & MASK2)
>
> ?
>
Then the macro is broken, although admittedly most macros probably are.
> I knew it was a prototype, I just thought it was left over, as it wasn't at
> the top of the file, and I saw no other prototype in that file. As for
> testing, I was eventually going to re-compile, so I guess I'd figure this
> out later if you didn't mention it.
We're not here to test your patch
On Wed, Dec 16, 2009 at 11:09 AM, Juan Lang wrote:
> Hi Amine,
>
> this patch has no functional benefit. For example,
> - HRESULT hr;
>
> TRACE("\n");
>
> - hr = SMTPTransport_ParseResponse(This, pBuffer, &response);
> - if (FAILED(hr))
> + if (FAILED(SMTPTransport_ParseResponse(T
> Well, that's entirely up to you guys ;)
Not really, it's up to you too. This is essentially a style-only
change. Alexandre generally frowns on these, but reluctantly accepts
them if the existing style is horrible, or if you're actively involved
in the code being modified. Neither appears to b
> It makes the code use one less variable. I don't see how is this dubious,
> but I understand that it's trivial.
Yes, at the cost of potentially less readability, or, depending on the
compile settings, a little more difficulty in checking whether the
function succeeded. I don't see that the bene
Hi Amine,
-static void SMTPTransport_CallbackMessageSendTo(IInternetTransport
*iface, char *pBuffer, int cbBuffer);
-
> The actual function is a little bit under.
Um, it's called a prototype, and it's needed to compile
smtptransport.c. Have you tested this patch at all?
--Juan
Hi Amine,
this patch has no functional benefit. For example,
-HRESULT hr;
TRACE("\n");
-hr = SMTPTransport_ParseResponse(This, pBuffer, &response);
-if (FAILED(hr))
+if (FAILED(SMTPTransport_ParseResponse(This, pBuffer, &response)))
This has the dubious benefit of removing
On 12/16/09 7:50 PM, Marcus Meissner wrote:
On Wed, Dec 16, 2009 at 07:30:22PM +0100, Paul Vriens wrote:
On 12/15/2009 09:16 PM, Jacek Caban wrote:
---
dlls/urlmon/binding.c | 6 +
dlls/urlmon/tests/url.c | 58 ++
2 files changed, 44 inser
On 12/16/09 7:30 PM, Paul Vriens wrote:
On 12/15/2009 09:16 PM, Jacek Caban wrote:
---
dlls/urlmon/binding.c | 6 +
dlls/urlmon/tests/url.c | 58
++
2 files changed, 44 insertions(+), 20 deletions(-)
Hi Jacek,
This one introduced a test failure
Austin English wrote:
> On Wed, Dec 16, 2009 at 12:28 PM, Amine Khaldi wrote:
>> WBR,
>> Amine Khaldi.
>
> Out of curiosity, what tool are you using to find these bugs?
>
I think he's using Clang. I've seen him on the LLVM bugzilla. He's
waiting for someone (e.g. me) to fix the bugs that prevent
On Wed, Dec 16, 2009 at 07:30:22PM +0100, Paul Vriens wrote:
> On 12/15/2009 09:16 PM, Jacek Caban wrote:
>> ---
>> dlls/urlmon/binding.c | 6 +
>> dlls/urlmon/tests/url.c | 58 ++
>> 2 files changed, 44 insertions(+), 20 deletions(-)
>>
>
> Hi Jacek,
>
On Wed, Dec 16, 2009 at 12:28 PM, Amine Khaldi wrote:
> WBR,
> Amine Khaldi.
Out of curiosity, what tool are you using to find these bugs?
--
-Austin
On Wed, Dec 16, 2009 at 12:28 PM, Amine Khaldi wrote:
> WBR,
> Amine Khaldi.
Out of curiosity, what tool are you using to find these bugs?
--
-Austin
On 12/15/2009 09:16 PM, Jacek Caban wrote:
---
dlls/urlmon/binding.c | 6 +
dlls/urlmon/tests/url.c | 58 ++
2 files changed, 44 insertions(+), 20 deletions(-)
Hi Jacek,
This one introduced a test failure:
http://test.winehq.org/data/tests/urlmon
On 12/15/2009 11:47 PM, Piotr Caban wrote:
---
dlls/urlmon/internet.c | 32
dlls/urlmon/tests/misc.c | 23 +--
2 files changed, 49 insertions(+), 6 deletions(-)
Hi Piotr,
This one has introduced some test failures:
http://test.w
Hi Amine,
r = register_clsid(&CLSID_StdHlink);
if (SUCCEEDED(r))
-r = register_clsid(&CLSID_StdHlinkBrowseContext);
+register_clsid(&CLSID_StdHlinkBrowseContext);
return S_OK;
In this case the correct fix is to return r. Please be more careful then doing
More progress on my http://wiki.winehq.org/UnitTestSuites effort:
Lei and I are running a buildbot that runs win32 chromium's unit tests
under wine under valgrind. It just came up yesterday, and we're
still working out some kinks, but you can see it at
http://build.chromium.org/buildbot/waterfall
2009/12/16 Owen Rudge :
> +214 stdcall MAPIFindNext(ptr ptr str str long long str)
The last parameter is an output parameter.
On 16/12/2009 05:13, Henri Verbeet wrote:
> These don't look quite right to me.
They were copied from the existing mapi32.dll. I think they're mostly
correct, although they do use "ptr" instead of "str". I'll double-check
them and update if necessary.
> Somewhat related, LHANDLE is a
> ULONG
Paul Vriens schrieb:
> On 12/16/2009 03:25 PM, André Hentschel wrote:
>> ---
>> dlls/msvcrtd/tests/debug.c |2 ++
>> 1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/dlls/msvcrtd/tests/debug.c b/dlls/msvcrtd/tests/debug.c
>> index 71f6e4c..dc89230 100644
>> --- a/dlls/msvc
On 12/16/2009 17:25, André Hentschel wrote:
---
dlls/msvcrtd/tests/debug.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/dlls/msvcrtd/tests/debug.c b/dlls/msvcrtd/tests/debug.c
index 71f6e4c..dc89230 100644
--- a/dlls/msvcrtd/tests/debug.c
+++ b/dlls/msvcrtd/tests/d
On 12/16/2009 03:25 PM, André Hentschel wrote:
---
dlls/msvcrtd/tests/debug.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/dlls/msvcrtd/tests/debug.c b/dlls/msvcrtd/tests/debug.c
index 71f6e4c..dc89230 100644
--- a/dlls/msvcrtd/tests/debug.c
+++ b/dlls/msvcrtd/test
2009/12/16 Stefan Dösinger :
> Actually, since we're not going to Unmap-flush and PreLoad() the buffer(its
> either-or), I can use the same data structure for the stack and list(or well,
> dynamic array). I just have to watch out not to remove elements in any place
> in unlock that affects DOUBL
Am 16.12.2009 um 13:44 schrieb Henri Verbeet:
> 2009/12/16 Stefan Dösinger :
>> The best way I see to merge those two tracking mechanisms is to organize
>> them as a list, and upload all modified ranges in PreLoad(), or if the
>> buffer is single buffered and dynamic, flush all the ranges after
2009/12/16 Stefan Dösinger :
> The best way I see to merge those two tracking mechanisms is to organize them
> as a list, and upload all modified ranges in PreLoad(), or if the buffer is
> single buffered and dynamic, flush all the ranges after the last unmap, and
> clear the list in both PreLoa
Am 16.12.2009 um 12:50 schrieb Henri Verbeet:
> What you're doing (or should be doing) is extending the
> "lock_count/dirty_start/dirty_end" scheme to something more detailed.
> I don't think using two different schemes depending on whether the
> buffer is dynamic or not is a good idea.
Sounds gre
2009/12/16 Stefan Dösinger :
> Am 16.12.2009 um 11:33 schrieb Henri Verbeet:
>
>> 2009/12/15 Stefan Dösinger :
>>> @@ -85,6 +85,21 @@ static void buffer_create_buffer_object(struct
>>> wined3d_buffer *This)
>> ...
>>> + This->maps = HeapAlloc(GetProcessHeap(), 0,
>>> sizeof(*This->maps
Maarten Lankhorst writes:
> +static ULONG WINAPI MMDevEnum_Release(IMMDeviceEnumerator *iface)
> +{
> +MMDevEnumImpl *This = (MMDevEnumImpl*)iface;
> +LONG ref = InterlockedDecrement(&This->ref);
> +TRACE("Refcount now %i\n", ref);
> +return ref;
> +}
Sounds like you want a stati
Am 16.12.2009 um 11:33 schrieb Henri Verbeet:
> 2009/12/15 Stefan Dösinger :
>> @@ -85,6 +85,21 @@ static void buffer_create_buffer_object(struct
>> wined3d_buffer *This)
> ...
>> +This->maps = HeapAlloc(GetProcessHeap(), 0,
>> sizeof(*This->maps));
>
> This is the wrong place for
2009/12/15 Owen Rudge :
> + 1 stdcall MAPIAddress(ptr ptr ptr long ptr long long ptr long ptr ptr)
> + 6 stdcall MAPILogoff(long long long long)
> +11 stdcall MAPISendMail(long long ptr long long)
These don't look quite right to me. Somewhat related, LHANDLE is a
ULONG in include/mapi.h, but a ULO
Am 16.12.2009 um 11:33 schrieb Henri Verbeet:
> 2009/12/15 Stefan Dösinger :
>> +/* buffer_get_sysmem can remove the BO from dynamic buffers */
> No, it can't?
Actually, that part slipped in form another patch I didn't send yet. It's
dropping dynamic VBOs if we put the buffer into do
2009/12/15 Stefan Dösinger :
> @@ -85,6 +85,21 @@ static void buffer_create_buffer_object(struct
> wined3d_buffer *This)
...
> +This->maps = HeapAlloc(GetProcessHeap(), 0, sizeof(*This->maps));
This is the wrong place for that. Either do it in buffer_init(), or in
buffer_Map(). Keepin
2009/12/15 Stefan Dösinger :
> +/* buffer_get_sysmem can remove the BO from dynamic buffers */
No, it can't?
> @@ -540,8 +547,8 @@ static HRESULT WINAPI
> IWineD3DDeviceImpl_CreateVertexBuffer(IWineD3DDevice *ifac
> TRACE("Not creating a vbo because GL_ARB_vertex_buffer is no
On 12/15/2009 15:52, Roderick Colenbrander wrote:
Great that you got it working. Regarding actctx, this should work fine
with our manifest support. Not much has to happen at all. Basically in
user32 it needs to be checked whether a window class (lets say the
Button one) is redirected or not. If i
On 12/16/2009 08:54 AM, Nikolay Sivov wrote:
On 12/16/2009 10:44, Paul Vriens wrote:
On 12/15/2009 11:48 PM, Piotr Caban wrote:
---
dlls/urlmon/tests/sec_mgr.c | 31 +++
1 files changed, 31 insertions(+), 0 deletions(-)
Hi Piotr,
Is there a way to avoid using lst
On 12/15/2009 08:46 PM, Hans Leidekker wrote:
On Tuesday 15 December 2009 20:09:12 Paul Vriens wrote:
We still have a crash on NT4 and failures on Win9x. I don't know why
win9x doesn't crash as well as we are using some uninitialzed string if
GetUserNameExA is not available.
Does the attached
40 matches
Mail list logo
