Pointer dereference rather than sizeof?

[Micheal Smith]

I recently read an article containing numerous gripes about common C
practices. One of them contained a gripe about the use of the sizeof
operator as an argument to malloc calls. The supposed "right" way to go
about calling malloc instead is to dereference a pointer; apparently even
if said pointer is undefined.

E.g.
ptr = malloc(sizeof(struct some_struct)); = wrong

ptr = malloc(*ptr); = right

The method works on my platform, but doesn't really sit right with me. Is
the code portable? Standard? I've been looking myself, but haven't come
across anything forbidding it as of yet.

[Martin Ambuhl]

Micheal Smith wrote:

I recently read an article containing numerous gripes about common C
practices. One of them contained a gripe about the use of the sizeof
operator as an argument to malloc calls. The supposed "right" way to go
about calling malloc instead is to dereference a pointer; apparently even
if said pointer is undefined.

E.g.
ptr = malloc(sizeof(struct some_struct)); = wrong

ptr = malloc(*ptr); = right

I'm sure you misunderstood.

If ptr is declared as
struct some-struct *ptr;
the first method is poor, but the second is an abomination.
It should be
ptr = malloc(sizeof *ptr);

It is not the operator 'sizeof' that is the problem, but the argument to
the operator. Note that sizeof *ptr is a compile-time constant and is
independent of ptr being initialized to some actual storage in the
correct form. In your suppose 'right' form, you are courting severe errors.

[Micheal Smith]

On Sun, 24 Aug 2008 23:50:56 -0400, Martin Ambuhl wrote:

Micheal Smith wrote:

>I recently read an article containing numerous gripes about common C
practices. One of them contained a gripe about the use of the sizeof
operator as an argument to malloc calls. The supposed "right" way to
go about calling malloc instead is to dereference a pointer; apparently
even if said pointer is undefined.

E.g.
ptr = malloc(sizeof(struct some_struct)); = wrong

ptr = malloc(*ptr); = right

I'm sure you misunderstood.

If ptr is declared as
struct some-struct *ptr;
the first method is poor, but the second is an abomination. It should be
ptr = malloc(sizeof *ptr);

It is not the operator 'sizeof' that is the problem, but the argument to
the operator. Note that sizeof *ptr is a compile-time constant and is
independent of ptr being initialized to some actual storage in the
correct form. In your suppose 'right' form, you are courting severe
errors.

Ah, there was a slip in my example. Thanks for the correction. It
definitely is
ptr = malloc(sizeof *ptr);

In case there's some misunderstanding I'm not touting either to be
right. Actually in my own estimation I'd prefer the "wrong" example.

[fjblurt]

On Aug 24, 8:59 pm, Micheal Smith <[e-mail]:

[asking about difference between `ptr = malloc(sizeof(struct some_struct))' and `ptr = malloc(sizeof(*ptr))']

The disadvantage of the first form is that it is up to the programmer
to ensure that the type given in the call to malloc() agrees with the
type in the declaration of ptr. If I inadvertently write

struct other_struct *ptr;

ptr = malloc(sizeof(struct some_struct));

this code is almost certainly not what I want, but the compiler will
not tell me anything is wrong. On the other hand, if I use the second
form, there is no possibility of a mismatch, and if I later change the
type from 'struct some_struct' to `struct third_struct', I only have
to change it in one place.

[Richard Heathfield]

Micheal Smith said:

I recently read an article containing numerous gripes about common C
practices. One of them contained a gripe about the use of the sizeof
operator as an argument to malloc calls. The supposed "right" way to go
about calling malloc instead is to dereference a pointer; apparently even
if said pointer is undefined.

E.g.
ptr = malloc(sizeof(struct some_struct)); = wrong

Well, not wrong, just not very maintainable.

>
ptr = malloc(*ptr); = right

Wrong, wrong, wrong, wrong, wrong. (BUT see below - because you're onto
something good here.)

The method works on my platform,

No, it doesn't, because (if, as you presumably mean to say, the pointer's
value is indeterminate) evaluating the pointer to enable it to be
dereferenced gives you undefined behaviour. (BUT see below - because
you're onto something good here.)

but doesn't really sit right with me. Is
the code portable? Standard? I've been looking myself, but haven't come
across anything forbidding it as of yet.

The Standard says that evaluating an indeterminately-valued object gives
you undefined behaviour - which, presumably, you don't want.

Okay, we've blown away malloc(*ptr), I hope.

Now let's plug in its replacement:

ptr = malloc(n * sizeof *ptr);

(n * can be omitted if it's 1, and sizeof *ptr must be replaced with some
other value - typically 1 - if ptr is of type void *)

Here, *ptr is *not* a pointer dereference, no matter how it looks, because
sizeof DOES NOT EVALUATE ITS OPERAND (except in one weird case in C99
which we can ignore in this discussion, partly because this isn't that
case, and partly because you're probably not using C99 anyway).

The advantage of this over malloc(n * sizeof(type)) is that, even if the
type of ptr changes during maintenance (as long as it doesn't change in or
out of void *), the line doesn't need to be fixed - it adjusts to the new
type's size automatically.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Keith Thompson]

Micheal Smith <xu****@cheapbsd.netwrites:

I recently read an article containing numerous gripes about common C
practices. One of them contained a gripe about the use of the sizeof
operator as an argument to malloc calls. The supposed "right" way to go
about calling malloc instead is to dereference a pointer; apparently even
if said pointer is undefined.

E.g.
ptr = malloc(sizeof(struct some_struct)); = wrong

ptr = malloc(*ptr); = right

The method works on my platform, but doesn't really sit right with me. Is
the code portable? Standard? I've been looking myself, but haven't come
across anything forbidding it as of yet.

As you acknowledged later in the thread, the correct form is

ptr = malloc(sizeof *ptr);

or, if you're uncomfortable with using sizeof without parentheses:

ptr = malloc(sizeof(*ptr));

Or if you want to allocate an array:

ptr = malloc(N * sizeof *ptr);

As "fjblurt" pointed out, this has the advantage that it's obvious
you're using the correct type; if during later maintenance you change
ptr from a foo* to a bar*, the malloc call will continue to be
correct.

The trick here is that the pointer isn't actually dereferenced. The
operand of a sizeof operator is not evaluated; it's only used to
determine the type of the expression. (Variable-length arrays, or
VLAs, a new features in C99, are an exception to this.) So the
expression ``sizeof *ptr'' is guaranteed not to attempt to dereference
ptr. It doesn't even evaluate the pointer value itself.

Your discomfort over what looks like deferencing a possibly invalid
pointer is reasonable, but it's perfectly safe in this case.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Bill Reid]

Keith Thompson <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

Micheal Smith <xu****@cheapbsd.netwrites:

I recently read an article containing numerous gripes about common C
practices. One of them contained a gripe about the use of the sizeof
operator as an argument to malloc calls. The supposed "right" way to go
about calling malloc instead is to dereference a pointer; apparently

even

if said pointer is undefined.

E.g.
ptr = malloc(sizeof(struct some_struct)); = wrong

ptr = malloc(*ptr); = right

The method works on my platform, but doesn't really sit right with me.

Is

the code portable? Standard? I've been looking myself, but haven't

come

across anything forbidding it as of yet.

As you acknowledged later in the thread, the correct form is

ptr = malloc(sizeof *ptr);

or, if you're uncomfortable with using sizeof without parentheses:

ptr = malloc(sizeof(*ptr));

Or if you want to allocate an array:

ptr = malloc(N * sizeof *ptr);

As "fjblurt" pointed out, this has the advantage that it's obvious
you're using the correct type; if during later maintenance you change
ptr from a foo* to a bar*, the malloc call will continue to be
correct.

The trick here is that the pointer isn't actually dereferenced. The
operand of a sizeof operator is not evaluated; it's only used to
determine the type of the expression. (Variable-length arrays, or
VLAs, a new features in C99, are an exception to this.) So the
expression ``sizeof *ptr'' is guaranteed not to attempt to dereference
ptr. It doesn't even evaluate the pointer value itself.

Your discomfort over what looks like deferencing a possibly invalid
pointer is reasonable, but it's perfectly safe in this case.

Of course it looks like it is de-referencing the pointer, because that's
what de-referencing a pointer looks like everywhere else in "C" code.

At the risk of repeating myself, I'm going to repeat myself:

"It's completely friggin' impossible to learn all the bass-ackwards
and semi-sideways inconsistent methods of declaring and
dereferencing pointers in "C". NO non-lunatic has ever been able
to grasp the total non-logic of the topic, which is just one
incomprehensible aspect of an ostensible "programming language"
that was obviously actually designed as a cruel joke on anybody
who would attempt to use it (I can just hear the uber-techno-trolls
K&R sniggering about it now)..."

If you DO choose to use this so-called "language", NEVER blame
yourself if you get massively confused by this type of inconsistent
syntax, IT'S NOT YOUR FAULT, YOU'VE BEEN "KERNIGHANED
AND RITCHIED", PUNK...

---
William Ernest Reid

[Peter Nilsson]

[e-mail] wrote:

Micheal Smith <[e-mail]:

[asking about difference between `ptr = malloc(sizeof(
struct some_struct))' and `ptr = malloc(sizeof(*ptr))']

