Style question: Should one check for NULL pointers?
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 9 lines · Alan Stern
On the other hand, what if on rare occasions the pointer actually is NULL, even though it's not supposed to be? This can only be the result of an error somewhere else in the kernel (such as incorrect locking during a data structure update). Detecting the NULL pointer and returning an error code will hide the existence of the true underlying error. But if the check _isn't_ made, then as soon as the pointer is derefenced there will be a nice big segfault. This will immediately alert people to the existence of a problem, something they otherwise might not be aware of at all.
The problem is IMHO code where some pretty fragile things are handled, especially file systems. I'd say: DO the paranoia checks if some fragile things are involved like key structures of the file system that can take _permanent_ damage. If you check for a NULL pointer you still have the chance to properly leave the system in a consistent state and no user will be happy if his filesystem goes messy just because someone saved a check to have nicer code, even if the original of the NULL pointer wasn't his fault, even if it's a developing version. So if the check isn't a total performace disaster, do it whenever permanent damage could occur. On other sections where, let's say just a user memory allocation would crash, checks could be ommitted, because it isn't that fatal and leaves no permanent destruction.
Just my opinion :)
TriPhoenix
Followup to: <[email protected]> By author: Dennis Bliefernicht <[email protected]> In newsgroup: linux.dev.kernel
Quoted 12 lines
The problem is IMHO code where some pretty fragile things are handled, especially file systems. I'd say: DO the paranoia checks if some fragile things are involved like key structures of the file system that can take _permanent_ damage. If you check for a NULL pointer you still have the chance to properly leave the system in a consistent state and no user will be happy if his filesystem goes messy just because someone saved a check to have nicer code, even if the original of the NULL pointer wasn't his fault, even if it's a developing version. So if the check isn't a total performace disaster, do it whenever permanent damage could occur.
Actually, you have it somewhat backwards.
In most cases, checking for NULL pointers (and returning an error whatnot) is actually *more* likely to cause permanent damage than having the kernel bomb out. At least with the kernel bombing out you won't keep grinding on a filesystem for which your kernel datastructures are bad. This is *IMPORTANT*.
-hpa
Signature · 4 lines
<[email protected]> at work, <[email protected]> in private! If you send me mail in HTML format I will assume it's spam. "Unix gives you enough rope to shoot yourself in the foot." Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64
Quoted 16 lines · H. Peter Anvin
Followup to: <[email protected]> By author: Dennis Bliefernicht <[email protected]> In newsgroup: linux.dev.kernelQuoted 12 lines
The problem is IMHO code where some pretty fragile things are handled, especially file systems. I'd say: DO the paranoia checks if some fragile things are involved like key structures of the file system that can take _permanent_ damage. If you check for a NULL pointer you still have the chance to properly leave the system in a consistent state and no user will be happy if his filesystem goes messy just because someone saved a check to have nicer code, even if the original of the NULL pointer wasn't his fault, even if it's a developing version. So if the check isn't a total performace disaster, do it whenever permanent damage could occur.
Quoted 7 lines
Actually, you have it somewhat backwards.
In most cases, checking for NULL pointers (and returning an error whatnot) is actually *more* likely to cause permanent damage than having the kernel bomb out. At least with the kernel bombing out you won't keep grinding on a filesystem for which your kernel datastructures are bad. This is *IMPORTANT*.
In BK, we have a READ_ONLY flag on each revision history file. Whenever we get into a state where we don't understand what's going on, we set that flag. That flag is checked in the code path which writes the file and it will simply refuse the write the file if the flag is set.
Seems like the same idea would work here. I can imagine a lot of use for a file system which remounts itself as read only the second it sees a problem it can't handle. At least you can poke around and try and figure out what is going on.
Signature · 2 lines
--- Larry McVoy lm at bitmover.com http://www.bitmover.com/lm