Обсуждение: libpq++ doc error?

Поиск
Список
Период
Сортировка

libpq++ doc error?

От
Vince Vielhaber
Дата:
I'm beginning to think I created my own error!  After looking over the
sources I'm thinking I did the cut-n-paste from the same source but a
different function (if that makes sense).

I just sent patches for libpq++ to return an int (I'll also submit changes
to the sgml docs) and return a -1 if PQcmdTuples() returns a NULL pointer.
I just haven't been able to convince it to return a NULL.

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH   email: vev@michvhf.com   flame-mail: /dev/null # include <std/disclaimers.h>       Have you
seenhttp://www.pop4.net?       Online Campground Directory    http://www.camping-usa.com      Online Giftshop
Superstore   http://www.cloudninegifts.com
 
==========================================================================




Re: [HACKERS] libpq++ doc error?

От
Tom Lane
Дата:
Vince Vielhaber <vev@michvhf.com> writes:
> I just sent patches for libpq++ to return an int (I'll also submit changes
> to the sgml docs) and return a -1 if PQcmdTuples() returns a NULL pointer.
> I just haven't been able to convince it to return a NULL.

It won't.  If you look at the source, it's quite clear that it never
returns NULL.  It will return an empty string ("") if it notices a
problem.

Also, if you wanted to be really paranoid you'd check that what it
returns actually looks like it is a number, because PQcmdTuples doesn't
check that there is a number in the right spot in the command status
returned by the backend.

These two points together are why I suggested testing for an initial
digit...
        regards, tom lane


Re: [HACKERS] libpq++ doc error?

От
Vince Vielhaber
Дата:
On Wed, 6 Oct 1999, Tom Lane wrote:

> Vince Vielhaber <vev@michvhf.com> writes:
> > I just sent patches for libpq++ to return an int (I'll also submit changes
> > to the sgml docs) and return a -1 if PQcmdTuples() returns a NULL pointer.
> > I just haven't been able to convince it to return a NULL.
> 
> It won't.  If you look at the source, it's quite clear that it never
> returns NULL.  It will return an empty string ("") if it notices a
> problem.
> 
> Also, if you wanted to be really paranoid you'd check that what it
> returns actually looks like it is a number, because PQcmdTuples doesn't
> check that there is a number in the right spot in the command status
> returned by the backend.
> 
> These two points together are why I suggested testing for an initial
> digit...

Ok, I'm looking for an empty string now and that will return a -1.  The
other return possibilities *should* be handled correctly by atoi() since
it doesn't care if there's any leading blanks/spaces, as long as it's
not a non-numeric non-space character.  If it's going to get that crazy
with differing possibilities then we'd be further ahead to fix it in 
either the backend or in libpq (by adding a new function and letting
this one fade away).   Is there an atoi() out there that would not return
a 123 if passed the string "      123    " ??  It does the right thing in
hpux8 and in FreeBSD 3.2.

Vince.
-- 
==========================================================================
Vince Vielhaber -- KA8CSH   email: vev@michvhf.com   flame-mail: /dev/null # include <std/disclaimers.h>       Have you
seenhttp://www.pop4.net?       Online Campground Directory    http://www.camping-usa.com      Online Giftshop
Superstore   http://www.cloudninegifts.com
 
==========================================================================