The disadvantage of the first form is that it is up to the
programmer to ensure that the type given in the call to
malloc() agrees with the type in the declaration of ptr.

Quite so. There is more chance of success with...

ptr = (struct some_struct *) malloc(sizeof *ptr);

>*If I inadvertently write

struct other_struct *ptr;

ptr = malloc(sizeof(struct some_struct));

this code is almost certainly not what I want, but the
compiler will not tell me anything is wrong.*On the other
hand, if I use the second form, there is no possibility
of a mismatch,

Er... did you jut say no possibility? What about...

int *ptr; /* int should be long */
ptr = malloc(*ptr);

The second form can be justifiably preferred, but it is
not foolproof, no method is.

and if I later change the type from 'struct some_struct'
to `struct third_struct', I only have to change it in
one place.

--
Peter

[Keith Thompson]

Peter Nilsson <ai***@acay.com.auwrites:

[e-mail] wrote:

>Micheal Smith <[e-mail]:

[asking about difference between `ptr = malloc(sizeof(
struct some_struct))' and `ptr = malloc(sizeof(*ptr))']

The disadvantage of the first form is that it is up to the
programmer to ensure that the type given in the call to
malloc() agrees with the type in the declaration of ptr.

Quite so. There is more chance of success with...

ptr = (struct some_struct *) malloc(sizeof *ptr);

How is the cast helpful?

>>*If I inadvertently write

struct other_struct *ptr;

ptr = malloc(sizeof(struct some_struct));

this code is almost certainly not what I want, but the
compiler will not tell me anything is wrong.*On the other
hand, if I use the second form, there is no possibility
of a mismatch,

Er... did you jut say no possibility? What about...

int *ptr; /* int should be long */
ptr = malloc(*ptr);

The second form can be justifiably preferred, but it is
not foolproof, no method is.

The error is in the declaration of ptr, not in the call to malloc.

[...]

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Martin Ambuhl]

Peter Nilsson wrote:

Quite so. There is more chance of success with...

ptr = (struct some_struct *) malloc(sizeof *ptr);

^^^^^^^^^^^^^^^^^^^^^

The case is unnecessary, as well as poor programing practice in C.

Er... did you jut say no possibility? What about...

int *ptr; /* int should be long */
ptr = malloc(*ptr);

This is not a problem with the proper use of malloc, but with the
programmer having no clue what type to use. Maybe he should take yp
canasta,

The second form can be justifiably preferred, but it is
not foolproof, no method is.

If you hire monkeys instead of programmers, that's your problem.

[Richard]

Martin Ambuhl <ma*****@earthlink.netwrites:

Peter Nilsson wrote:

>Quite so. There is more chance of success with...

ptr = (struct some_struct *) malloc(sizeof *ptr);

^^^^^^^^^^^^^^^^^^^^^

The case is unnecessary, as well as poor programing practice in C.

We all hear this time and time again because of some almost impossible,
manufactured instance in a C environment. Another way of looking at this
"poor practice" is this - it shows there and then the type of ptr
without needing to trawl back ... and since we also hear so many times in
clc how different types can live in different "types of memory" it might
even help the compiler generate the call to the "correct" malloc .....

[Ian Collins]

Richard wrote:

Martin Ambuhl <ma*****@earthlink.netwrites:

>Peter Nilsson wrote:

>>Quite so. There is more chance of success with...

