[freetds] [PATCH] useless CHECK_NULP in dblib.c:tdsdbopen()
Craig A. Berry
craigberry at mac.com
Sat Mar 21 12:10:49 EDT 2009
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
More information about the FreeTDS
mailing list