Skip site navigation (1) Skip section navigation (2)

pgsql/src bin/psql/command.c include/config.h. ...

From: Bruce Momjian - CVS <momjian(at)hub(dot)org>
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql/src bin/psql/command.c include/config.h. ...
Date: 2001-01-24 03:42:38
Message-ID: 200101240342.f0O3gcG04762@hub.org (view raw or flat)
Thread:
Lists: pgsql-committers
CVSROOT:	/home/projects/pgsql/cvsroot
Module name:	pgsql
Changes by:	momjian(at)hub(dot)org	01/01/23 22:42:38

Modified files:
	src/bin/psql   : command.c 
	src/include    : config.h.win32 

Log message:
	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):
	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
	this patch are required no matter how the other issue is handled.
	
	Regards,
	Magnus


pgsql-committers by date

Next:From: Bruce Momjian - CVSDate: 2001-01-24 03:46:16
Subject: pgsql/contrib/pgcrypto Makefile README.pgcrypt ...
Previous:From: Bruce Momjian - CVSDate: 2001-01-24 03:40:35
Subject: pgsql/ ontrib/oid2name/Makefile ontrib/oid2nam ...

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group