ptr = (struct some_struct *) malloc(sizeof *ptr);

^^^^^^^^^^^^^^^^^^^^^

The case is unnecessary, as well as poor programing practice in C.

We all hear this time and time again because of some almost impossible,
manufactured instance in a C environment. Another way of looking at this
"poor practice" is this - it shows there and then the type of ptr
without needing to trawl back ... and since we also hear so many times in
clc how different types can live in different "types of memory" it might
even help the compiler generate the call to the "correct" malloc .....

Utter bollocks. The cast is superfluous error concealing clutter.

--
Ian Collins.

[Richard]

Ian Collins <ia******@hotmail.comwrites:

Richard wrote:

>Martin Ambuhl <ma*****@earthlink.netwrites:

>>Peter Nilsson wrote:

Quite so. There is more chance of success with...

ptr = (struct some_struct *) malloc(sizeof *ptr);
^^^^^^^^^^^^^^^^^^^^^

The case is unnecessary, as well as poor programing practice in C.

We all hear this time and time again because of some almost impossible,
manufactured instance in a C environment. Another way of looking at this
"poor practice" is this - it shows there and then the type of ptr
without needing to trawl back ... and since we also hear so many times in
clc how different types can live in different "types of memory" it might
even help the compiler generate the call to the "correct" malloc .....

Utter bollocks. The cast is superfluous error concealing clutter.

Which we hear about 20,00,0000000,000 million times a day. I was
wondering when its ok to say "read the FAQ" and others its not.

But you deny that different types can live in different memory?

Interesting.

I also find it interesting that you find it "utter bollox" that some
people might (you know when debugging 50,0000 lines of other peoples c
code by reading a printout) find the cast helpful in reading the local
code at that point.

Less ribbing and more seriously - how many times have you seen these
casts actually conceal a problem in the real world? The reason I ask is
that I have seen these casts in literally thousands of lines of code in
perfectly working systems that I have been contracted in to
enhance/maintain for a period of time.

[Nick Keighley]

On 26 Aug, 01:48, "Bill Reid" <[e-mail]:

Keith Thompson <[e-mail] in message
news:ln************@nuthaus.mib.org...

<snip>

discussing
ptr = malloc (sizeof *ptr)

Your discomfort over what looks like deferencing a possibly invalid
pointer is reasonable, but it's perfectly safe in this case.

Of course it looks like it is de-referencing the pointer, because that's
what de-referencing a pointer looks like everywhere else in "C" code.

At the risk of repeating myself, I'm going to repeat myself:

"It's completely friggin' impossible to learn all the bass-ackwards
and semi-sideways inconsistent methods of declaring and
dereferencing pointers in "C". *NO non-lunatic has ever been able
to grasp the total non-logic of the topic

<snip rant>

so what is a simple, easy to learn, well defined language.
What would *you* recommend?

--
Nick Keighley

[Ian Collins]

Richard wrote:

Ian Collins <ia******@hotmail.comwrites:

>Richard wrote:

>>We all hear this time and time again because of some almost impossible,
manufactured instance in a C environment. Another way of looking at this
"poor practice" is this - it shows there and then the type of ptr
without needing to trawl back ... and since we also hear so many times in
clc how different types can live in different "types of memory" it might
even help the compiler generate the call to the "correct" malloc .....

>Utter bollocks. The cast is superfluous error concealing clutter.

But you deny that different types can live in different memory?

