473,898 Members | 3,709 Online
Bytes | Software Development & Data Engineering Community
+ Post

Home Posts Topics Members FAQ

Pointer dereference rather than sizeof?

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(s truct 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.

Aug 25 '08
98 6478
Martin Ambuhl <ma*****@earthl ink.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 .....
Aug 26 '08 #11
Richard wrote:
Martin Ambuhl <ma*****@earthl ink.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.
Aug 26 '08 #12
Ian Collins <ia******@hotma il.comwrites:
Richard wrote:
>Martin Ambuhl <ma*****@earthl ink.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,0 00 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.

Aug 26 '08 #13
On 26 Aug, 01:48, "Bill Reid" <hormelf...@hap pyhealthy.netwr ote:
Keith Thompson <ks...@mib.orgw rote in message
news:ln******** ****@nuthaus.mi b.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
Aug 26 '08 #14
Richard wrote:
Ian Collins <ia******@hotma il.comwrites:
>Richard wrote:
>>We all hear this time and time again because of some almost impossible,
manufacture d 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.
Aug 26 '08 #15
In article <g9**********@r egistered.motza rella.org>,
Richard <rg****@gmail.c omwrote:
>>... 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.
Aug 26 '08 #16
Ian Collins <ia******@hotma il.comwrites:
Richard wrote:
>Ian Collins <ia******@hotma il.comwrites:
>>Richard wrote:
>>>We all hear this time and time again because of some almost impossible,
manufactur ed 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?
Aug 26 '08 #17
Nick Keighley <ni************ ******@hotmail. comwrote:
On 26 Aug, 01:48, "Bill Reid" <hormelf...@hap pyhealthy.netwr ote:
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
Aug 26 '08 #18
Nick Keighley wrote:
On 26 Aug, 01:48, "Bill Reid" <hormelf...@hap pyhealthy.netwr ote:
>discussing
ptr = malloc (sizeof *ptr)
>"It's completely friggin' impossible to learn all the bass-ackwards
and semi-sideways inconsistent methods of declaring and
dereferencin g 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

Aug 26 '08 #19
On 26 Aug, 11:44, r...@hoekstra-uitgeverij.nl (Richard Bos) wrote:
Nick Keighley <nick_keighley_ nos...@hotmail. comwrote:
On 26 Aug, 01:48, "Bill Reid" <hormelf...@hap pyhealthy.netwr ote:
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
Aug 26 '08 #20

This thread has been closed and replies have been disabled. Please start a new discussion.

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.