Re: pointer doubt (1)

Discussion in 'C Programming' started by John Gordon, May 8, 2013.

  1. John Gordon

    John Gordon Guest

    In <kme6j2$6ue$> rashan <> writes:

    > Can ne1 explain me the difference between.... a NULL pointer ... and a
    > VOID pointer.


    > With Many Thanks.


    NULL is a pointer value.

    Void is a pointer type.

    When NULL is assigned to a pointer, it typically indicates that the pointer
    hasn't been initialized or doesn't point anywhere. On many implementations
    the actual value of NULL is zero.

    Pointers of type void can be converted to or from any other pointer type.
    This is useful when you don't know in advance what type will be needed,
    for example the malloc() function.

    --
    John Gordon A is for Amy, who fell down the stairs
    B is for Basil, assaulted by bears
    -- Edward Gorey, "The Gashlycrumb Tinies"
     
    John Gordon, May 8, 2013
    #1
    1. Advertising

  2. John Gordon <> writes:
    > In <kme6j2$6ue$> rashan <> writes:
    >> Can ne1 explain me the difference between.... a NULL pointer ... and a
    >> VOID pointer.

    >
    > NULL is a pointer value.


    Close enough. To be pedantic, NULL is a macro that expands to an
    implementation-defined null pointer constant; assigning NULL to a
    pointer object results in that pointer taking on a null pointer value.
    NULL appears in source code; a null pointer value exists during program
    execution.

    > Void is a pointer type.


    "Void" is an arbitrary identifer. "void" is a keyword, and a name for a
    predefined incomplete type, not a pointer type. "void*" is a pointer
    type.

    > When NULL is assigned to a pointer, it typically indicates that the pointer
    > hasn't been initialized or doesn't point anywhere. On many implementations
    > the actual value of NULL is zero.


    The pointer *has* been initialized, but to a value that doesn't point to
    anything.

    > Pointers of type void can be converted to or from any other pointer type.


    Quibble: void* pointers cannot be portably converted to or from function
    pointer types.

    > This is useful when you don't know in advance what type will be needed,
    > for example the malloc() function.


    There are actually two distinct rules in play here. One is that an
    arbitrary object pointer can be converted to void* and back again
    without loss of information. malloc() in particular is guaranteed to
    return a pointer that, when converted, is properly aligned to point to
    any object type (that's not true of void* pointers in general).

    The other is that conversion to and from void* can be done implicitly,
    with no cast.

    These rules together make things like:

    int *ptr = malloc(42 * sizeof *ptr);

    possible.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Working, but not speaking, for JetHead Development, Inc.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, May 8, 2013
    #2
    1. Advertising

  3. On 08.05.2013 22:10, Keith Thompson wrote:

    >> NULL is a pointer value.

    >
    > Close enough. To be pedantic, NULL is a macro that expands to an
    > implementation-defined null pointer constant;


    [...]

    >> When NULL is assigned to a pointer, it typically indicates that the pointer
    >> hasn't been initialized or doesn't point anywhere. On many implementations
    >> the actual value of NULL is zero.

    >
    > The pointer *has* been initialized, but to a value that doesn't point to
    > anything.


    I don't understand why you nitpick the difference between compile- and
    runtime, but then say that "NULL" doesn't point to anything. To be
    pedantic, NULL points to an implementation-defined location (as you
    yourself wrote). What the results of dereferencing that location are is
    implementation-defined. How is that "nothing"?

    Regards,
    Johannes

    --
    >> Wo hattest Du das Beben nochmal GENAU vorhergesagt?

    > Zumindest nicht öffentlich!

    Ah, der neueste und bis heute genialste Streich unsere großen
    Kosmologen: Die Geheim-Vorhersage.
    - Karl Kaos über Rüdiger Thomas in dsa <hidbv3$om2$>
     
    Johannes Bauer, May 13, 2013
    #3
  4. Johannes Bauer <> wrote:

    (snip)
    >> The pointer *has* been initialized, but to a value that doesn't point to
    >> anything.


    > I don't understand why you nitpick the difference between compile- and
    > runtime, but then say that "NULL" doesn't point to anything. To be
    > pedantic, NULL points to an implementation-defined location (as you
    > yourself wrote). What the results of dereferencing that location are is
    > implementation-defined. How is that "nothing"?


    For some systems, a specific address, usually zero, is reserved by the
    software, but is otherwise a valid address. Some libraries test at the
    end that the same value is still stored there, and give a message if the
    value has changed. The null pointer does point somewhere, but you aren't
    supposed to do anything there.

    For protected mode x86 (starting with the 80286), segment selector zero
    is reserved by the hardware as the null segment selector. There is no
    segment descriptor for selector zero. That is the way the hardware
    works.

    -- glen
     
    glen herrmannsfeldt, May 13, 2013
    #4
  5. John Gordon

    James Kuyper Guest

    On 05/13/2013 06:09 AM, Johannes Bauer wrote:
    > On 08.05.2013 22:10, Keith Thompson wrote:
    >
    >>> NULL is a pointer value.

    >>
    >> Close enough. To be pedantic, NULL is a macro that expands to an
    >> implementation-defined null pointer constant;

    >
    > [...]
    >
    >>> When NULL is assigned to a pointer, it typically indicates that the pointer
    >>> hasn't been initialized or doesn't point anywhere. On many implementations
    >>> the actual value of NULL is zero.

    >>
    >> The pointer *has* been initialized, but to a value that doesn't point to
    >> anything.

    >
    > I don't understand why you nitpick the difference between compile- and
    > runtime, but then say that "NULL" doesn't point to anything. To be
    > pedantic, NULL points to an implementation-defined location (as you
    > yourself wrote). ...


    The NULL macro expands to an implementation-defined null pointer
    constant (7.19p3). That means it's implementation-defined whether that
    constant is 0, '\0', 0ULL, (3-3), (void*)(2/3), or any other null
    pointer constant. That doesn't mean the location it points at is
    implementation-defined.

    When a null pointer constant is converted to a pointer type, the result
    is a null pointer. How that pointer is represented is up to each
    implementor to decide, but it is not implementation-defined. That means
    that the implementation has no obligation to document it. Even if it
    were implementation-defined, it would not necessarily be a pointer
    pointing at an implementation-defined location. It could also be a
    pointer that is invalid, as far as the hardware is concerned, pointing
    nowhere.

    A null pointer is prohibited from comparing equal to a pointer to any
    object or function (6.3.2.3p3). In practice, a null pointer is often
    (but not always) represented by something that would, if dereferenced,
    behave as an ordinary pointer retrieving it's value from whatever is
    currently stored in a specific location in memory - but that's not
    required by the standard.

    > ... What the results of dereferencing that location are is
    > implementation-defined. How is that "nothing"?


    Those results are not implementation-defined, they are undefined. That's
    not "nothing", it's everything. A program that dereferences a null
    pointer has behavior that is not constrained in any way by the C
    standard. That means, in particular, that the behavior need not take a
    form that could be interpreted as indicating that the null pointer was
    merely an ordinary pointer pointing at a unspecified location in memory
    (though that, in itself, would be sufficient to cause fatally sever
    problems, depending upon the type being pointed at, and the contents of
    the unspecified memory location).
    --
    James Kuyper
     
    James Kuyper, May 13, 2013
    #5
  6. John Gordon

    James Kuyper Guest

    On 05/13/2013 06:09 AM, Johannes Bauer wrote:
    > On 08.05.2013 22:10, Keith Thompson wrote:
    >
    >>> NULL is a pointer value.

    >>
    >> Close enough. To be pedantic, NULL is a macro that expands to an
    >> implementation-defined null pointer constant;

    >
    > [...]
    >
    >>> When NULL is assigned to a pointer, it typically indicates that the pointer
    >>> hasn't been initialized or doesn't point anywhere. On many implementations
    >>> the actual value of NULL is zero.

    >>
    >> The pointer *has* been initialized, but to a value that doesn't point to
    >> anything.

    >
    > I don't understand why you nitpick the difference between compile- and
    > runtime, but then say that "NULL" doesn't point to anything. To be
    > pedantic, NULL points to an implementation-defined location (as you
    > yourself wrote). ...


    The NULL macro expands to an implementation-defined null pointer
    constant (7.19p3). That means it's implementation-defined whether that
    constant is 0, '\0', 0ULL, (3-3), (void*)(2/3), or any other null
    pointer constant. That doesn't mean the location it points at is
    implementation-defined.

    When a null pointer constant is converted to a pointer type, the result
    is a null pointer. How that pointer is represented is up to each
    implementor to decide, but it is not implementation-defined. That means
    that the implementation has no obligation to document it. Even if it
    were implementation-defined, it would not necessarily be a pointer
    pointing at an implementation-defined location. It could also be a
    pointer that is invalid, as far as the hardware is concerned, pointing
    nowhere.

    A null pointer is prohibited from comparing equal to a pointer to any
    object or function (6.3.2.3p3). In practice, a null pointer is often
    (but not always) represented by something that would, if dereferenced,
    behave as an ordinary pointer retrieving it's value from whatever is
    currently stored in a specific location in memory - but that's not
    required by the standard.

    > ... What the results of dereferencing that location are is
    > implementation-defined. How is that "nothing"?


    Those results are not implementation-defined, they are undefined. That's
    not "nothing", it's everything. A program that dereferences a null
    pointer has behavior that is not constrained in any way by the C
    standard. That means, in particular, that the behavior need not take a
    form that could be interpreted as indicating that the null pointer was
    merely an ordinary pointer pointing at a unspecified location in memory
    (though that, in itself, would be sufficient to cause fatally sever
    problems, depending upon the type being pointed at, and the contents of
    the unspecified memory location).
    --
    James Kuyper
     
    James Kuyper, May 13, 2013
    #6
  7. John Gordon

    Eric Sosman Guest

    On 5/13/2013 6:09 AM, Johannes Bauer wrote:
    > On 08.05.2013 22:10, Keith Thompson wrote:
    >
    >>> NULL is a pointer value.

    >>
    >> Close enough. To be pedantic, NULL is a macro that expands to an
    >> implementation-defined null pointer constant;

    >
    > [...]
    >
    >>> When NULL is assigned to a pointer, it typically indicates that the pointer
    >>> hasn't been initialized or doesn't point anywhere. On many implementations
    >>> the actual value of NULL is zero.

    >>
    >> The pointer *has* been initialized, but to a value that doesn't point to
    >> anything.

    >
    > I don't understand why you nitpick the difference between compile- and
    > runtime, but then say that "NULL" doesn't point to anything. To be
    > pedantic, NULL points to an implementation-defined location (as you
    > yourself wrote). What the results of dereferencing that location are is
    > implementation-defined. How is that "nothing"?


    To be pedantic, NULL is a macro. During compilation, it
    expands to a /null pointer constant/. Oddly enough, the value
    of an NPC is not necessarily a pointer at all! It can, however,
    be converted to a pointer type, and the conversion produces a
    /null pointer/. Unless I've missed something, there are only
    three guarantees about a null pointer:

    - It "is guaranteed to compare unequal to a pointer to any
    object or function" (6.3.2.3p3).

    - Converting a type A* null pointer to type B* produces a
    null pointer of type B* (6.3.2.3p4).

    - "Any two null pointers shall compare equal" (6.3.2.3p4 again).

    Nowhere is it required or even suggested that a null pointer
    (or NULL) points anywhere or to anything, nor is the effect of a
    dereference implementation-defined (it is /undefined behavior/,
    which an implementation is permitted but not obligated to define;
    /implementation-defined behavior/, on the other hand, requires a
    definition).

    As far as I can see, the only implementation-defined feature
    of NULL is the precise form of null pointer constant to which it
    expands. The Standard describes some forms like `0' and `(void*)0'
    and `(5/9)' that qualify as null pointer constants, but the NULL
    macro might expand to, say, `__builtin_nil'. Such a spelling might
    enable a compiler to produce better diagnostics for suspicious
    constructs like `char ptr = NULL;' than if NULL expanded to plain
    `0', but does not affect the meaning of the code (if any).

    --
    Eric Sosman
    d
     
    Eric Sosman, May 13, 2013
    #7
  8. Johannes Bauer <> writes:
    > On 08.05.2013 22:10, Keith Thompson wrote:
    >>> NULL is a pointer value.

    >>
    >> Close enough. To be pedantic, NULL is a macro that expands to an
    >> implementation-defined null pointer constant;

    >
    > [...]
    >
    >>> When NULL is assigned to a pointer, it typically indicates that the pointer
    >>> hasn't been initialized or doesn't point anywhere. On many implementations
    >>> the actual value of NULL is zero.

    >>
    >> The pointer *has* been initialized, but to a value that doesn't point to
    >> anything.

    >
    > I don't understand why you nitpick the difference between compile- and
    > runtime, but then say that "NULL" doesn't point to anything. To be
    > pedantic, NULL points to an implementation-defined location (as you
    > yourself wrote). What the results of dereferencing that location are is
    > implementation-defined. How is that "nothing"?


    As long as we're being pedantic, NULL is an identifier, defined
    as a macro if any of certain standard headers are included, that
    expands to a null pointer constant. Both NULL and null pointer
    constants exist only in C source code. A null pointer *value*
    can exist during execution. I didn't say that NULL doesn't point
    to anything, I said that a null pointer doesn't point to anything.

    You say that I wrote that a null pointer points to an
    implementation-defined location. It does not, and I never said
    it does. The only implementation-defined thing that I mentioned
    in my previous post is the null pointer constant to which the NULL
    macro expands. For example, NULL might expand either to 0 or to
    ((void*)0), both of which are null pointer constants, and both of
    which denote the same run-time pointer value, namely a null pointer.

    Again, a null pointer, at least in the abstract machine, does not
    point to anything. If it pointed to "an implementation-defined
    location", that would mean that each implementation would
    have to document what that location is; there is no such
    requirement. The result of dereferencing a null pointer are not
    implementation-defined; they are undefined.

    On *some* implementations, a null pointer may happen to be the
    address of some memory location, but the standard says nothing
    about what that location might be, or whether it even exists.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    Working, but not speaking, for JetHead Development, Inc.
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
     
    Keith Thompson, May 13, 2013
    #8
    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. Replies:
    10
    Views:
    740
    Chris Torek
    Feb 4, 2005
  2. Bob Nelson

    doubt about doubt

    Bob Nelson, Jul 28, 2006, in forum: C Programming
    Replies:
    11
    Views:
    659
  3. Replies:
    0
    Views:
    592
  4. Peter Otten
    Replies:
    2
    Views:
    139
    Cousin Stanley
    Aug 10, 2013
  5. Terry Reedy
    Replies:
    0
    Views:
    135
    Terry Reedy
    Aug 10, 2013
Loading...

Share This Page