Re: mingw check hung

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