FW: Postgresql on win32 - Mailing list pgsql-hackers

Seems this one got lost along the way somewhere. At least, I didn't get it
back... Trying a resend.

//Magnus

>  -----Original Message-----
> From:     Magnus Hagander
> Sent:    den 20 januari 2001 14:29
> To:    'pgsql-hackers@postgresql.org'
> Subject:    Postgresql on win32
>
> Hello!
>
> Here is a patch to make the current snapshot compile on Win32
> (native, libpq and psql) again. Changes are:
> 1) psql requires the includes of "io.h" and "fcntl.h" in
> command.c in order to make a call to open() work (io.h for
> _open(), fcntl.h for the O_xxx)
> 2) PG_VERSION is no longer defined in version.h[.in], but in
> configure.in. Since we don't do configure on native win32, we
> need to put it in config.h.win32 :-(
> 3) Added define of SYSCONFDIR to config.h.win32 - libpq won't
> compile without it. This functionality is *NOT* tested - it's
> just defined as "" for now. May work, may not.
> 4) DEF_PGPORT renamed to DEF_PGPORT_STR
>
> I have done the "basic tests" on it - it connects to a
> database, and I can run queries. Haven't tested any of the
> fancier functions (yet).
>
> However, I stepped on a much bigger problem when fixing psql
> to work. It no longer works when linked against the .DLL
> version of libpq (which the Makefile does for it). I have
> left it linked against this version anyway, pending the
> comments I get on this mail :-)
> The problem is that there are strings being allocated from
> libpq.dll using PQExpBuffers (for example, initPQExpBuffer()
> on line 92 of input.c). These are being allocated using the
> malloc function used by libpq.dll. This function *may* be
> different from the malloc function used by psql.exe - only
> the resulting pointer must be valid. And with the default
> linking methods, it *WILL* be different. Later, psql.exe
> tries to free() this string, at which point it crashes
> because the free() function can't find the allocated block
> (it's on the allocated blocks list used by the runtime lib of
> libpq.dll).
>
> Shouldn't the right thing to do be to have psql call
> termPQExpBuffer() on the data instead? As it is now,
> gets_fromFile() will just return the pointer received from
> the PQExpBuffer.data (this may well be present at several
> places - this is the one I was bitten by so far). Isn't that
> kind of "accessing the internals of the PQExpBuffer
> structure" wrong? Instead, perhaps it shuold make a copy of
> the string, adn then termPQExpBuffer() it? In that case, the
> string will have been allocated from within the same library
> as the free() is called.
>
> I can get it to work just fine by doing this - changing from
> (around line 100 of input.c):
>                 if (buffer.data[buffer.len - 1] == '\n')
>                 {
>                         buffer.data[buffer.len - 1] = '\0';
>                         return buffer.data;
>                 }
> to
>         if (buffer.data[buffer.len - 1] == '\n')
>         {
>             char *tmps;
>             buffer.data[buffer.len - 1] = '\0';
>             tmps = strdup(buffer.data);
>             termPQExpBuffer(&buffer);
>             return tmps;
>         }
>
> and the same a bit further down in the same function.
>
> But, as I said above, this may be at more places in the code?
> Perhaps someone more familiar to it could comment on that?
>
>
> What do you think shuld be done about this? Personally, I go
> by the "If you allocate a piece of memory using an interface,
> use the same interface to free it", but the question is how
> to make it work :-)
>
>
> Also, AFAIK this only affects psql.exe, so the changes made
> to the libpq files by this patch are required no matter how
> the other issue is handled.
>
> Regards,
>  Magnus
>
>
>  <<pgsql-win32.patch>>