Skip to Content.
Sympa Menu

freetds - Re: [freetds] [PATCH] useless CHECK_NULP in dblib.c:tdsdbopen()

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Craig A. Berry" <craigberry AT mac.com>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] [PATCH] useless CHECK_NULP in dblib.c:tdsdbopen()
  • Date: Sat, 21 Mar 2009 11:10:49 -0500


On Mar 20, 2009, at 8:07 PM, Craig A. Berry wrote:


On Mar 20, 2009, at 7:27 PM, James K. Lowden wrote:

Craig A. Berry wrote:
The CHECK_NULP statement removed by the attached patch is not
actually
checking anything except whether random data from the stack is non-
zero.

One of us is confused, Craig. How about the attached instead?

The macro:

#define CHECK_NULP(x, func, param_num, ret) if (!(x))
{ dbperror(dbproc,
#SYBENULP, 0, func, (int) param_num); return ret; }

The function call:

tdsdbopen(LOGINREC * login, const char *server, int msdblib)

The check:

- CHECK_NULP(server, "dbopen", 2, NULL);

expands to:

if (!(server)) { dbperror(dbproc, 20176, 0, "dbopen", (int) 2);
return (void *)0; };

The check isn't against "random data from the stack"; it's against the
server argument.

I really wasn't clear (and hadn't looked at the macro long enough to
understand it). It's dbproc, not server, that has been "fetched but
not initialized". I'll try to actually think before replying further.

Your patch looks good to me, compiles fine here, and I'm now testing with it. You were right that I was confused in saying that the uninitialized data is what we were checking (server), when in fact it's what we were using to report the error (dbproc). This was rather dangerous because dbperror dereferences dbproc and could either get garbage or segfault when given a bad pointer. Had we initialized dbproc to NULL, that would've been ok as dbperror handles that case.

________________________________________
Craig A. Berry
mailto:craigberry AT mac.com

"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser





Archive powered by MHonArc 2.6.24.

Top of Page