No, but there is only one malloc (unless C is grown function overloading
while I wasn't looking) and even if there wasn't a cast would be a
seriously queer way of selecting a function to call.

>
I also find it interesting that you find it "utter bollox" that some
people might (you know when debugging 50,0000 lines of other peoples c
code by reading a printout) find the cast helpful in reading the local
code at that point.

Well I never have and I've been fixing other people's code for over 20
years.

Less ribbing and more seriously - how many times have you seen these
casts actually conceal a problem in the real world? The reason I ask is
that I have seen these casts in literally thousands of lines of code in
perfectly working systems that I have been contracted in to
enhance/maintain for a period of time.

Once or twice, but the bit I really hate is superfluous clutter.

--
Ian Collins.

[Richard Tobin]

In article <g9**********@registered.motzarella.org>,
Richard <rg****@gmail.comwrote:

>>... and since we also hear so many times in
clc how different types can live in different "types of memory" it might
even help the compiler generate the call to the "correct" malloc .....

>Utter bollocks. The cast is superfluous error concealing clutter.

>But you deny that different types can live in different memory?

You need to be more precise about what you mean. If you mean that
there are different address ranges that different types must go in,
that's not allowed by C. It could be that some address ranges are
preferable for certain types, but I don't know any examples of that.
And you can imagine other possibilities that a sufficiently clever
compiler could take advantage of.

But the memory returned by malloc() can be used for any type that
fits, so a compiler can't return memory only suitable for struct A
if the program might put a struct B there later.

-- Richard
--
Please remember to mention me / in tapes you leave behind.

[Richard]

Ian Collins <ia******@hotmail.comwrites:

Richard wrote:

>Ian Collins <ia******@hotmail.comwrites:

>>Richard wrote:

>>>We all hear this time and time again because of some almost impossible,
manufactured instance in a C environment. Another way of looking at this
"poor practice" is this - it shows there and then the type of ptr
without needing to trawl back ... and since we also hear so many times in
clc how different types can live in different "types of memory" it might
even help the compiler generate the call to the "correct" malloc .....

>>Utter bollocks. The cast is superfluous error concealing clutter.

But you deny that different types can live in different memory?

No, but there is only one malloc (unless C is grown function overloading
while I wasn't looking) and even if there wasn't a cast would be a
seriously queer way of selecting a function to call.

>>
I also find it interesting that you find it "utter bollox" that some
people might (you know when debugging 50,0000 lines of other peoples c
code by reading a printout) find the cast helpful in reading the local
code at that point.

Well I never have and I've been fixing other people's code for over 20
years.

Would you like to redefine "never". You're not the kind of poster I
would call a "liar" (leading to the usual calls for apologies etc) but I
feel you must be mistaken, forgetful or being slightly too OTT by using
"never".

You would not find reading the type of "ptr" in a huge mass of code
helpful? I sure would.

>

>Less ribbing and more seriously - how many times have you seen these
casts actually conceal a problem in the real world? The reason I ask is
that I have seen these casts in literally thousands of lines of code in
perfectly working systems that I have been contracted in to
enhance/maintain for a period of time.

Once or twice, but the bit I really hate is superfluous clutter.

I dont see it as that. I dont like superfluous white space though ...

btw I am not supporing it - I just think the reaction here is sometimes
too strong.

But I missed your answer possibly - did you mean you have seen the use
of it break systems once or twice?

[Richard Bos]

Nick Keighley <ni******************@hotmail.comwrote:

On 26 Aug, 01:48, "Bill Reid" <[e-mail]:

At the risk of repeating myself, I'm going to repeat myself:

"It's completely friggin' impossible to learn all the bass-ackwards
and semi-sideways inconsistent methods of declaring and
dereferencing pointers in "C". =A0NO non-lunatic has ever been able
to grasp the total non-logic of the topic

so what is a simple, easy to learn, well defined language.
What would *you* recommend?

For Bill? Logo. _With_ turtle.

Richard

[Bartc]

Nick Keighley wrote:

On 26 Aug, 01:48, "Bill Reid" <[e-mail]:

>discussing
ptr = malloc (sizeof *ptr)

>"It's completely friggin' impossible to learn all the bass-ackwards
and semi-sideways inconsistent methods of declaring and
dereferencing pointers in "C". NO non-lunatic has ever been able
to grasp the total non-logic of the topic

so what is a simple, easy to learn, well defined language.
What would *you* recommend?

It came as a surprise to me that there apparently were no other languages
that do the same sorts of things as C does (ignoring C++).

So that explains why C is that widespread -- there are no alternatives! Not
when a low-level language is needed anyway.

C is on the face of it very simple; basic datatypes like:

Integers (of say 8,16,32,64 bits)
Floats (of say 32,64 bits)
Pointers (of say 32 or 64 bits)

And fixed-length arrays, and struct collections, of this lot and each other.

But, C seems to come with a huge amount of baggage, and seems to spread
itself too thinly across every system ever conceived, past present and
future. With the result that the obvious way to do anything is nearly always
wrong -- according to this newsgroup, because it might break on some obscure
system.

--
Bartc

[Nick Keighley]

On 26 Aug, 11:44, [e-mail] (Richard Bos) wrote:

Nick Keighley <[e-mail]:

On 26 Aug, 01:48, "Bill Reid" <[e-mail]:

At the risk of repeating myself, I'm going to repeat myself:

"It's completely friggin' impossible to learn all the bass-ackwards
and semi-sideways inconsistent methods of declaring and
dereferencing pointers in "C". =A0NO non-lunatic has ever been able
to grasp the total non-logic of the topic

so what is a simple, easy to learn, well defined language.
What would *you* recommend?

For Bill? Logo. _With_ turtle.

I thought that was for bright children?

--
Nick Keighley

[William Pursell]

On 26 Aug, 10:20, Richard<[e-mail]:
re: the practice of casting the return of malloc()

Richard wrote:

I also find it interesting that you find it "utter bollox" that some
people might (you know when debugging 50,0000 lines of other peoples c
code by reading a printout) find the cast helpful in reading the local
code at that point.

You would not find reading the type of "ptr" in a huge mass of code
helpful? I sure would.

Unless the type is wrong, in which case it causes
a great deal more confusion. If you need to know
the type of a variable, look at its declaration.
If you need to know the type of a variable because
you need to know how much space to allocate
using malloc, then learn to use sizeof *p
instead of sizeof( typeof p ) and you discover
that you don't actually need to know the type
of p at all. By your reasoning,

x = z + y;

should always be replaced with

x = (unsigned)((int) z + (long) y);

so that you don't have to look at the
declaration of x, y, and z to know that they
are of type unsigned, long, and int, respectively.
How is a call to malloc any different than
this case?

[Flash Gordon]

Bartc wrote, On 26/08/08 12:32:

Nick Keighley wrote:

>On 26 Aug, 01:48, "Bill Reid" <[e-mail]:

>discussing
ptr = malloc (sizeof *ptr)

>>"It's completely friggin' impossible to learn all the bass-ackwards
and semi-sideways inconsistent methods of declaring and
dereferencing pointers in "C". NO non-lunatic has ever been able
to grasp the total non-logic of the topic

so what is a simple, easy to learn, well defined language.
What would *you* recommend?

It came as a surprise to me that there apparently were no other
languages that do the same sorts of things as C does (ignoring C++).

So that explains why C is that widespread -- there are no alternatives!
Not when a low-level language is needed anyway.

I've used Pascal derivative for low-level programming including embedded
systems development. I've known people to do it in ADA. I came across
one computer where the OS was developed in Forth. I'm sure it is done in
other languages as well.

C is on the face of it very simple; basic datatypes like:

Integers (of say 8,16,32,64 bits)
Floats (of say 32,64 bits)
Pointers (of say 32 or 64 bits)

And fixed-length arrays, and struct collections, of this lot and each
other.

You can get very complex things with just that lot. This applies to
other languages as well.

But, C seems to come with a huge amount of baggage,

? It's a very small language.

and seems to spread
itself too thinly across every system ever conceived, past present and
future.

That is part of why it is still a small language.

With the result that the obvious way to do anything is nearly
always wrong -- according to this newsgroup, because it might break on
some obscure system.

Only some stuff hits that. You then just have to decide if the extra
effort to make it more portable is worth it (for example, with the code
I currently work on making it portable to non-8-bit byte systems is
*not* worth the effort.
--
Flash Gordon

[Herbert Rosenau]

On Tue, 26 Aug 2008 07:28:01 UTC, Peter Nilsson <ai***@acay.com.au>
wrote:

int *ptr; /* int should be long */
ptr = malloc(*ptr);

Will fail iserably because pter is uninitialised and access to an
uninitialised pointer ends up in undefined behavior.

The second form can be justifiably preferred, but it is
not foolproof, no method is.

No ,it can not. Because even when ptr points really to the number of
bytes you likes to malloc the value of ptr, aka the address of the
object ptr points to befor malloc returns will get lost, leaving in
memoryleak.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!

[Herbert Rosenau]

On Tue, 26 Aug 2008 08:39:12 UTC, Richard<rg****@gmail.comwrote:

Martin Ambuhl <ma*****@earthlink.netwrites:

Peter Nilsson wrote:

Quite so. There is more chance of success with...

ptr = (struct some_struct *) malloc(sizeof *ptr);

^^^^^^^^^^^^^^^^^^^^^

The case is unnecessary, as well as poor programing practice in C.

We all hear this time and time again because of some almost impossible,
manufactured instance in a C environment. Another way of looking at this
"poor practice" is this - it shows there and then the type of ptr
without needing to trawl back ... and since we also hear so many times in
clc how different types can live in different "types of memory" it might
even help the compiler generate the call to the "correct" malloc .....

there is only one single type of malloc: char *malloc(int), But
leaving of to #include ystdlib.hgets misinterpreted by the compiler
as int malloc(int) and then copying the unset value of the place where
a function returns ints converted to void* as result of malloc()
hitting the lands of undefined behavior.

The times of plain K&R are gone significantly more than 20 years ago.

So based on the faulty cast the compiler will supperss any diagnostic
an lets you fall in the deep black hole of undefined behavior without
any comment on that.

Simply don't cast, aviod cast always - except you knows exactly why
you have to cast. Casting a value returned by a function returning a
pointer is in all circumstanes a mistake of a dumb "coder" who has not
learned programming.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!

[Herbert Rosenau]

On Tue, 26 Aug 2008 08:47:34 UTC, Richard<rg****@gmail.comwrote:

Ian Collins <ia******@hotmail.comwrites:

Richard wrote:

Martin Ambuhl <ma*****@earthlink.netwrites:

Peter Nilsson wrote:

Quite so. There is more chance of success with...

ptr = (struct some_struct *) malloc(sizeof *ptr);
^^^^^^^^^^^^^^^^^^^^^

The case is unnecessary, as well as poor programing practice in C.

We all hear this time and time again because of some almost impossible,
manufactured instance in a C environment. Another way of looking at this
"poor practice" is this - it shows there and then the type of ptr
without needing to trawl back ... and since we also hear so many times in
clc how different types can live in different "types of memory" it might
even help the compiler generate the call to the "correct" malloc .....

Utter bollocks. The cast is superfluous error concealing clutter.

Which we hear about 20,00,0000000,000 million times a day. I was
wondering when its ok to say "read the FAQ" and others its not.

But you deny that different types can live in different memory?

Interesting.

I also find it interesting that you find it "utter bollox" that some
people might (you know when debugging 50,0000 lines of other peoples c
code by reading a printout) find the cast helpful in reading the local
code at that point.

Less ribbing and more seriously - how many times have you seen these
casts actually conceal a problem in the real world? The reason I ask is
that I have seen these casts in literally thousands of lines of code in
perfectly working systems that I have been contracted in to
enhance/maintain for a period of time.

Noways since ISO/ANSI C was released. In any way it was a dumb mistake
by someone who had never learden to program but was hacking planless
around, producing errornous code.

There is a golden rule: avoid cast always - except you knows exactly
why you must cast. An casting a result of a function that returns
pointer to void is under no circumstand a cause to cast. In contrast,
it will ever and in all cirtcumstaneces result in a faulty program.

When one sees such a defective cast one can be sure that the one who
has written that is completely untrustable and it will be advisabe to
kill the whole source this person has constructed and write anything
again from scratch to get rid of more hidden bugs, saving the time to
find them.

--
Tschau/Bye
Herbert

Visit http://www.ecomstation.de the home of german eComStation
eComStation 1.2R Deutsch ist da!

[Martin Ambuhl]

Herbert Rosenau wrote:

there is only one single type of malloc: char *malloc(int),

No, the prototype for malloc is
void *malloc(size_t size);
You are wrong about both the argument type and the return type.

The times of plain K&R are gone significantly more than 20 years ago.

Heed your own words: malloc returning pointer-to char is pre-standard
K&R1 (note the 1). That was closer to 30 years ago.

[Peter Nilsson]

Keith Thompson <[e-mail]:

Peter Nilsson <[e-mail]:

[e-mail] wrote:

Micheal Smith <[e-mail]:
[asking about difference between `ptr = malloc(sizeof(
struct some_struct))' and `ptr = malloc(sizeof(*ptr))']
>
The disadvantage of the first form is that it is up to
the programmer to ensure that the type given in the call
to malloc() agrees with the type in the declaration of
ptr.

Quite so. There is more chance of success with...

* ptr = (struct some_struct *) malloc(sizeof *ptr);

How is the cast helpful?

If the pointer types are not compatible, then a diagnostic
is required. [Sound familiar?]

>*If I inadvertently write
>
struct other_struct *ptr;
>
ptr = malloc(sizeof(struct some_struct));
>
this code is almost certainly not what I want, but the
compiler will not tell me anything is wrong.*On the other
hand, if I use the second form, there is no possibility
of a mismatch,
>
Er... did you jut say no possibility? What about...

* int *ptr; /* int should be long */
* ptr = malloc(*ptr);

The second form can be justifiably preferred, but it is
not foolproof, no method is.

The error is in the declaration of ptr, not in the call
to malloc.

By that logic, casting malloc and forgetting to include
a prototype is not an error in the cast, rather the
absense of the include header or prototype.

--
Peter

[pete]

Peter Nilsson wrote:

Keith Thompson <[e-mail]:

>Peter Nilsson <[e-mail]:

>> ptr = (struct some_struct *) malloc(sizeof *ptr);

How is the cast helpful?

If the pointer types are not compatible, then a diagnostic
is required. [Sound familiar?]

In C, there is no pointer type that requires a cast
when a (void *) type value is being assigned to it.

--
pete

[Martin Ambuhl]

Peter Nilsson wrote:

Keith Thompson <[e-mail]:

>Peter Nilsson <[e-mail]:

>>[e-mail] wrote:
Micheal Smith <[e-mail]:
[asking about difference between `ptr = malloc(sizeof(
struct some_struct))' and `ptr = malloc(sizeof(*ptr))']
The disadvantage of the first form is that it is up to
the programmer to ensure that the type given in the call
to malloc() agrees with the type in the declaration of
ptr.
Quite so. There is more chance of success with...

ptr = (struct some_struct *) malloc(sizeof *ptr);

How is the cast helpful?

If the pointer types are not compatible, then a diagnostic
is required. [Sound familiar?]

malloc returns a void *. There is no pointer type not compatible with
it. Sound familiar? Get a clue.

[Ben Bacarisse]

pete <pf*****@mindspring.comwrites:

Peter Nilsson wrote:

>Keith Thompson <[e-mail]:

>>Peter Nilsson <[e-mail]:

>>> ptr = (struct some_struct *) malloc(sizeof *ptr);
How is the cast helpful?

If the pointer types are not compatible, then a diagnostic
is required. [Sound familiar?]

In C, there is no pointer type that requires a cast
when a (void *) type value is being assigned to it.

Function pointers do. But that is not really the point.

--
Ben.

[pete]

Ben Bacarisse wrote:

pete <pf*****@mindspring.comwrites:

>Peter Nilsson wrote:

>>Keith Thompson <[e-mail]:
Peter Nilsson <[e-mail]:
ptr = (struct some_struct *) malloc(sizeof *ptr);
How is the cast helpful?
If the pointer types are not compatible, then a diagnostic
is required. [Sound familiar?]

In C, there is no pointer type that requires a cast
when a (void *) type value is being assigned to it.

Function pointers do. But that is not really the point.

Conversion from a pointer to void
to a function pointer, is undefined.

--
pete

[Mark L Pappin]

Martin Ambuhl <ma*****@earthlink.netwrites:

Peter Nilsson wrote:

>Keith Thompson <[e-mail]:

>>Peter Nilsson <[e-mail]:
[e-mail] wrote:
Micheal Smith <[e-mail]:
>[asking about difference between `ptr = malloc(sizeof(
>struct some_struct))' and `ptr = malloc(sizeof(*ptr))']
The disadvantage of the first form is that it is up to
the programmer to ensure that the type given in the call
to malloc() agrees with the type in the declaration of
ptr.
Quite so. There is more chance of success with...

ptr = (struct some_struct *) malloc(sizeof *ptr);
How is the cast helpful?

If the pointer types are not compatible, then a diagnostic
is required. [Sound familiar?]

malloc returns a void *. There is no pointer type not compatible with
it. Sound familiar? Get a clue.

Peter's point appears to be: (answering Keith's question) the cast is
helpful because it forces the void* to the type the programmer
believes ptr to be, and if this belief is wrong then a diagnostic will
be emitted; so
ptr = (struct some_struct *) malloc(sizeof *ptr);
has more chance of success than
ptr = malloc(sizeof (struct some_struct *));
when attempting to ensure that the type matches that of ptr.

IMNSHO they are both a bad idea and only the clc-recommended
ptr = malloc(sizeof *ptr);
(or of course
ptr = malloc(N * sizeof *ptr);
if allocating an array rather than a single object, or
ptr = malloc(N);
if ptr is a void* or char*) should be used, because the only thing
that's important at the malloc() call is that the appropriate amount
of storage is requested, and allowing the automatic conversion from
void* to do its job and allowing sizeof to do _its_ job reduces the
cognitive load on the programmer.

mlp

[Ben Bacarisse]

pete <pf*****@mindspring.comwrites:

Ben Bacarisse wrote:

>pete <pf*****@mindspring.comwrites:

>>Peter Nilsson wrote:
Keith Thompson <[e-mail]:
Peter Nilsson <[e-mail]:
> ptr = (struct some_struct *) malloc(sizeof *ptr);
How is the cast helpful?
If the pointer types are not compatible, then a diagnostic
is required. [Sound familiar?]
In C, there is no pointer type that requires a cast
when a (void *) type value is being assigned to it.

Function pointers do. But that is not really the point.

Conversion from a pointer to void
to a function pointer, is undefined.

That may be the intent but the wording of 6.3.2.3 paragraphs 5 and 6
suggests that:

void *vp;
...
void (*fp)(void) = (void (*)(void))(int)vp;

is implementation defined.

--
Ben.

[Eric Sosman]

Peter Nilsson wrote:

Keith Thompson <[e-mail]:

>Peter Nilsson <[e-mail]:

>>[e-mail] wrote:
Micheal Smith <[e-mail]:
[asking about difference between `ptr = malloc(sizeof(
struct some_struct))' and `ptr = malloc(sizeof(*ptr))']
The disadvantage of the first form is that it is up to
the programmer to ensure that the type given in the call
to malloc() agrees with the type in the declaration of
ptr.
Quite so. There is more chance of success with...

ptr = (struct some_struct *) malloc(sizeof *ptr);

How is the cast helpful?

If the pointer types are not compatible, then a diagnostic
is required. [Sound familiar?]

Yes, but how is that helpful?

(Confession: At first glance I made the same mis-reading
I suspect you did. But if on re-reading you still think the
cast is helpful, please explain how and why.)

--
Eric Sosman
es*****@ieee-dot-org.invalid

[pete]

Ben Bacarisse wrote:

pete <pf*****@mindspring.comwrites:

>Ben Bacarisse wrote:

>>pete <pf*****@mindspring.comwrites:

Peter Nilsson wrote:
Keith Thompson <[e-mail]:
>Peter Nilsson <[e-mail]:
>> ptr = (struct some_struct *) malloc(sizeof *ptr);
>How is the cast helpful?
If the pointer types are not compatible, then a diagnostic
is required. [Sound familiar?]
In C, there is no pointer type that requires a cast
when a (void *) type value is being assigned to it.
Function pointers do. But that is not really the point.

Conversion from a pointer to void
to a function pointer, is undefined.

That may be the intent but the wording of 6.3.2.3 paragraphs 5 and 6
suggests that:

void *vp;
...
void (*fp)(void) = (void (*)(void))(int)vp;

is implementation defined.

It says it would be implementation defined
unless it's undefined.

The coversion of an object's address to a function pointer,
seems meaningless to me.
The result of the conversion is useless and
the reversal of the conversion isn't specified
to have any particular value.

--
pete

[Keith Thompson]

pete <pf*****@mindspring.comwrites:

Peter Nilsson wrote:

>Keith Thompson <[e-mail]:

>>Peter Nilsson <[e-mail]:

>>> ptr = (struct some_struct *) malloc(sizeof *ptr);
How is the cast helpful?

If the pointer types are not compatible, then a diagnostic
is required. [Sound familiar?]

In C, there is no pointer type that requires a cast
when a (void *) type value is being assigned to it.

True, but not the point.

Given:

ptr = (struct some_struct *) malloc(sizeof *ptr);

the conversion from void* to struct some_struct* obviously does not
require a diagnostic -- not because the source type is void*, but
because the conversion is specified by a cast.

The assignment, however, does require a diagnostic if ptr is not of a
type compatible with struct some_struct*.

Consider this (incorrect) program:

#include <stdlib.h>
int main(void)
{
int *ptr;
ptr = (int*)malloc(sizeof *ptr);
return 0;
}

The int* cast documents the fact that ptr is of type int* (or possibly
of type void*). If, during later maintence, we change the type of
ptr:

#include <stdlib.h>
int main(void)
{
unsigned int *ptr;
ptr = (int*)malloc(sizeof *ptr);
return 0;
}

then the compiler will remind us to update the cast by issuing a
required diagnostic for the attempt to assign an int* value to an
unsigned int* object.

This may be the best argument I've seen in favor of casting the result
of malloc (except perhaps for the rare requirement to compile the same
code as both C and C++).

On the other hand, given the usual clc idiom:

ptr = malloc(sizeof *ptr);

there's no need to update the statement if the type of ptr is changed;
there's no error for the compiler to warn us about.

On the other other hand, without the cast we can't easily tell what
type ptr has.

On the other**3 hand, we don't need to know that to determine that the
statement is correct (and, as somebody will probably jump in and point
out, any decent IDE should let us jump to the declaration of ptr).

I'm still not convinced. The suggested
ptr = (type*)malloc(sizeof *ptr);
is an even rarer idiom than the clc-approved
ptr = malloc(sizeof *ptr);
and I'm not sure I'd trust maintenance programmers to get it right.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Anand Hariharan]

On Aug 26, 3:47*am, Richard<[e-mail]:

Ian Collins <[e-mail]:

Richard wrote:

Martin Ambuhl <[e-mail]:

>Peter Nilsson wrote:

>>Quite so. There is more chance of success with...

>>* ptr = (struct some_struct *) malloc(sizeof *ptr);
* * * * * *^^^^^^^^^^^^^^^^^^^^^

>The case is unnecessary, as well as poor programing practice in C.

(...)

>
Less ribbing and more seriously - how many times have you seen these
casts actually conceal a problem in the real world? The reason I ask is
that I have seen these casts in literally thousands of lines of code in
perfectly working systems that I have been contracted in to
enhance/maintain for a period of time.

I agree. There is plenty of code that cast the pointer returned by
malloc. There are two reasons for this.

First is that there are people who think C++ is just C with some more
stuff thrown in. Using malloc in C++ requires a cast (and people who
write C in C++ code don't use the C++ casts).

The second is more important. There are very few good C books. Even
the text that is considered definitive (K&R) cast malloc's pointer.
Very many of the "Everybody does it, so it can't be wrong" arguments
wouldn't exist if the dangers of UB (and how easy it is to write code
that has UB) were shown early on while learning C.

- Anand

[Keith Thompson]

Anand Hariharan <ma********************@gmail.comwrites:
[...]

The second is more important. There are very few good C books. Even
the text that is considered definitive (K&R) cast malloc's pointer.
Very many of the "Everybody does it, so it can't be wrong" arguments
wouldn't exist if the dangers of UB (and how easy it is to write code
that has UB) were shown early on while learning C.

I think the errata list at
<http://plan9.bell-labs.com/cm/cs/cbook/2ediffs.htmlcorrects this.
(I can't access the web page at the moment, so I can't be sure exactly
what it says.)

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[pete]

Keith Thompson wrote:

Anand Hariharan <ma********************@gmail.comwrites:
[...]

>The second is more important. There are very few good C books. Even
the text that is considered definitive (K&R) cast malloc's pointer.
Very many of the "Everybody does it, so it can't be wrong" arguments
wouldn't exist if the dangers of UB (and how easy it is to write code
that has UB) were shown early on while learning C.

I think the errata list at
<http://plan9.bell-labs.com/cm/cs/cbook/2ediffs.htmlcorrects this.
(I can't access the web page at the moment, so I can't be sure exactly
what it says.)

I can't access the web at this moment.

--
pete

[vippstar]

On Aug 27, 9:09 am, Keith Thompson <[e-mail]:

Anand Hariharan <[e-mail]:

[...]

The second is more important. There are very few good C books. Even
the text that is considered definitive (K&R) cast malloc's pointer.
Very many of the "Everybody does it, so it can't be wrong" arguments
wouldn't exist if the dangers of UB (and how easy it is to write code
that has UB) were shown early on while learning C.

I think the errata list at
<http://plan9.bell-labs.com/cm/cs/cbook/2ediffs.htmlcorrects this.
(I can't access the web page at the moment, so I can't be sure exactly
what it says.)

I also can't open the web page.
However, google has cached it:
<http://209.85.135.104/search?q=cache...bell-labs.com/
cm/cs/cbook/2ediffs.html+http://plan9.bell-labs.com/cm/cs/cbook/
2ediffs.html&hl=en&ct=clnk&cd=1>

[REH]

On Aug 26, 1:58*pm, Flash Gordon <[e-mail]:

I've used Pascal derivative for low-level programming including embedded
systems development. I've known people to do it in ADA. I came across
one computer where the OS was developed in Forth. I'm sure it is done in
other languages as well.

Just a nit: it's "Ada."

REH

[Peter Nilsson]

Martin Ambuhl <[e-mail]:

Peter Nilsson wrote:

<snip>

malloc returns a void *.*There is no pointer type not
compatible with it. Sound familiar? Get a clue.

It sounds like a lie that's been repeated so often it's
got the status of fact.

The only compatible type to void * is void *.

--
Peter

[Peter Nilsson]

Keith Thompson <[e-mail]:

Anand Hariharan <[e-mail]:

The second is more important. *There are very few good C
books. *Even the text that is considered definitive (K&R)
cast malloc's pointer. Very many of the "Everybody does
it, so it can't be wrong" arguments wouldn't exist if the
dangers of UB (and how easy it is to write code that has
UB) were shown early on while learning C.

I think the errata list at
<http://plan9.bell-labs.com/cm/cs/cbook/2ediffs.html>
corrects this.
(I can't access the web page at the moment, so I can't be
sure exactly what it says.)

<http://www-db-out.research.bell-labs.com/cm/cs/cbook/2ediffs.html>

Quote:

142(S6.5, toward the end): The remark about casting the
return value of malloc ("the proper method is to declare
... then explicitly coerce") needs to be rewritten. The
example is correct and works, but the advice is debatable
in the context of the 1988-1989 ANSI/ISO standards. It's
not necessary (given that coercion of void * to
ALMOSTANYTYPE * is automatic), and possibly harmful if
malloc, or a proxy for it, fails to be declared as
returning void *. The explicit cast can cover up an
unintended error. On the other hand, pre-ANSI, the cast
was necessary, and it is in C++ also.

It's surprising how some people seem to have interpreted
"The example is correct and works" as somehow meaning the
example is incorrect and doesn't.

--
Peter

[Richard Heathfield]

Peter Nilsson said:

<snip>

<http://www-db-out.research.bell-labs.com/cm/cs/cbook/2ediffs.html>

Quote:

142(S6.5, toward the end): The remark about casting the
return value of malloc ("the proper method is to declare
... then explicitly coerce") needs to be rewritten. The
example is correct and works, but the advice is debatable
in the context of the 1988-1989 ANSI/ISO standards.

<snip>

>
It's surprising how some people seem to have interpreted
"The example is correct and works" as somehow meaning the
example is incorrect and doesn't.

On the other hand, it's not surprising that some people take the position
that, *although* the example is correct and works, it is poor style, is
maintenance-intensive, and can hide (not *cause*, but *hide*) a subtle
bug.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Martin Ambuhl]

Peter Nilsson wrote:

Martin Ambuhl <[e-mail]:

>Peter Nilsson wrote:

>><snip>

malloc returns a void *. There is no pointer type not
compatible with it. Sound familiar? Get a clue.

It sounds like a lie that's been repeated so often it's
got the status of fact.

The only compatible type to void * is void *.

Having proven your ignorance and your trolldom, you may now enter my
killfile.

[Richard Heathfield]

Martin Ambuhl said:

Peter Nilsson wrote:

>Martin Ambuhl <[e-mail]:

>>Peter Nilsson wrote:
<snip>
malloc returns a void *. There is no pointer type not
compatible with it. Sound familiar? Get a clue.

It sounds like a lie that's been repeated so often it's
got the status of fact.

The only compatible type to void * is void *.

Having proven your ignorance and your trolldom, you may now enter my
killfile.

My curiosity has overcome my reluctance to display my own ignorance. I have
read through the Standard, looking for information about the compatibility
of void * with other types, and I can't find any. I *did* find the bit
about it being okay to convert any object pointer or incomplete pointer to
void * and back without loss of information - which sure *sounds* like
compatibility - but the Standard does not explicitly state that it *is*
compatibility.

What have I missed?

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Keith Thompson]

Peter Nilsson <ai***@acay.com.auwrites:

Martin Ambuhl <[e-mail]:

>Peter Nilsson wrote:

<snip>

malloc returns a void *.*There is no pointer type not
compatible with it. Sound familiar? Get a clue.

It sounds like a lie that's been repeated so often it's
got the status of fact.

The only compatible type to void * is void *.

It's not a lie, just a misunderstanding of the meaning of "compatible
types".

void* and int*, for example, can be assigned to each other without a
cast. This permission doesn't come from them being compatible types
(they're not); it's specifically stated in the discussion on simple
assignment (which then applies indirectly to initialization and
argument passing).

It's easy to make the mistake of assuming that types that can be
assigned to each other are "compatible"; that just doesn't happen to
be the way the standard uses the term.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

Martin Ambuhl <ma*****@earthlink.netwrites:

Peter Nilsson wrote:

>Martin Ambuhl <[e-mail]:

>>Peter Nilsson wrote:
<snip>
malloc returns a void *. There is no pointer type not
compatible with it. Sound familiar? Get a clue.

It sounds like a lie that's been repeated so often it's
got the status of fact.
The only compatible type to void * is void *.

Having proven your ignorance and your trolldom, you may now enter my
killfile.

You might want to reconsider. Though I think he overstated the case,
it's true that void* is not compatible with any other pointer type, in
the way that the standard defines the word "compatible". See my other
response.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[pete]

Richard Heathfield wrote:

Martin Ambuhl said:

>Peter Nilsson wrote:

>>Martin Ambuhl <[e-mail]:
Peter Nilsson wrote:
<snip>
malloc returns a void *. There is no pointer type not
compatible with it. Sound familiar? Get a clue.
It sounds like a lie that's been repeated so often it's
got the status of fact.

The only compatible type to void * is void *.

Having proven your ignorance and your trolldom, you may now enter my
killfile.

My curiosity has overcome my reluctance to display my own ignorance. I have
read through the Standard, looking for information about the compatibility
of void * with other types, and I can't find any. I *did* find the bit
about it being okay to convert any object pointer or incomplete pointer to
void * and back without loss of information - which sure *sounds* like
compatibility - but the Standard does not explicitly state that it *is*
compatibility.

What have I missed?

You missed the part of the thread that had been snipped,
in which

Peter Nilsson wrote:
ptr = (struct some_struct *) malloc(sizeof *ptr);
and Keith Thompson asked:
How is the cast helpful?
and Peter Nilsson replied:
If the pointer types are not compatible,
then a diagnostic is required. [Sound familiar?]

because Peter Nilsson didn't know what he was talking about.

--
pete

[Richard Heathfield]

pete said:

Richard Heathfield wrote:

<snip>

>>
What have I missed?

You missed the part of the thread that had been snipped,

You're right. That's precisely what I missed.

in which

Peter Nilsson wrote:
ptr = (struct some_struct *) malloc(sizeof *ptr);
and Keith Thompson asked:
How is the cast helpful?
and Peter Nilsson replied:
If the pointer types are not compatible,
then a diagnostic is required. [Sound familiar?]

because Peter Nilsson didn't know what he was talking about.

Um, perhaps so. But might he not have meant that, if ptr is of some type
that is not void * and also is not struct some_struct *, a diagnostic
message would be required, and that he considers this beneficial? It would
be a sort of compile-time assertion that ptr has type struct some_struct
*, yes? I don't say I agree with that by any means (and in fact I don't
think I'm telling you anything new when I say that I consider the castless
version is better style and more robust), but it seems to me that it
needn't necessarily be ignorance or trolling that led him to that
conclusion. It might just be an alternative point of view, and it seems to
me that it's a defensible one, although I don't happen to agree with it
myself.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999