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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
