Neil Conway <[EMAIL PROTECTED]> writes:
> I think the percentage of deployments that enable assertions (which
> causes a runtime performance hit) but NOT debugging info (which does
> not) is pretty small.
How big a penalty is it? If it's small, or if it could be made small by making
a few assertions require an extra extra-assertions option, then perhaps it
would make more sense to ship with it enabled?
I know the number of times I received ORA-600 (oracle's way of spelling
"assertion failed") I sure wouldn't have wanted the database to continue
processing based on invalid data.
> ISTM that checking for non-NULL pointers is pretty pointless: just
> because a pointer happens to be non-NULL doesn't mean it is any more
> valid, and dereferencing a NULL pointer is easy enough to track down in
> any case.
That would depend a lot on the scenario. Often code doesn't crash right at
that point but stores the data causes a crash elsewhere. Or perhaps even
causes corrupted data on disk.
Probably the most useful side-effect of checking for null pointers is that
programmers get in the habit of checking all their arguments...
--
greg
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
