Type casting void *

M

MisterE

Which is 'correct':

void foo(void *a)
{
int *b = (int *)a;
}

or

void foo(void *a)
{
int *b = a;
}

Is there any reason why most source code listings almost always use the
first one?
 
G

gw7rib

Which is 'correct':

void foo(void *a)
{
int *b = (int *)a;

}

or

void foo(void *a)
{
int *b = a;

}

Both look correct to me.
Is there any reason why most source code listings almost always use the
first one?

To reassure the reader that that is what you meant?
So that it still works in C++?

Against this, the casts can hide errors. I tried to demonstate this by
changing the lines to int *b = (int *)*a; and int *b = *a; but of
course neither of these work as *a makes no sense when a is a void *.
 
J

John Bode

Which is 'correct':

void foo(void *a)
{
int *b = (int *)a;

}

or

void foo(void *a)
{
int *b = a;

}

Is there any reason why most source code listings almost always use the
first one?

In C, both forms are correct (I prefer the second). In C++, only the
first form is correct.

Older versions of C (pre-C89) did not support the void* type, instead
using a char* to represent a "generic" pointer, so casts were required
to assign to different pointer types. People who learned on these
older versions probably still cast all pointer assignments out of
habit, but since C89, it's no longer necessary.
 
A

Antoninus Twink

MisterE said:
Both are legal. The second is preferable.


Ignorance, pure ignorance

Of course!

After all, anyone with a different preference to The Great Richard
Heathfield must obviously be ignorant.

And then people will say that Heathfield isn't at all arrogant and the
"trolls" misrepresent him...
 
J

J. J. Farrell

MisterE said:
Which is 'correct':

void foo(void *a)
{
int *b = (int *)a;
}

or

void foo(void *a)
{
int *b = a;
}

Both are "correct". The second is generally considered better style
since it's less to type, less to read and comprehend, and there are
situations where unnecessary casts can disguise errors. It's best to
save casts for where they must be used, so they also act as an added
warning to the user that "something a bit special is going on here".
Is there any reason why most source code listings almost always use the
first one?

I don't accept the premise - most C code I've seen uses the second form
and I'd be very surprised if most C code used the first. If some people
use it habitually in C, I can only imagine it's because they don't
understand the concept and purpose of C void pointers very well.
 
M

Mark Wooding

J. J. Farrell said:
I don't accept the premise - most C code I've seen uses the second
form and I'd be very surprised if most C code used the first. If some
people use it habitually in C, I can only imagine it's because they
don't understand the concept and purpose of C void pointers very well.

I think that many pick up the habit of the pointless cast from C++ --
where it most definitely is /not/ pointless. Some may just not realise
that the cast is unnecessary in C++; some deliberately want to write
code which is valid in both languages; and some don't want to lose the
habit in case it causes problems when they go back to C++ later.

I still consider the cast to be poor style -- for the reasons that
J. J. Farrell outlined -- but the above are reasonable arguments in
favour of it.

-- [mdw]
 
K

Kaz Kylheku

I still consider the cast to be poor style -- for the reasons that
J. J. Farrell outlined -- but the above are reasonable arguments in
favour of it.

Making an /unnecesary/ use of device that is powerful enough to subvert
the type system, just because you need to allocate some memory,
is hard to justify.
 
P

Peter Nilsson

Kaz Kylheku said:
Making an /unnecesary/ use of device that is
powerful enough to subvert the type system,

Void *'s type weakness is a deliberate subversion
of a strongly typed system.
just because you need to allocate some memory,

Um... where in the OP's cited code was /allocation/
an issue?

void foo(void *a)
{
int *b = (int *)a;
}
is hard to justify.

That water purification costs millions of dollars and
adds as much pollution as it removes does not mean that
water purification is hard to justify.

If the cast has the correct type, the above requires a
diagnostic if and only if the declared type of b is
wrong (and not itself void *.) That is a subversion in
a sense, but it's a subversion of the /absence/ of a
strongly typed system.
 
C

CBFalconer

Peter said:
Void *'s type weakness is a deliberate subversion
of a strongly typed system.


Um... where in the OP's cited code was /allocation/
an issue?

void foo(void *a)
{
int *b = (int *)a;
}

FYI that cast is totally redundant, and serves to suppress possible
error messages.
 
K

Keith Thompson

Richard Heathfield said:
CBFalconer said:


What possible error message did you have in mind?

In the code as written, none that I can think of. But if, in the
course of maintenance, the parameter type is changed from void* to,
say, double*, then the cast will indeed suppress an error message, one
that would probably have indicated a real problem.
 
R

Richard Tobin

void foo(void *a)
{
int *b = (int *)a;
}
[/QUOTE]
FYI that cast is totally redundant

It documents, to a human reader, that a conversion is happening.

I wouldn't use it myself, but I can see that some might consider
it worthwhile.

-- Richard
 
M

Martin Ambuhl

FYI that cast is totally redundant

It documents, to a human reader, that a conversion is happening.

I wouldn't use it myself, but I can see that some might consider
it worthwhile.[/QUOTE]

If that is the goal, then it seems that a better approach (although
_still_ not one I would recommend) is to use comments for comments:

void foo(void *a)
{
int *b = /* (int *) */ a;
}
 
R

Richard

Martin Ambuhl said:
If that is the goal, then it seems that a better approach (although
_still_ not one I would recommend) is to use comments for comments:

void foo(void *a)
{
int *b = /* (int *) */ a;
}

That has to rank with one of the dumbest most stupid suggestions I ever
saw in my entire life. Looks terrible. The cast does NO problem
whatsoever. If you want to be a complete fool I guess you will mention
"what if a changes", well guess what - you'd have to change the comment
too.

Truly, truly horrible idea.
 
R

Richard

pete said:
I don't like to use comments for trivia.
The tendency is for trivial comments
not to be updated accordingly with the rest of the code.

Spot on. That suggestion was simply ridiculous.
 
M

Martin Ambuhl

pete said:
I don't like to use comments for trivia.
The tendency is for trivial comments
not to be updated accordingly with the rest of the code.

The cast is trivial and potentially dangerous. Richard Tobin suggested
as a possible rationalization for it that it commented the code. I
suggested only that if one wanted to comment code, the right tool is a
comment. Part of the reason that I _clearly_ stated that this is
"although _still_ not one I would recommend" is that it is trivial.
Thank you for the expansion. But note that while it is true that
> The tendency is for trivial comments
> not to be updated accordingly with the rest of the code.
that tendency is much more dangerous for an cast not updated than for a
commonet not updated.
 
T

Tim Rentsch

Richard said:
That has to rank with one of the dumbest most stupid suggestions I ever
saw in my entire life. Looks terrible. The cast does NO problem
whatsoever. If you want to be a complete fool I guess you will mention
"what if a changes", well guess what - you'd have to change the comment
too.

If that's really one of the dumbest most stupid suggestions
you've ever seen then I think you are a very lucky person.
I expect most people have seen /much/ worse...
 
R

Richard

Tim Rentsch said:
If that's really one of the dumbest most stupid suggestions
you've ever seen then I think you are a very lucky person.
I expect most people have seen /much/ worse...

Really, one of! (many ...)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top