Developer Forum

What is wrong with the above?

Don't worry, I already know (learned my lesson last week.) It is for the
benefit of our resident compiler guru who seems to think you need the cast.
I thought it too, up until I started posting here!

Thanks,

Chris

cast.
Even better, here is the email itself. Please help!

<start email>
First, Casts from void * are necessary both in C and C++. This is from the
same reason you told me: otherwise, if the compiler wouldn't
know what is the size of the object which is pointed at, it might get
confused with arithmetic operations. You can ask him where did he learned
this rule from. tell me if you want me to correspond directly with him.

Second, a possible reason to use integral types for addresses rather than
void *, is that in order to perform bitwise operations on an
address, you have to use operators of an integral type.
<end email>

"Chris Fogelklou" < XXXX@XXXXX.COM > a rit dans le message de



Hi,


the

Casts from void* are necessary in C++, not in C.


Regis

the

I am aware... I'm fishing for more info! Perhaps if I reposted again and
said you were wrong I'll get more...

You're WRONG!

learned
than

Yes, please tell her to come here. On the other hand, don't, tell
her to read the archives. This conversation is getting old ;)

the ISO/IEC 9899:1999 standard section 6.3.2.3 has what you want. That
is C99 btw. Don't know the clause in C89.


This much is true. But it is in implementation defined behaviour land,
most compilers behave very nicely when it comes to this though.

--
Thomas.

struct my_struct *p = (struct my_struct *)malloc(sizeof(struct
my_struct));

There is nothing wrong with the above. It is considered a better
idiom to use

struct my_struct *p = malloc(sizeof *p);

The argument that the compiler does not know the type of the object
is bogus since all the information is already there. The compiler knows
the type of p, it knows the type of the value returned by malloc,
nothing is missing.

In my previous reply I mentioned 6.3.2.3, I should also have mentioned
clause 6.5.4 and 6.5.16.1 which is where the "no cast required" part is.

--
Thomas.

"Chris Fogelklou" < XXXX@XXXXX.COM > a rit dans le message de


Yes, sorry for that, i read your post too quickly,






for
the

void* is implicitly converted to the destination pointer type (C99 ?.3.2.3
and ?.20.3.1).


sizeof ?

him.

It's also said in the standard (C99), part 6 of ?.3.2.3 that :
"Any pointer type may be converted to an integer type. Except as previously
specified, the result is implementation-defined. If the result cannot be
represented in the integer type, the behavior is undefined. The result need
not be in the range of values of any integer type."

Is he/she sure that he/she can always hold his adressses with an integral
type ? It implies sizeof(the famous integral type) >= sizeof(void*).

There is a way in C99 to hold pointers and adresses with integers thanks to
the types intptr_t and uintptr_t. (C99 7.18.1.4), but I'm not sure it's
possible in C90..

Regis

the
cast.

Hi Thomas,

Thanks! OK, then what about this:

int my_func(void *pinst)
{
my_struct *pthis = (my_struct *)pinst; //Cast
pthis->print("Lets see what's wrong with this!");
return 0;
}

If it is OK to never cast to/from void * as was made abundantly clear last
week, then this is also OK. However, pinst could be a run-time defineable
value.

Thanks!

Chris

It is absolutly ok to do this (presuming a correct definition of
my_struct) with or without a cast.

void * can be converted to from other object pointer types and the other
way round without casts in any circumstance. (function pointers are
different here, but that is another story).

And note that function parameters are always evaluated at runtime.

When my_func is called, the arguments to that call are evaluated and
copied into the parameters of the to be called function.

--
Z ( XXXX@XXXXX.COM )
"LISP is worth learning for the profound enlightenment experience
you will have when you finally get it; that experience will make you
a better programmer for the rest of your days." -- Eric S. Raymond

Don't get too antsy with him/her. This sounds like some system
programming operations on some embedded system, where the rules
are often different. The cast of the malloc remains unnecessary
(and don't put the question in the subject only).

Do learn to organize your questions into a single consistent
message, rather than a bit here and a bit there.

--
fix (vb.): 1. to paper over, obscure, hide from public view; 2.
to work around, in a way that produces unintended consequences
that are worse than the original problem. Usage: "Windows ME
fixes many of the shortcomings of Windows 98 SE". - Hutchison

Ris Troadec" < XXXX@XXXXX.COM > wrote in message
news:c5maek$b90$ XXXX@XXXXX.COM ...
de
from
and
?.3.2.3
get
previously
need
to
Do you know if this was also a standard in C89/C90? If so, it would
strengthen my argument since the recent response was that "GCC-derived
compilers don't fully support C99 yet." Not sure if it's true... Any
thoughts?

Not sure what she meant with arithmetic operations... you don't normally do
arithmetic on pointers, but if you did, I guess you could just cast to an
integral type of the correct size, correct?

The fact is I am very uncomfortable holding addresses in an integral data
type. Usually we let the compiler choose the addressing scheme (depending
on the memory model) and it should (if it is smart) know how big to make
pointers. But if all of our generic pointers are integral and need to be
casted to pointers, it's our own code that must know what the memory model
is.

Thanks in advance!

Chris

In <c5m97e$39jkg$ XXXX@XXXXX.COM > Thomas Stegen < XXXX@XXXXX.COM > writes:



Nope, it doesn't. It says:

1 A pointer to void may be converted to or from a pointer to any
incomplete or object type. A pointer to any incomplete or
object type may be converted to a pointer to void and back again;
the result shall compare equal to the original pointer.

But there is no mention that the conversion is automatic. Compare with

5 An integer may be converted to any pointer type. Except as
previously specified, the result is implementation-defined,
might not be correctly aligned, might not point to an entity of
the referenced type, and might be a trap representation.

6 Any pointer type may be converted to an integer type. Except as
previously specified, the result is implementation-defined. If the
result cannot be represented in the integer type, the behavior
is undefined. The result need not be in the range of values of
any integer type.

7 A pointer to an object or incomplete type may be converted to
a pointer to a different object or incomplete type.

Do you mean that these conversions are automatic, too?

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: XXXX@XXXXX.COM

In <c5maek$b90$ XXXX@XXXXX.COM > "Ris Troadec" < XXXX@XXXXX.COM > writes:




You're WRONG!

There is NOTHING in C99 ?.3.2.3 or ?.20.3.1 supporting your assertion.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: XXXX@XXXXX.COM

In < XXXX@XXXXX.COM > CBFalconer < XXXX@XXXXX.COM > writes:




It sounds more like someone confusing the C and C++ rules.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: XXXX@XXXXX.COM

Sorry... meant "then this is also BAD practice."