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

Re: Problem with PQexecPrepared

From: "Jeroen T(dot) Vermeulen" <jtv(at)xs4all(dot)nl>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: David Stanaway <david(at)stanaway(dot)net>,pgsql-interfaces(at)postgresql(dot)org
Subject: Re: Problem with PQexecPrepared
Date: 2004-06-10 14:56:29
Message-ID: 20040610145629.GC27490@xs4all.nl (view raw or flat)
Thread:
Lists: pgsql-interfaces
On Thu, Jun 10, 2004 at 01:34:12AM -0400, Tom Lane wrote:
> David Stanaway <david(at)stanaway(dot)net> writes:
 
> > If the prototype had been for const char** I would not have needed to
> > change anything, the API author I guess is being thorough.
> 
> The author was me, and I didn't think I was creating any problems by
> const-ifying the declaration :-(.  Jerome, are you sure this isn't
> a compiler glitch?  I really have a problem with the notion that a
> library routine can over-constify its input declarations...

I don't think this is a compiler glitch.  The way the C type system works
(well, in its current form anyway) was thought out pretty well and I
wouldn't bet on gcc getting it wrong.  You can't hoist const qualifiers
across pointers, because the constness of a pointer is a very different
thing from the constness of whatever it points to.  The former can be
converted implicitly in this case, but the latter cannot because it's at
least as fundamental a property of the pointer's type as the "char" is.
It's hidden away a level too deep to meddle with, if you will.

This particular usage (converting "TYPE **" to "const TYPE *const *")
might probably have been allowed as a special case, but such exceptions
make for convoluted type systems and perhaps even paradoxes.  Compilers
used to be full of such ad-hockery IIRC, and the standardization process
got rid of it so that all compilers could implement a single, consistent
language.  And as the poem goes, there was dancing in the dock; and a
day of celebration was commanded in Bangkok.

I wouldn't say that the library routine over-constified the parameter
either.  Think about it: what other type could you possibly give it?
It's a char const *const * by nature, and there's no point in denying it.
Whether this problem turns up in practice probably depends a lot on one's
programming style:

	const char **array = malloc(strings * sizeof(*array));
	for (n=0; n<strings; ++n)
	{
		char buf[100];
		char *mystring;
		int len;

		len = get_a_string(buf, 100);
		array[n] = mystring = malloc(len);
		strcpy(mystring, buf);
	}
	pass_parameter(array);

Note how the strings are generated at runtime, but the array only sees
const char *'s.  The array itself may be nonconst, but that is the one
implicit conversion that is allowed while passing it as a parameter.


Jeroen


In response to

pgsql-interfaces by date

Next:From: Jeroen T. VermeulenDate: 2004-06-10 15:04:12
Subject: Re: libpq 7.4 and binary cursor
Previous:From: Stephane RaimbaultDate: 2004-06-10 14:30:27
Subject: libpq 7.4 and binary cursor

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