<snip>
=> According to the language definition, a constant 0 in a pointer
=> context is converted into a null pointer at compile time. That
=> is, in an initialization, assignment, or comparison when one
=> side is a variable or expression of pointer type, the compiler
=> can tell that a constant 0 on the other side requests a null
=> pointer, and generate the correctly-typed null pointer value.
</snip>
Hi Ravi,
I totally agree with this statement of the C-faq.
=> and from 5.3:
=>
=> Substituting the trivial pointer expression "p" for "expr", we
=> have
=> if(p) is equivalent to if(p != 0)
=>
=> and this is a comparison context, so the compiler can tell that
=> the (implicit) 0 is actually a null pointer constant, and use
=> the correct null pointer value. There is no trickery involved
=> here; compilers do work this way, and generate identical code
=> for both constructs. The internal representation of a null
=> pointer does *not* matter.
I also agree that the internal representation of the null-pointer does not
matter becoz we are concentrating on
1. comparision - example
if (p != 0) - here 0 is converted implicitly to a null pointer and then the
comparision is performed. No problems with this. Here, we are not trying to
access the value of the null pointer. I mean we are trying to do something like
int *p = 0;
printf("%d", (unsigned long)p);
2. assignment and initialization are self explanatory.
I still state one thing, in any of the cases stated above we are not using the
*value* of null-pointer (by this I am referring to internal representation of
the null pointer) as for any computation or any other purpose. But in the
statement under question, and as I had explained in the second mail of mine
(wherein I showed how I think that the compiler will parse the expression), we
are using the value of the null-pointer for computing the offset.
=> 5.10: But wouldn't it be better to use NULL (rather than 0), in case
=> the value of NULL changes, perhaps on a machine with nonzero
=> internal null pointers?
=>
=> A: No. (Using NULL may be preferable, but not for this reason.)
=> Although symbolic constants are often used in place of numbers
=> because the numbers might change, this is *not* the reason that
=> NULL is used in place of 0. Once again, the language guarantees
=> that source-code 0's (in pointer contexts) generate null
=> pointers. NULL is used only as a stylistic convention. See
=> questions 5.5 and 9.2.
I suppose we are not at all talking about NULL. The mail by Ed Vance completely
explains the thing that we are not worryin about NULL. NULL is pre-processor
macro,
so the compiler does not know anything about #define NULL.
for example , if I say that
#define NULL (0xff)
Then the compiler just know this 0xff. It does not know about NULL. So , can we
concentrate on the real question withoout worrying about NULL. Please forget
NULL. I just want clarification about null-pointer. The only two solution I can
think of now are :
1. ((struct module*)0L)->persist_start
The compiler is smart enough considering that it computes the expression like :
(struct module *)0L is converted to (null-pointer of struct module type).
Now, the compiler understands that the following construct "(null-pointer of
struct module type)->persist_start" is an expression meant for calculating the
offset of of persist_start in this structure, and hence puts that value in place
of this expression.
2. Else ((struct module*)0L)->persist_start is not portable.
=> Also, of all the architectures mentioned in the FAQ that use non-zero
=> values for null pointers, how many have Linux ports??
I agree with it too. But I think this is not the point in question. I am just
querying whether the above expression results in a portable code or not.
Suppose, I am going to port Linux to all those platforms tommorrow. :) So do i
need to change this code fragment or not ? :)
Thanks for all this about sys_init_module().
-neeraj
--
Kernelnewbies: Help each other learn about the Linux kernel.
Archive: http://mail.nl.linux.org/kernelnewbies/
FAQ: http://kernelnewbies.org/faq/
