Re: mingw check hung

Magnus Hagander wrote:
> Andrew Dunstan wrote:
>   
>> Magnus Hagander wrote:
>>     
>>>> Specifically, it's the SetEnvironmentVariable() call from
>>>> pgwin32_putenv() called from pgwin32_unsetenv(). When this is disabled
>>>> things work just fine.
>>>>     
>>>>         
>>> That's strange :( What arguments are it sent to the function? Since this
>>> is an API function, it really shouldn't behave differently between mingw
>>> and msvc, so it must be something that goes wrong with the arguments.
>>>
>>> Also, Tom mentioned earlier that we may be including *two* replacements
>>> for unsetenv(), which could be what's causing the problem. Can you check
>>> if that is happening and try to disable the one in port/unsetenv.c and
>>> see if that changes things?
>>>
>>>
>>>   
>>>       
>> I've already ruled out that hypothesis by forcing the call direct to
>> pgwin32_unsetenv() instead of relying on the macro, in initdb.c.
>>
>> There are only two such calls in initdb.c: the arguments are "LC_ALL"
>> and "PGCLIENTENCODING".
>>
>> I wonder if this version of SetEnvironmentVariable is sufficiently dumb
>> that it fails badly if given a NULL second argument for a value that is
>> not in fact in the environment (as I would normally expect of these on
>> Windows)?
>>     
>
> But that should be a win32 API call. It's not a runtime call. So it
> should be identical between mingw and msvc!
>
> Try removing the code that sets it to NULL if it's empty string. Having
> it as empty string made it fail on MSVC, and the API documentation says
> it should be NULL, but maybe mingw is somehow intercepting the call and
> breaking it...
>
>
>   

Mingw is just passing the call on.

You're right. When I comment out the NULL assignment, it all works.

MSDN says this (<http://msdn.microsoft.com/en-us/library/z46c489x.aspx>):
   If the value parameter is not empty and the environment variable   named by the variable parameter does not exist,
theenvironment   variable is created and assigned the contents of value. Solely for   purposes of this operation, value
isconsidered empty if it is a   null reference (Nothing in Visual Basic), contains a zero-length   string, or contains
aninitial hexadecimal zero character (0x00).
 
   If variable contains a non-initial hexadecimal zero character, the   characters before the zero character are
consideredthe environment   variable name and all subsequent characters are ignored.
 
   If value contains a non-initial hexadecimal zero character, the   characters before the zero character are assigned
tothe environment   variable and all subsequent characters are ignored.
 
   If value is empty and the environment variable named by variable   exists, the environment variable is deleted. If
variabledoes not   exist, no error occurs even though the operation cannot be performed.
 


So it looks like we could remove that NULL assignment happily and expect 
the right thing to be done.

cheers

andrew