FreeTDS Development Group

["Craig A. Berry" <craigberry AT mac.com>]

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