Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Re: Pointer dereference rather than sizeof?

Reply
Thread Tools

Re: Pointer dereference rather than sizeof?

 
 
Martin Ambuhl
Guest
Posts: n/a
 
      08-25-2008
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.

 
Reply With Quote
 
 
 
 
fjblurt@yahoo.com
Guest
Posts: n/a
 
      08-25-2008
On Aug 24, 8:59 pm, Micheal Smith <(E-Mail Removed)> wrote:
> [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.
 
Reply With Quote
 
 
 
 
Peter Nilsson
Guest
Posts: n/a
 
      08-26-2008
(E-Mail Removed) wrote:
> Micheal Smith <(E-Mail Removed)> wrote:
> > [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
 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      08-26-2008
Peter Nilsson <(E-Mail Removed)> writes:
> (E-Mail Removed) wrote:
>> Micheal Smith <(E-Mail Removed)> wrote:
>> > [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) http://www.velocityreviews.com/forums/(E-Mail Removed) <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"
 
Reply With Quote
 
Martin Ambuhl
Guest
Posts: n/a
 
      08-26-2008
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.
 
Reply With Quote
 
Richard
Guest
Posts: n/a
 
      08-26-2008
Martin Ambuhl <(E-Mail Removed)> writes:

> 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 .....
 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      08-26-2008
Richard wrote:
> Martin Ambuhl <(E-Mail Removed)> writes:
>
>> 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 *******s. The cast is superfluous error concealing clutter.

--
Ian Collins.
 
Reply With Quote
 
Richard
Guest
Posts: n/a
 
      08-26-2008
Ian Collins <(E-Mail Removed)> writes:

> Richard wrote:
>> Martin Ambuhl <(E-Mail Removed)> writes:
>>
>>> 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 *******s. 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.

 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      08-26-2008
Richard wrote:
> Ian Collins <(E-Mail Removed)> writes:
>
>> 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 *******s. 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.
 
Reply With Quote
 
Richard Tobin
Guest
Posts: n/a
 
      08-26-2008
In article <g90fvi$bri$(E-Mail Removed)>,
Richard <(E-Mail Removed)> wrote:

>>> ... 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 *******s. 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.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Pointer dereference rather than sizeof? Keith Thompson C Programming 8 09-03-2008 01:36 PM
pointer dereference somenath C Programming 12 08-10-2007 05:16 PM
pointer dereference somenath C Programming 34 07-18-2007 01:33 PM
Can't dereference pointer to stack? TuAmigoFiel@gmail.com C++ 9 02-11-2006 06:31 AM
NULL Pointer Dereference Denis Palmeiro C Programming 10 07-16-2003 12:33 PM



Advertisments