does a cast become a null pointer ?

[MC]

Hi
If I have a pointer to a some structure
say for example payroll_ptr where
struct payroll { ... } has some members and
if i use a function argument as

int function_process ( (payroll_ptr) 0 , ..)
does the first argument become a NULL
pointer ?

Thanks
Mahesh

[foo bar]

"MC" <ma*********@yahoo.com> wrote in message
news:bi**********@zcars0v6.ca.nortel.com...

Hi
If I have a pointer to a some structure
say for example payroll_ptr where
struct payroll { ... } has some members and
if i use a function argument as

int function_process ( (payroll_ptr) 0 , ..)
does the first argument become a NULL
pointer ?

Thanks
Mahesh

Yes, the first parameter will contain value 0 (null pointer). Pointers that
contain the value of 0, are all NULL pointers.

All pointers can assign and test for value 0 (but to not run into explicit
casting problems, the NULL macro has the type pointer-to-void).

[Barry Schwarz]

On Wed, 27 Aug 2003 12:33:58 -0700, "MC" <ma*********@yahoo.com>
wrote:

Hi
If I have a pointer to a some structure
say for example payroll_ptr where
struct payroll { ... } has some members and
if i use a function argument as

int function_process ( (payroll_ptr) 0 , ..)
does the first argument become a NULL
pointer ?

Only if payroll_ptr is the type (via a typedef) of the pointer and not
the pointer itself. Otherwise you have a syntax error.

If their is a prototype in scope for the function then the cast is
completely superfluous.

If you want to pass a null pointer constant to a function, it would
make the code much easier to read if you simply used NULL.
<<Remove the del for email>>

[Samuel Barber]

"MC" <ma*********@yahoo.com> wrote in message news:<bi**********@zcars0v6.ca.nortel.com>...

If I have a pointer to a some structure
say for example payroll_ptr where
struct payroll { ... } has some members and
if i use a function argument as

int function_process ( (payroll_ptr) 0 , ..)
does the first argument become a NULL
pointer ?

It's better C to not have the cast. Modern C makes a clear distinction
between integers and pointers. (char*)0 is an integer converted to a
pointer; the compiler treats it the same as (char*)1. So it's not a
null pointer; it's a nulled pointer. The practical difference is nil,
but that doesn't nullify the language difference.

Sam

[pete]

Samuel Barber wrote:

(char*)0 is an integer converted to a
pointer; the compiler treats it the same as (char*)1.
No, it doesn't treat them the same by any means.
So it's not a null pointer; it's a nulled pointer.
0 is a null pointer constant.
(char*)0, is a null pointer.
(char*)1, is the integer number one, cast to type pointer to char.
The practical difference is nil,
but that doesn't nullify the language difference.

"null pointer" is a technical term in C.
"nulled pointer" is a term that you just made up.
I see that one difference as being substantial.

Whether or not (char*)1 means anything at all,
is implementation defined.
The meaning of ((char*)0) is defined by the standard.

--
pete

[Eric Sosman]

MC wrote:

"Barry Schwarz" <sc******@deloz.net> wrote in message
news:bi**********@216.39.134.219...

If their is a prototype in scope for the function then the cast is
completely superfluous.

So if I have a header file that has the prototype
for the function and I include that header file
in this source file, then the cast is superfluous .
Am i right ?

In the case presented (where question refers to the
function's first argument), yes.

There's a wrinkle, though, for what are called "variadic
functions." Like the *printf() family, these functions take
a few "mandatory" arguments of known types followed by an
indeterminate number of "variable" arguments. Both the
number and the types of the variable arguments can differ
from one call to the next, e.g.

printf ("Hello, world!\n");
fprintf (stdout, "The answer is %d\n", 42);
sprintf (buff, "%d / %d = %f", 42, 26, 42.0/26.0);

Now, how does all this bear on your question? The
catch is that the compiler has no idea what types the
variable arguments are supposed to have: they can, as
shown above, be different in different calls. Thus, the
compiler does not know it's supposed to convert an argument
from whatever type you present to whatever type the function
actually expects; the compiler doesn't know the expected
type. So for arguments that correspond to the "..." part
of a variadic function's parameter list, casts are still
necessary if the supplied argument doesn't already have
the correct type.

To sum up, if the type of the supplied value doesn't
match the type of the expected argument:

- If there is no prototype in scope, you need a cast.
(Better still would be to introduce a prototype.)

- If there is a prototype in scope and the function
is not variadic, no cast is needed because the
compiler provides the needed conversion. (But if
there's an explicit cast, no harm is done.)

- If there's a prototype and the function is variadic
but the supplied value is for one of the "fixed"
arguments, no cast is needed. (That's why the
first argument is special: there must be at least
one fixed argument, so the very first argument is
necessarily fixed.)

- If there's a prototype and the function is variadic
and the supplied value is for one of the "..."
arguments, you need a cast.

Complicated as all this may seem, it *still* isn't quite
accurate. When the compiler doesn't know what the function
expects (no prototype, or "..." argument), it applies the
"argument promotions." These will, for example, convert a
`float' value to `double' automatically, so some cases of
type mismatch don't actually need the explicit cast mentioned
above.

In light of all these ins and outs, Henry Spencer recommends
explicit casts even when they don't seem to be needed; see the
Third Commandment in

http://www.lysator.liu.se/c/ten-commandments.html

Personally, I confess myself a habitual and wilful sinner against
the Third Commandment, and I will no doubt burn in Hell (or in
gdb, which some people consider different.) But it is probably a
good idea to consider the Commandments carefully before deciding
to violate them: if you're going to sin, do so on purpose and not
by accident.

--
Er*********@sun.com