Re: CVS update: php3/functions

tommay <php-dev@lists.php.net> writes: > Date: Tuesday November 3, 1998 @ 20:23 > Author: tommay > > Update of /repository/php3/functions > In directory asf:/u2/tmp/cvs-serv5584 > > Modified Files: > sybase-ct.c > Log Message: > php3_sybct_query(): better error checking, be sure to read all the results, > split the result fetch out into its own function for readability. Oh yeah. I also made this change which may be a mistake. After fetching a row, we loop over the fields and check for null values: for (j=0; j<num_fields; j++) { if (indicators[j] && (!tmp_buffer[j] || lengths[j]==0)) { /* null value */ var_reset(&result->data[i][j]); } else { result->data[i][j].value.str.len = lengths[j]-1; /* we don't need the NULL in the length */ result->data[i][j].value.str.val = estrndup(tmp_buffer[j],lengths[j]); result->data[i][j].type = IS_STRING; } } I changed the null value test to if (indicators[j] == -1) { /* null value */ which seemed sensible to me. But, in checking through the CVS log I came across the following, so obviously somebody has thought about this before: revision 1.18 date: 1997/12/07 13:48:43; author: zeev; state: Exp; lines: +3 -3 Sybase/CT fix for NULL fields for (j=0; j<num_fields; j++) { - if (indicators[j]) { /* null value */ + if (indicators[j] && (!tmp_buffer[j] || lengths[j]==0)) { /* null value */ var_reset(&result->data[i][j]); } else { result->data[i][j].strlen = lengths[j]-1; /* we don't need the NULL in the length */ What's really going on here? The documentation for indicators[] says: Indicator Value Meaning -1 The fetched data was NULL. In this case, no data is copied to *buffer. 0 The fetch was successful. > 0 The actual length of the server data, if the fetch resulted in truncation. And lengths[] is the number of chars written to *buffer. Now, tmp_buffer[j] is a pointer to some memory we have emalloc()ed and it is never NULL, so testing it is bogus. And in practice, we should never get indicator[j] > 0 because our values should never be truncated. If they are, it is a bug in sybase-ct.c. So the only values we're really concerned about are 0 and -1. However, today I fixed some cases where the value could have been truncated, which would have resulted in indicator[j] > 0 giving a false positive on the test for a null vlaue. Perhaps the extra test was a work around for this bug: "oh, you say it's null yet you wrote a value to *buffer and set length[j]? then it's not really null!". In that case, my new test is correct. But if there's some reason for the test I replaced could somebody try to remember what it is? Tom. -- PHP Development Mailing List http://www.php.net/ To unsubscribe send an empty message to php-dev-unsubscribe@lists.php.net For help: php-dev-help@lists.php.net