«

Peter Nilsson wrote:
>
.... snip ...
>
> The weakening of void *'s type in C was deliberate and brought
> about by a number of issues of the day. But whatever the reasons,
> it came at a cost of robustness. That is true irrespective of
> whether we are talking about malloc casting or not.

How? You can't dereference a void*. You can't add to it. All you
can really do is pass it around (through systems that neither know
nor care what it really represents) until it gets somewhere that
does know and care.

Until you start casting.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

CBFalconer wrote:
> Peter Nilsson wrote:
> >
> ... snip ...
> >
> > The weakening of void *'s type in C was deliberate and brought
> > about by a number of issues of the day. But whatever the reasons,
> > it came at a cost of robustness. That is true irrespective of
> > whether we are talking about malloc casting or not.
>
> How?

You point the way...

> You can't dereference a void*. You can't add to it. All you
> can really do is pass it around (through systems that neither know
> nor care what it really represents) until it gets somewhere that
> does know and care.

Even if the destination 'cares', what guarantee does the language
give you that it can 'know'? It's up to the programmer to make sure
that an X* to void* gets converted back to X* and not Y*.

> Until you start casting.

int compare(const void *lhs, const void *rhs)
{
const long *l = lhs;
const long *r = rhs;
return (*l > *r) - (*l < *r);
}

long a[] = { 1, 2, 3 };
int b[] = { 1, 2, 3 };

qsort(a, sizeof a / sizeof *a, sizeof *a, compare); /* fine */
qsort(b, sizeof b / sizeof *b, sizeof *b, compare); /* boom */

--
Peter

"E. Robert Tisdale" <> wrote:

> Joona I Palaste wrote:
>
> > ytrama wrote:
> >
> >>I have read in one old posting that
> >>[you shouldn't] cast [the] pointer which is returned by malloc.
> >>I would like to know the reason.
> >
> > It won't fix anything
> > but it may make the compiler think problems are fixed
> > when they really aren't.

> That's *not* true.

It's not necessarily true for all compilers, but the risk is too great
to ignore.

> f.c: In function `f':
> f.c:2: warning: implicit declaration of function `malloc'

> The compiler gives ample diagnostics

The compiler _may_ give ample diagnostics. Without the cast, it _must_.

(And anyway, superfluous casts are harmful to the mind of the
programmer, and an irritant to the clueful maintainer.)

Richard

Joona I Palaste <> wrote:

> Sebastian Hungerecker <> scribbled the following:
> > E. Robert Tisdale wrote:
> >> Ben Pfaff wrote:
> >>>Some others do disagree, such as P.J. Plauger
> >>>(see article <9sFIb.9066$>).
> >>
> >> Did you really mean to post an email address here?
>
> > That's no email address. It's a message ID. To be specific it's the
> > message id of the following message:
>
> > http://groups.google.com/groups?selm...ink.net&rnum=1

(You don't even need the &rnum=1 part, btw. And I suggest using .co.uk
instead of .com, to avoid the indefinitely and possibly irrepairably
broken Google Groups Beta.)

> Frankly, I believe Trollsdale knew that.

Frankly, I don't have that much confidence in his competence in _any_
field, let alone C or the 'net.

Richard

Peter Nilsson wrote:
> CBFalconer wrote:
>> Peter Nilsson wrote:
>>>
>> ... snip ...
>>>
>>> The weakening of void *'s type in C was deliberate and brought
>>> about by a number of issues of the day. But whatever the reasons,
>>> it came at a cost of robustness. That is true irrespective of
>>> whether we are talking about malloc casting or not.
>>
>> How?
>
> You point the way...
>
>> You can't dereference a void*. You can't add to it. All you
>> can really do is pass it around (through systems that neither know
>> nor care what it really represents) until it gets somewhere that
>> does know and care.
>
> Even if the destination 'cares', what guarantee does the language
> give you that it can 'know'? It's up to the programmer to make sure
> that an X* to void* gets converted back to X* and not Y*.
>
>> Until you start casting.
>
> int compare(const void *lhs, const void *rhs)
> {
> const long *l = lhs;
> const long *r = rhs;
> return (*l > *r) - (*l < *r);
> }
>
> long a[] = { 1, 2, 3 };
> int b[] = { 1, 2, 3 };
>
> qsort(a, sizeof a / sizeof *a, sizeof *a, compare); /* fine */
> qsort(b, sizeof b / sizeof *b, sizeof *b, compare); /* boom */

I just deleted an answer that wasn't working out. Your other
choice is to write the qsort code yourself, and build the sortable
type into it. Then the compiler will catch misuse. In fact this
is often the best move for both safety and efficiency reasons. The
penalty is that you are no longer using tested code. Without the
void* you couldn't even have a generic qsort to call. This is an
argument for adding "typeof(x)" to the language.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

In article <>, says...
> Without the void* you couldn't even have a generic qsort to call. This
> is an argument for adding "typeof(x)" to the language.

It would certainly be a whole lot more useful than strcat_s() and friends.
Of course, waiting for either to show up in your shiny new C07-conforming
compiler might take longer than your life expectancy.

--
Randy Howard (2reply remove FOOBAR)
"Making it hard to do stupid things often makes it hard
to do smart ones too." -- Andrew Koenig