Re: Pointer dereference rather than sizeof?

Discussion in 'C Programming' started by Martin Ambuhl, Aug 25, 2008.

  1. 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.
     
    Martin Ambuhl, Aug 25, 2008
    #1
    1. Advertising

  2. Martin Ambuhl

    Guest

    On Aug 24, 8:59 pm, Micheal Smith <> 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.
     
    , Aug 25, 2008
    #2
    1. Advertising

  3. wrote:
    > Micheal Smith <> 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
     
    Peter Nilsson, Aug 26, 2008
    #3
  4. Peter Nilsson <> writes:
    > wrote:
    >> Micheal Smith <> 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.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, Aug 26, 2008
    #4
  5. 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.
     
    Martin Ambuhl, Aug 26, 2008
    #5
  6. Martin Ambuhl

    Richard Guest

    Martin Ambuhl <> 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 .....
     
    Richard, Aug 26, 2008
    #6
  7. Martin Ambuhl

    Ian Collins Guest

    Richard wrote:
    > Martin Ambuhl <> 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 bollocks. The cast is superfluous error concealing clutter.

    --
    Ian Collins.
     
    Ian Collins, Aug 26, 2008
    #7
  8. Martin Ambuhl

    Richard Guest

    Ian Collins <> writes:

    > Richard wrote:
    >> Martin Ambuhl <> 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 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.
     
    Richard, Aug 26, 2008
    #8
  9. Martin Ambuhl

    Ian Collins Guest

    Richard wrote:
    > Ian Collins <> 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 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.
     
    Ian Collins, Aug 26, 2008
    #9
  10. In article <g90fvi$bri$>,
    Richard <> 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 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 Tobin, Aug 26, 2008
    #10
  11. Martin Ambuhl

    Richard Guest

    Ian Collins <> writes:

    > Richard wrote:
    >> Ian Collins <> 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 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, Aug 26, 2008
    #11
  12. On Tue, 26 Aug 2008 07:28:01 UTC, Peter Nilsson <>
    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, Aug 26, 2008
    #12
  13. On Tue, 26 Aug 2008 08:39:12 UTC, Richard<> wrote:

    > Martin Ambuhl <> 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 .....



    there is only one single type of malloc: char *malloc(int), But
    leaving of to #include ystdlib.h> gets 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, Aug 26, 2008
    #13
  14. On Tue, 26 Aug 2008 08:47:34 UTC, Richard<> wrote:

    > Ian Collins <> writes:
    >
    > > Richard wrote:
    > >> Martin Ambuhl <> 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 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!
     
    Herbert Rosenau, Aug 26, 2008
    #14
  15. 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.
     
    Martin Ambuhl, Aug 26, 2008
    #15
  16. Keith Thompson <> wrote:
    > Peter Nilsson <> writes:
    > > wrote:
    > > > Micheal Smith <> 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 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
     
    Peter Nilsson, Aug 26, 2008
    #16
  17. Peter Nilsson wrote:
    > Keith Thompson <> wrote:
    >> Peter Nilsson <> writes:
    >>> wrote:
    >>>> Micheal Smith <> 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 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.
     
    Martin Ambuhl, Aug 27, 2008
    #17
  18. pete <> writes:

    > Peter Nilsson wrote:
    >> Keith Thompson <> wrote:
    >>> Peter Nilsson <> writes:

    >
    >>>> 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.
     
    Ben Bacarisse, Aug 27, 2008
    #18
  19. Martin Ambuhl <> writes:

    > Peter Nilsson wrote:
    >> Keith Thompson <> wrote:
    >>> Peter Nilsson <> writes:
    >>>> wrote:
    >>>>> Micheal Smith <> 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 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
     
    Mark L Pappin, Aug 27, 2008
    #19
  20. pete <> writes:

    > Ben Bacarisse wrote:
    >> pete <> writes:
    >>
    >>> Peter Nilsson wrote:
    >>>> Keith Thompson <> wrote:
    >>>>> Peter Nilsson <> writes:
    >>>>>> 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.
     
    Ben Bacarisse, Aug 27, 2008
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Denis Palmeiro

    NULL Pointer Dereference

    Denis Palmeiro, Jul 8, 2003, in forum: C Programming
    Replies:
    10
    Views:
    677
    Shill
    Jul 16, 2003
  2. Replies:
    9
    Views:
    560
    Bo Persson
    Feb 11, 2006
  3. somenath

    pointer dereference

    somenath, Jul 12, 2007, in forum: C Programming
    Replies:
    34
    Views:
    940
    Anurag
    Jul 18, 2007
  4. Alex Vinokur

    sizeof (size_t) and sizeof (pointer)

    Alex Vinokur, Nov 12, 2007, in forum: C++
    Replies:
    19
    Views:
    799
    Ben Rudiak-Gould
    Nov 30, 2007
  5. Keith Thompson

    Re: Pointer dereference rather than sizeof?

    Keith Thompson, Aug 25, 2008, in forum: C Programming
    Replies:
    8
    Views:
    668
    Bill Reid
    Sep 3, 2008
Loading...

Share This Page