From: Jeroen T. Vermeulen <jtv@xs4all.nl>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: David Stanaway <david@stanaway.net>
Cc: pgsql-interfaces@postgresql.org
Subject: Re: Problem with PQexecPrepared
Date: Thu, 10 Jun 2004 16:56:29 +0200
Message-ID: <20040610145629.GC27490@xs4all.nl> (raw)
In-Reply-To: <20133.1086845652@sss.pgh.pa.us>
References: <1086817452.10544.5.camel@dmxnocws13.dialmex.net>
<20040609222114.GI91662@xs4all.nl>
<1086820694.10544.14.camel@dmxnocws13.dialmex.net>
<20133.1086845652@sss.pgh.pa.us>
On Thu, Jun 10, 2004 at 01:34:12AM -0400, Tom Lane wrote:
> David Stanaway <david@stanaway.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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-interfaces@postgresql.org
Cc: jtv@xs4all.nl, tgl@sss.pgh.pa.us, david@stanaway.net
Subject: Re: Problem with PQexecPrepared
In-Reply-To: <20040610145629.GC27490@xs4all.nl>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox