axis-c-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Blecken" <>
Subject RE: Possbile bug in Axis.cpp on Win32 (XP, VC7.1)
Date Thu, 21 Apr 2005 23:58:56 GMT
This seems to be the main reason why we can't compile on VC7.

I looked at the defs in winbase.h in 6 and 7 and the arguments have really
changed. Must be still void* in the end, since the call is implemented in 

Apart from defining ifdefs (i.e. WIN32_VC6 and WIN32_VC7) I can only 
suggest to change the synchronization primitive. Why not using a mutex
like the UNIX code?

This seems to compile on both VC6 and VC7:

#ifdef WIN32

static HANDLE hMutex = NULL; 

static void start_initializing()
	if (NULL == hMutex)
		hMutex = CreateMutex( NULL, FALSE, NULL);

	WaitForSingleObject(hMutex, INFINITE);

static void done_initializing()



-----Original Message-----
From: Adrian Dick []
Sent: Monday, April 11, 2005 6:58 AM
To: Apache AXIS C Developers List
Subject: RE: Possbile bug in Axis.cpp on Win32 (XP, VC7.1)


As you comment below, the code in CVS does not exactly match the original
patch provided, due to the apparent differences in API between MS VC++

>From <MS VC++ 6.0 install>\Include\WINBASE.H
   InterlockedCompareExchange (
       PVOID *Destination,
       PVOID Exchange,
       PVOID Comperand

I initially tried using the version provided in the original patch (which
matches your suggested usage), but received compilation errors, basically
the reverse of those you are seeing.

Adrian Dick (

"Rob Lievaart" <> wrote on 11/04/2005 14:22:45:

> Hi Adrian,
> There are two things here, one is the signature of the function,
> and one is the actual parameter values.
> I can imagine something about the different compiler versions
> being more or less picky about signatures which types can and cannot be
> converted to each other, but I find it hard to believe  that
> Microsoft changed the actual system call.  According to the
> documentation parameter 2 and 3 need to be the values to be
> compared and exchanged, but instead of these values, _pointers_
> to these values are passed.
> As far as I can see, the current function passes two pointers instead
> of a '1' and a '0' for exchange and comparand.  The result is that
> g_uModuleInitializing is never equal to the comparand, so it is never
> actually set to any other value then 0. The function will return the
> initial 0,  so it will continue thinking it has the lock, but without
> actually setting the flag.
> I guess, the chance of multiple threads actually trying to initialize at
> the same time, is pretty low, so it will seem to work, but it does not
> provide any protection this way.
> > This appears to be a problem between different versions of MS VC++.
> >
> > I applied this fix, as provided in
> >
> Ehh, the patch you refer to in this issue shows the following code:
> + static void start_initializing()
> + {
> +     while (InterlockedCompareExchange(&g_uModuleInitializing, 1, 0));
> + }
> However the version in CVS has:
> static void start_initializing()
> {
>     long exchange  = 1;
>     long comperand = 0;
>     while (InterlockedCompareExchange(((void **)&g_uModuleInitializing),
> void*)&exchange, (void *) &comperand)));
> }
> Apart from the void * casts, the first one passes the values 1 and 0,
> and the
> second one passes the address of 2 variables that contain 1 and zero.
> The version in CVS definately does not match de documentation from
> Microsoft.
> I currently don't have VC6.0 installed to check out, what the problem
> is. But my
> guess is that the version in the original patch is correct.
> (I used the original version on VC7.1 and it compiles)
> Do you remember what problems VC6.0 had with the original version?
> Kind regards,
> Rob.

View raw message