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, 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.

cheers

andrew