On So, 2011-05-01 at 21:55 +0400, Nikolay Sivov wrote:
> On 5/1/2011 21:49, Alexey Fisher wrote:
> > On So, 2011-05-01 at 19:11 +0400, Nikolay Sivov wrote:
> >> On 5/1/2011 13:07, Alexey Fisher wrote:
> >>> There is a new patch in the attachment.
> >>>BOOL Str_SetPtrAtoW (LPWSTR *lppDest, LPCST
On 5/1/2011 21:49, Alexey Fisher wrote:
On So, 2011-05-01 at 19:11 +0400, Nikolay Sivov wrote:
On 5/1/2011 13:07, Alexey Fisher wrote:
There is a new patch in the attachment.
BOOL Str_SetPtrAtoW (LPWSTR *lppDest, LPCSTR lpSrc)
{
-TRACE("(%p %s)\n", lppDest, lpSrc);
+TRACE("(%p, %s
On So, 2011-05-01 at 19:11 +0400, Nikolay Sivov wrote:
> On 5/1/2011 13:07, Alexey Fisher wrote:
> >
> > There is a new patch in the attachment.
>
> > BOOL Str_SetPtrAtoW (LPWSTR *lppDest, LPCSTR lpSrc)
> > {
> > -TRACE("(%p %s)\n", lppDest, lpSrc);
> > +TRACE("(%p, %s)\n", *lppDest, d
On 05/01/2011 10:29 AM, Alexey Fisher wrote:
Correct me if I'm wrong. You can't ReAlloc pointer only if you allocated
the memory by Alloc. At least for glibc.
First of all we talking about Wine's functions HeapAlloc, HeapReAlloc, and
HeapFree.
The HeapReAlloc can and does re-allocate memory
On So, 2011-05-01 at 08:05 -0700, Dan Kegel wrote:
> On Sun, May 1, 2011 at 2:07 AM, Alexey Fisher
> wrote:
> >> > The code looks like it assumes that pointer is always
> >> > managed by Alloc/ReAlloc/Free. In what context is
> >> > the destination a fresh, non-Alloc'd pointer?
> >> > Perhaps tha
On 5/1/2011 13:07, Alexey Fisher wrote:
There is a new patch in the attachment.
BOOL Str_SetPtrAtoW (LPWSTR *lppDest, LPCSTR lpSrc)
{
-TRACE("(%p %s)\n", lppDest, lpSrc);
+TRACE("(%p, %s)\n", *lppDest, debugstr_a(lpSrc));
+
+if (*lppDest) {
+ERR("lppDest should be NULL
On Sun, May 1, 2011 at 2:07 AM, Alexey Fisher
wrote:
>> > The code looks like it assumes that pointer is always
>> > managed by Alloc/ReAlloc/Free. In what context is
>> > the destination a fresh, non-Alloc'd pointer?
>> > Perhaps that's where the bug lies.
>>
>> We do not need to save anything w
On Sunday 01 May 2011 14:34:53 Emanuele Oriani wrote:
> Indeed, I've written a spinlock with GCC extension and replaced the
> EnterCriticalSection in the x11 drv file.
> Apart that the lock has got to be recursive, so I implemented a quick
> (but incorrect) recursive spinlock for the purpose of run
Indeed, I've written a spinlock with GCC extension and replaced the
EnterCriticalSection in the x11 drv file.
Apart that the lock has got to be recursive, so I implemented a quick
(but incorrect) recursive spinlock for the purpose of running SC2 and
difference was barely negligible.
The biggest
On So, 2011-05-01 at 07:43 +0200, Alexey Fisher wrote:
> Am Samstag, den 30.04.2011, 14:41 + schrieb Dan Kegel:
> > Alexey wrote:
> >
> > > i currently digg in comctl32 to find why my app fails. I found that
> > > string conversation AtoW in some places silently fails. The problem is
> > > tha
Hi,
On Apr 29, 2011, at 3:50 PM, Andrew Eikum wrote:
> +LIST_FOR_EACH_ENTRY(client, &This->session->clients, ACImpl, entry){
> +OSSpinLockLock(&client->lock);
> +if(client->playing == StatePlaying){
> +*state = AudioSessionStateActive;
I think the session should b
On Saturday 30 April 2011 18:26:04 Emanuele Oriani wrote:
> Hi Stefan,
>
> What do you think about using inline spinlocks (in asm code maybe) to
> implement locks?
> Clearly an optimized spinlock would mean different code for different
> compilers/architectures, but shouldn't it be the best soluti
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=10649
Your paranoid android
13 matches
Mail list logo
