Re: Ike Naar

Discussion in 'C Programming' started by Keith Thompson, Feb 8, 2009.

  1. "Malcolm McLean" <> writes:
    [...]
    > Surely there is some rule that NULL can be used as the null pointer
    > constnant, in all contexts?


    NULL is (or, rather, expands to) a null pointer constant in all
    contexts. But a null pointer constant doesn't necessarily result in a
    null pointer value in all contexts.

    For example:
    printf("%p\n", 0);
    0 is a null pointer constant, but since it corresponds to the ",..."
    in the declaration of printf, the compiler doesn't convert it from int
    to any pointer type, and the call passes a value of type int. It
    could be passed as the wrong value, the wrong size, or even in the
    wrong location. If NULL is defined as 0, which is both legal and
    common, then the above is equivalent to:
    printf("%p\n", NULL);
    To be safe, you need a cast:
    printf("%p\n", (void*)NULL);

    --
    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, Feb 8, 2009
    #1
    1. Advertising

  2. Keith Thompson

    Flash Gordon Guest

    Malcolm McLean wrote:
    > "Keith Thompson" <> wrote in message news:
    >> "Malcolm McLean" <> writes:
    >> [...]
    >>> Surely there is some rule that NULL can be used as the null pointer
    >>> constnant, in all contexts?

    >>
    >> NULL is (or, rather, expands to) a null pointer constant in all
    >> contexts. But a null pointer constant doesn't necessarily result in a
    >> null pointer value in all contexts.
    >>
    >> For example:
    >> printf("%p\n", 0);
    >> 0 is a null pointer constant, but since it corresponds to the ",..."
    >> in the declaration of printf, the compiler doesn't convert it from int
    >> to any pointer type, and the call passes a value of type int. It
    >> could be passed as the wrong value, the wrong size, or even in the
    >> wrong location. If NULL is defined as 0, which is both legal and
    >> common, then the above is equivalent to:
    >> printf("%p\n", NULL);
    >> To be safe, you need a cast:
    >> printf("%p\n", (void*)NULL);
    >>

    > That's another good argument for the campaign for 64 bit ints.


    No it isn't. It is a good argument in favour of doing some of the
    compile-time checks that gcc (and probably other compiles) does. It is
    also a good argument for changing the C standard to require than NULL be
    defined as ((void*)0) which is something that all implementations could
    easily be changed to do.

    > (I suppose it would still break if the null pointer wasn't all bits zero).


    Or if the first few pointers are passed in address registers (passing
    parameters in registers does happen even with varidac functions).
     
    Flash Gordon, Feb 8, 2009
    #2
    1. Advertising

  3. Flash Gordon <> writes:
    > Malcolm McLean wrote:
    >> "Keith Thompson" <> wrote in message news:
    >>> "Malcolm McLean" <> writes:
    >>> [...]
    >>>> Surely there is some rule that NULL can be used as the null pointer
    >>>> constnant, in all contexts?
    >>>
    >>> NULL is (or, rather, expands to) a null pointer constant in all
    >>> contexts. But a null pointer constant doesn't necessarily result in a
    >>> null pointer value in all contexts.
    >>>
    >>> For example:
    >>> printf("%p\n", 0);
    >>> 0 is a null pointer constant, but since it corresponds to the ",..."
    >>> in the declaration of printf, the compiler doesn't convert it from int
    >>> to any pointer type, and the call passes a value of type int. It
    >>> could be passed as the wrong value, the wrong size, or even in the
    >>> wrong location. If NULL is defined as 0, which is both legal and
    >>> common, then the above is equivalent to:
    >>> printf("%p\n", NULL);
    >>> To be safe, you need a cast:
    >>> printf("%p\n", (void*)NULL);
    >>>

    >> That's another good argument for the campaign for 64 bit ints.

    >
    > No it isn't. It is a good argument in favour of doing some of the
    > compile-time checks that gcc (and probably other compiles) does. It is
    > also a good argument for changing the C standard to require than NULL
    > be defined as ((void*)0) which is something that all implementations
    > could easily be changed to do.


    That would help for void* pointers, but not for other pointer types.
    I don't think it would matter for anything in the standard library
    (assuming char* and void* are interchangeable as arguments), but
    consider a variadic function that expects an argument of type int*.
    Passing NULL would still pass a null pointer of type void*, which
    could be incompatible.

    [...]

    --
    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, Feb 8, 2009
    #3
  4. Keith Thompson

    Flash Gordon Guest

    Keith Thompson wrote:
    > Flash Gordon <> writes:
    >> Malcolm McLean wrote:
    >>> "Keith Thompson" <> wrote in message news:
    >>>> "Malcolm McLean" <> writes:
    >>>> [...]
    >>>>> Surely there is some rule that NULL can be used as the null pointer
    >>>>> constnant, in all contexts?
    >>>> NULL is (or, rather, expands to) a null pointer constant in all
    >>>> contexts. But a null pointer constant doesn't necessarily result in a
    >>>> null pointer value in all contexts.
    >>>>
    >>>> For example:
    >>>> printf("%p\n", 0);
    >>>> 0 is a null pointer constant, but since it corresponds to the ",..."
    >>>> in the declaration of printf, the compiler doesn't convert it from int
    >>>> to any pointer type, and the call passes a value of type int. It
    >>>> could be passed as the wrong value, the wrong size, or even in the
    >>>> wrong location. If NULL is defined as 0, which is both legal and
    >>>> common, then the above is equivalent to:
    >>>> printf("%p\n", NULL);
    >>>> To be safe, you need a cast:
    >>>> printf("%p\n", (void*)NULL);
    >>>>
    >>> That's another good argument for the campaign for 64 bit ints.

    >> No it isn't. It is a good argument in favour of doing some of the
    >> compile-time checks that gcc (and probably other compiles) does. It is
    >> also a good argument for changing the C standard to require than NULL
    >> be defined as ((void*)0) which is something that all implementations
    >> could easily be changed to do.

    >
    > That would help for void* pointers, but not for other pointer types.
    > I don't think it would matter for anything in the standard library
    > (assuming char* and void* are interchangeable as arguments), but
    > consider a variadic function that expects an argument of type int*.
    > Passing NULL would still pass a null pointer of type void*, which
    > could be incompatible.


    I know it would not help where other pointer types are expected
    (technically, although in practice it would for many implementations),
    and is possibly dodgy where a char* is expected. However it would be
    correct where a void* is expected and, more importantly (in my opinion),
    it would guarantee a diagnostic if used where an integer is required.
    --
    Flash Gordon
     
    Flash Gordon, Feb 9, 2009
    #4
  5. Keith Thompson

    Richard Bos Guest

    Golden California Girls <> wrote:

    > Malcolm McLean wrote:
    > > "Keith Thompson" <> wrote in message news:


    > >> To be safe, you need a cast:
    > >> printf("%p\n", (void*)NULL);
    > >>

    > > That's another good argument for the campaign for 64 bit ints.

    >
    > Where C&V is it required that pointers be so small as be fit in 64 bits?


    Oh, it's worse than that. It's not even required that pointers be the
    same size as ints - or that pointers are the same size as other
    pointers.

    Richard
     
    Richard Bos, Feb 20, 2009
    #5
  6. Keith Thompson

    Richard Bos Guest

    "Malcolm McLean" <> wrote:

    > "Richard Bos" <> wrote in message news:
    > > Golden California Girls <> wrote:
    > >
    > >> Malcolm McLean wrote:
    > >> > "Keith Thompson" <> wrote in message news:

    > >
    > >> >> To be safe, you need a cast:
    > >> >> printf("%p\n", (void*)NULL);
    > >> >>
    > >> > That's another good argument for the campaign for 64 bit ints.
    > >>
    > >> Where C&V is it required that pointers be so small as be fit in 64 bits?

    > >
    > > Oh, it's worse than that. It's not even required that pointers be the
    > > same size as ints - or that pointers are the same size as other
    > > pointers.
    > >

    > There aren't enough 32 bit integers to go round, even if we ration them
    > strictly to one each. However the problem disappears with 64 bit ints.


    Large integers are nice, but they have nothing to do with pointers.

    > The campaign for 64 bit ints is the campaign for int to be the natural
    > integer size on a machine with a 64 bit address space.


    That's pretty (though in some circumstances dumb), but all the evidence
    I've seen here is that this may be its stated goal, but the one thing it
    really campaigns for is for all pointers to be the same as all integers.
    Which is truly astoundingly dumb.

    > There is a case for fat pointers, but that's a different argument. It isn't
    > clear to me that we don't need some tweaks to the standard in order to make
    > fat pointers generally useful.


    Then you should read the Standard with a more open mind. There is _no_
    problem with fat pointers in C, and there can be very good applications
    of them, on systems where they make sense.

    Richard
     
    Richard Bos, Feb 23, 2009
    #6
    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:
    1
    Views:
    255
    Mark -Mortakai- Moran
    Sep 11, 2008
  2. Antoninus Twink

    Re: Ike Naar

    Antoninus Twink, Feb 8, 2009, in forum: C Programming
    Replies:
    1
    Views:
    314
    Ben Bacarisse
    Feb 8, 2009
  3. Stephen Sprunk

    Re: Ike Naar

    Stephen Sprunk, Feb 8, 2009, in forum: C Programming
    Replies:
    31
    Views:
    900
    Keith Thompson
    Feb 15, 2009
  4. Replies:
    1
    Views:
    113
    Mark -Mortakai- Moran
    Sep 11, 2008
Loading...

Share This Page