Re: mingw check hung - Mailing list pgsql-hackers

Andrew Dunstan wrote:
> 
> 
> 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, the environment
>    variable is created and assigned the contents of value. Solely for
>    purposes of this operation, value is considered empty if it is a
>    null reference (Nothing in Visual Basic), contains a zero-length
>    string, or contains an initial hexadecimal zero character (0x00).
> 
>    If variable contains a non-initial hexadecimal zero character, the
>    characters before the zero character are considered the 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 to the 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 variable does 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.

I'm doing training all day today, but I can hopefully look at it this
weekend if you haven't already. However, I do recall *adding* that part
specifically for MSVC compatibility - I got a crash without it. Perhaps
we need to #ifdef it on mingw, but I'd like to understand *why*, since
it's just an API call...

Are we *sure*, btw, that this is actually a mingw issue, and not
something else in the environment? Could you try a MSVC compiled binary
on the same machine?

//Magnus