Do you have to cast void pointers when dereferencing them?
Guy Harris
guy at auspex.UUCP
Thu Dec 22 08:27:23 AEST 1988
>> >code must know the type of the lvalue to put the rvalue into the proper
>> >representation. Is this not true?
>> . . .Why is this any different from
>> int foo; float bar; bar = foo;
>> which also causes an implicit conversion from "int" to "float"?
>
>The statement I made was regarding implicit conversion between pointer
>types.
Sorry, but with regards to the question of whether the compiler knows
enough about the types involved to do the conversion, that's *not* a
difference. Pointer types, integral types, structured types, whatever;
the compiler *does* have enough information to perform an implicit
conversion in an assignment, if such a conversion is defined and is
allowed.
>Well, as far as K&R goes, no implicit pointer type conversion
>is made (they do describe how ints can be converted to float (actually
>double, but I digress)).
Whether the language specifies that such conversions are performed or
not is a different issue. There is sufficient information available to
the compiler that it *can* perform such conversions. Why is this any
different from:
int foo;
struct { int a; int b; } bar;
foo = bar;
Were a conversion between "int" and a "struct" of the given flavor
defined, the compiler could arrange that it be performed; there doesn't
happen to be such a conversion defined, however.
>This, I believe, is the root of some of the
>discussion lately that the following is non-portable:
>
> #define NULL (char *)0
> . . .
> int *foo;
>
> foo = NULL;
>
>(note that different pointer types are on either side of the '=').
Err, no, it's not the root of the discussion. The problem isn't just
that this requires a pointer conversion; the problem is that some
compilers may object to converting a "char *" to an "int *" without a
cast (not because they don't know how to do it, but because it's not
*required* to be permitted by the dpANS, and because it could be
difficult or impossible in some implementations).
If it's just a question of different types,
#define NULL (void *)0
...
int *foo;
foo = NULL;
would be no better than your example; however, since the dpANS treats
"void *" differently from other pointers when it comes to conversions,
this construct is OK while the other isn't.
More information about the Comp.lang.c
mailing list