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: Frediano Ziglio <freddy77 AT gmail.com>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] [PATCH] useless CHECK_NULP in dblib.c:tdsdbopen()
  • Date: Mon, 23 Mar 2009 12:09:10 +0100

2009/3/21 James K. Lowden <jklowden AT freetds.org>:
> Craig A. Berry wrote:
>> >>       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.
>
> Ah!  I didn't even notice that.  Friggin macros!
>
> Keep 'em coming, Craig.
>

I think that a

DBPROCESS *dbproc = NULL;

is better... so we check parameter and in case server is NULL we call
dbperror with proper DBPROCESS (which is NULL).
I don't understand why gcc don't detect this...

freddy77




Archive powered by MHonArc 2.6.24.

Top of Page