Re: Problem with PQexecPrepared
От | Jeroen T. Vermeulen |
---|---|
Тема | Re: Problem with PQexecPrepared |
Дата | |
Msg-id | 20040610145629.GC27490@xs4all.nl обсуждение исходный текст |
Ответ на | Re: Problem with PQexecPrepared (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-interfaces |
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
В списке pgsql-interfaces по дате отправления: