Re: Pointer dereference rather than sizeof?

Discussion in 'C Programming' started by Keith Thompson, Aug 25, 2008.

  1. Micheal Smith <> writes:
    > 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) <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 25, 2008
    #1
    1. Advertising

  2. Keith Thompson

    Bill Reid Guest

    Keith Thompson <> wrote in message
    news:...
    > Micheal Smith <> writes:


    > > 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
    Bill Reid, Aug 26, 2008
    #2
    1. Advertising

  3. On 26 Aug, 01:48, "Bill Reid" <> wrote:
    > Keith Thompson <> wrote in message
    > news:...


    <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
    Nick Keighley, Aug 26, 2008
    #3
  4. Keith Thompson

    Richard Bos Guest

    Nick Keighley <> wrote:

    > On 26 Aug, 01:48, "Bill Reid" <> wrote:
    > > 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
    Richard Bos, Aug 26, 2008
    #4
  5. Keith Thompson

    Bartc Guest

    Nick Keighley wrote:
    > On 26 Aug, 01:48, "Bill Reid" <> wrote:


    >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
    Bartc, Aug 26, 2008
    #5
  6. On 26 Aug, 11:44, (Richard Bos) wrote:
    > Nick Keighley <> wrote:
    > > On 26 Aug, 01:48, "Bill Reid" <> wrote:


    > > > 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
    Nick Keighley, Aug 26, 2008
    #6
  7. Keith Thompson

    Flash Gordon Guest

    Bartc wrote, On 26/08/08 12:32:
    > Nick Keighley wrote:
    >> On 26 Aug, 01:48, "Bill Reid" <> wrote:

    >
    >> 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
    Flash Gordon, Aug 26, 2008
    #7
  8. Keith Thompson

    REH Guest

    On Aug 26, 1:58 pm, Flash Gordon <> wrote:
    > 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
    REH, Aug 27, 2008
    #8
  9. Keith Thompson

    Bill Reid Guest

    Richard Bos <> wrote in message
    news:4all.nl...
    > Nick Keighley <> wrote:
    > > On 26 Aug, 01:48, "Bill Reid" <> wrote:


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


    Close! JavaScript!!!

    ---
    William Ernest Reid
    Bill Reid, Sep 3, 2008
    #9
    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:
    651
    Shill
    Jul 16, 2003
  2. Replies:
    9
    Views:
    543
    Bo Persson
    Feb 11, 2006
  3. somenath

    pointer dereference

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

    sizeof (size_t) and sizeof (pointer)

    Alex Vinokur, Nov 12, 2007, in forum: C++
    Replies:
    19
    Views:
    777
    Ben Rudiak-Gould
    Nov 30, 2007
  5. Martin Ambuhl

    Re: Pointer dereference rather than sizeof?

    Martin Ambuhl, Aug 25, 2008, in forum: C Programming
    Replies:
    67
    Views:
    1,907
    Tim Rentsch
    Oct 9, 2008
Loading...

Share This Page