4 ms·
> caused by the difference between NULL and 0 in a C pointer What? In C pointers, `NULL` is equivalent to `(void *) 0`, is it not? Were you compiling in a deb
by jsd1982 10y ago
> caused by the difference between NULL and 0 in a C pointer
What? In C pointers, `NULL` is equivalent to `(void *) 0`, is it not?
Were you compiling in a debug mode where your compiler reinterprets NULL as a bad pointer value other than literal 0?
- beat 10y ago99% of the time, yes. But not always. Technical detail in this case... we were creating rows with a BLOB column in Sybase. If you passed in NULL, Sybase did not allocate space for the blob. But if you passed in 0, it allocated 8k. We had been storing data in the blobs, in the dozens-to-hundreds of k size range. Sometimes we didn't store data in a row, but mostly we did. The data got moved to the filesystem, resulting in a huge performance boost. Because we pulled the blobs out of Sybase, we massively downsized the databases, to about 10% of their original size - which was still a few times larger than what was needed for an entire production season (about three months of data). Now, this is where I badmouth co-workers... I had argued strenuously for removing that BLOB column completely, as it smelled wrong to me to leave it. But the tech lead, a rather nervous man who was always afraid of things breaking unexpectedly, insisted we leave it there, because removing it might break something else (I wouldn't be introduced to the Lava Flow Antipattern until years later...) (also, welcome to the world of coding in C without testing frameworks). The code worked fine in testing. Beautifully. But testing couldn't even fill 1% of a database. The wasted space from the BLOB allocation was invisible... until production started, and rows were 100 times larger than they should have been on our biggest table. Oops. Thankfully, Sybase has excellent documentation. The gleaming row of carefully indexed, spiral-bound manuals helped me find detailed example code quicky, which got me to the latent bug. We'd never noticed the 8k being allocated for empty blobs before because they were swamped by the size of the actual blobs.
- jsd1982 10y ago> 99% of the time, yes. But not always. Hmmm, no, sorry. `NULL` is #defined as `((void )0)`. There is no 99% or other probability involved. Sorry to be so pedantic as it's kind of an aside to the discussion at hand. I thought perhaps you knew something about NULL in C that I never knew and was eager to be enlightened. I think you're conflating C pointer `NULL` with the database concept of `NULL` which is not necessarily represented the same way when interfacing with database client APIs. There's probably a detail you glossed over whereby you're passing 0 vs NULL via separate method calls to the database client API. The distinction cannot be due to literal `NULL` vs. literal `0` purely in C programming terms. The limitations of C require that database-NULL be represented differently from integral values in terms of data structures. Even if you do pass `NULL` and `0` in the exact same parameter location to the exact same method name, you'd have to ignore a warning about the implicit type conversion from `void ` to `int` and still the semantics do not change and you have no runtime bug as you described.