Messages in this thread | | | Subject | Re: [PATCH] Use NULL instead of integer 0 in security/selinux/ | From | (Eric W. Biederman) | Date | 10 Jul 2004 03:39:13 -0600 |
| |
Linus Torvalds <torvalds@osdl.org> writes:
> On Fri, 9 Jul 2004, Eric W. Biederman wrote: > > > > Does this mean constructs like: > > ``if (pointer)'' and ``if (!pointer)'' are also outlawed. > > Of course not. > > Why should they be?
Only because the definition of the semantics of ``if'' is in terms of comparisons with ``0'', and I am familiar enough with the C programming language that, that is how I read it. It is still the case that because the comparison happens in pointer context the ``0'' referred to is the null pointer constant.
For some of us who are extremely familiar with C your argument is confusing. You make statements that sound like they are about the definition of the C programming language when in fact they are criticism of a given C programming style.
Since I am already making distinctions 0 as the integer value and 0 as the pointer constant when 0 is implicitly introduced. It is really not confusing to me in the case of manifest constants.
> What's considered bad form is: > - assignments in boolean context (because of the confusion of "=" and > "==") > - thinking the constant "0" is a pointer.
I would agree that using the constant "0" in a pointer context when a more explicit NULL is bad form. But "0" is the one legal way in C to write the NULL pointer constant.
> There's no reason why "if (!ptr)" would be wrong. That has zero confusion > about 0 vs NULL.
For me it has exactly the same level of confusion as the cases that are being fixed has. I have to know the type to know if it is testing against the NULL pointer constant or if it is testing against the integer value zero.
> The confusion about "0" is that in traditional C it means two things: it > can either be an integer (the common case) or it can sometimes be a > pointer. That kind of semantic confusion is bad.
Either that or it can be called greater expressive power though fewer concepts.
I like the fact this allows cases like ``if (!ptr)'' and friends. > But it has nothing to do with the _value_ zero, or testing pointers for > being non-NULL. The value zero is not about semantic confusion, it's just > a bit pattern. And testing pointers is not ambiguous: when you test a > pointer, it's _un_ambigiously checking that pointer for NULL.
see above.
> Problems arise when there is room for confusion, and that's when the > compiler should (and does) warn. If something is unambiguous, it's not > bad.
The compiler is compiling the correct code so the code is clearly not ambiguous. But since types are not always obvious to a person staring at the code using the more explicit form of the constant i.e. NULL or '\0' instead of 0 adds useful redundancy.
Hopefully that explains why I objected to the way you can out against using ``0'' as the null pointer constant.
Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |