Lowest addressed character in array

Discussion in 'C Programming' started by arnuld, Dec 14, 2010.

  1. arnuld

    arnuld Guest

    > On Sun, 12 Dec 2010 12:01:21 -0800, Keith Thompson wrote:

    > They *require* that the argument (for example, the argument to strlen())
    > is a pointer to a string.
    >
    > The idea that a null pointer is not a pointer to a string is implicit in
    > the Standard's definition of the phrase "pointer to a string" (C99
    > 7.1.1p1).


    Just checked it out and its says:

    "A pointer to a string is a pointer to its initial (lowest addressed)
    character."


    Here is what I get:

    #include <stdio.h>

    int main(void)
    {
    const char* arrc = "clc";
    const char* p = arrc;

    for(; *p; ++p)
    {
    printf("p: %p\n", (void*)p);
    }

    return 0;
    }
    ================ OUTPUT ========================
    [arnuld@dune programs]$ gcc -ansi -pedantic -Wall -Wextra test.c
    [arnuld@dune programs]$ ./a.out
    p: 0x80484b0
    p: 0x80484b1
    p: 0x80484b2
    [arnuld@dune programs]$


    of course, lowest adressed character is first one, element on index
    zero). I remember one of my colleagues telling me that array elements
    need not be in ascending order of addresses, they can be in descending
    order of addresses e.g. in my example, it could print 4b2, 4b1, 4b0.
    There is not guarantee that elements are always laid down in ascending
    order in RAM (memory). From what you say I think he was wrong (if I get
    correctly what Standard say). Any enlightenment here ?



    >
    > There's no need for strlen() to make that distinction itself. It's
    > entirely the responsibility of the caller, just as it's the caller's
    > responsibility not to call strlen() with a pointer that's just been
    > free()'d.
    >
    > A pointer value may be valid or invalid depending on the context in
    > which it's used. A null pointer value is perfectly valid on the RHS of
    > an assignment, but not as the operand of a unary "*". A pointer to a
    > struct object that's been converted to void* is valid as an argument to
    > memset(), but not as an argument to strlen().
    >
    > I suppose that having string functions treat null pointers as if they
    > were pointers to empty strings would be more convenient in some cases
    > (though it could impose extra overhead where the caller has taken care
    > to pass a non-null pointer), but in my opinion it makes for a more
    > consistent mental model.
    >
    > If you had a function that took an int* argument, would you want it to
    > treat a null pointer as if it pointed to an int with the value 0?
    >
    > Admittedly, the difference there is that you can pass int arguments
    > directly, so there's no need to use a pointer if you just want the
    > value. If C were able to treat strings as first-class objects (as some
    > languages do), we probably wouldn't be having this debate.






    --
    www.lispmachine.wordpress.com



    --
    www.lispmachine.wordpress.com
     
    arnuld, Dec 14, 2010
    #1
    1. Advertising

  2. arnuld <> writes:
    >> On Sun, 12 Dec 2010 12:01:21 -0800, Keith Thompson wrote:

    >
    >> They *require* that the argument (for example, the argument to strlen())
    >> is a pointer to a string.
    >>
    >> The idea that a null pointer is not a pointer to a string is implicit in
    >> the Standard's definition of the phrase "pointer to a string" (C99
    >> 7.1.1p1).

    >
    > Just checked it out and its says:
    >
    > "A pointer to a string is a pointer to its initial (lowest addressed)
    > character."

    [...]
    > #include <stdio.h>
    >
    > int main(void)
    > {
    > const char* arrc = "clc";
    > const char* p = arrc;
    >
    > for(; *p; ++p)
    > {
    > printf("p: %p\n", (void*)p);
    > }
    >
    > return 0;
    > }
    > ================ OUTPUT ========================
    > [arnuld@dune programs]$ gcc -ansi -pedantic -Wall -Wextra test.c
    > [arnuld@dune programs]$ ./a.out
    > p: 0x80484b0
    > p: 0x80484b1
    > p: 0x80484b2
    > [arnuld@dune programs]$
    >
    >
    > of course, lowest adressed character is first one, element on index
    > zero). I remember one of my colleagues telling me that array elements
    > need not be in ascending order of addresses, they can be in descending
    > order of addresses e.g. in my example, it could print 4b2, 4b1, 4b0.
    > There is not guarantee that elements are always laid down in ascending
    > order in RAM (memory). From what you say I think he was wrong (if I get
    > correctly what Standard say). Any enlightenment here ?

    [...]

    Addresses of successive element of an array are always guaranteed
    to be in increasing order, but "increasing" is defined in terms of
    pointer operations: &p[1] > &p[0], &p[2] > &p[1].

    The hexadecimal values you're seeing are a printable *representation*
    of the addresses; they're not the addresses themselves. Remember,
    addresses (pointer values) are not integers -- though they can
    be converted to integers (the result of such a conversion should
    normally be consistent with the addressing structure of the machine),
    and are very often implemented as bit patterns that behave like
    integers.

    There is no guarantee that the output of your program will even look
    like a sequence of integers; it could legally be:

    p: red
    p: green
    p: Wednesday

    (though that's almost fantastically unlikely).

    Strictly speaking, your colleage is right; practically speaking, he's wrong.

    --
    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, Dec 14, 2010
    #2
    1. Advertising

  3. arnuld

    Seebs Guest

    On 2010-12-14, arnuld <> wrote:
    > of course, lowest adressed character is first one, element on index
    > zero). I remember one of my colleagues telling me that array elements
    > need not be in ascending order of addresses, they can be in descending
    > order of addresses e.g. in my example, it could print 4b2, 4b1, 4b0.


    Uh, no.

    > There is not guarantee that elements are always laid down in ascending
    > order in RAM (memory). From what you say I think he was wrong (if I get
    > correctly what Standard say). Any enlightenment here ?


    Why do you listen to these people?

    -s
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    I am not speaking for my employer, although they do rent some of my opinions.
     
    Seebs, Dec 14, 2010
    #3
  4. arnuld

    Nick Guest

    Seebs <> writes:

    > On 2010-12-14, arnuld <> wrote:
    >> of course, lowest adressed character is first one, element on index
    >> zero). I remember one of my colleagues telling me that array elements
    >> need not be in ascending order of addresses, they can be in descending
    >> order of addresses e.g. in my example, it could print 4b2, 4b1, 4b0.

    >
    > Uh, no.


    In "angels on the head of a pin mode", as there is nothing other than an
    implementation defined way to convert a pointer to an integer:
    a) it could /print/ 4b2, 4b1, 4b0 even if they were ascending up the
    memory (I'm pretty sure of this one) - ie, %p could just subtract the
    actual pointer address from all-1s.
    b) (I'm slightly less sure). If all pointers were to the top ends of
    blocks of memory, and +/- worked the wrong way round for pointers,
    you'd never know.
    --
    Online waterways route planner | http://canalplan.eu
    Plan trips, see photos, check facilities | http://canalplan.org.uk
     
    Nick, Dec 15, 2010
    #4
  5. Nick <> writes:
    > Seebs <> writes:
    >> On 2010-12-14, arnuld <> wrote:
    >>> of course, lowest adressed character is first one, element on index
    >>> zero). I remember one of my colleagues telling me that array elements
    >>> need not be in ascending order of addresses, they can be in descending
    >>> order of addresses e.g. in my example, it could print 4b2, 4b1, 4b0.

    >>
    >> Uh, no.

    >
    > In "angels on the head of a pin mode", as there is nothing other than an
    > implementation defined way to convert a pointer to an integer:
    > a) it could /print/ 4b2, 4b1, 4b0 even if they were ascending up the
    > memory (I'm pretty sure of this one) - ie, %p could just subtract the
    > actual pointer address from all-1s.


    Agreed -- except that %p converts a pointer to a string, not
    (necessarily) to an integer.

    > b) (I'm slightly less sure). If all pointers were to the top ends of
    > blocks of memory, and +/- worked the wrong way round for pointers,
    > you'd never know.


    I think pointers would have to keep track of the size of the blocks
    they're pointing to. For example, given char arr[100], &arr, in
    your model, points to the end of the 100-byte block, but &arr[0]
    still has to point to the 0th byte of the block.

    --
    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, Dec 15, 2010
    #5
  6. On Dec 15, 12:51 pm, Keith Thompson <> wrote:
    > Nick <> writes:
    > > Seebs <> writes:
    > >> On 2010-12-14, arnuld <> wrote:
    > >>> of course, lowest adressed character is first one, element on index
    > >>> zero). I remember one of my colleagues telling me that array elements
    > >>> need not be in ascending order of addresses, they can be in descending
    > >>> order of addresses e.g. in my example, it could print 4b2, 4b1, 4b0.

    >
    > >> Uh, no.

    >
    > > In "angels on the head of a pin mode", as there is nothing other than an
    > > implementation defined way to convert a pointer to an integer:
    > > a) it could /print/ 4b2, 4b1, 4b0 even if they were ascending up the
    > > memory (I'm pretty sure of this one) - ie, %p could just subtract the
    > > actual pointer address from all-1s.

    >
    > Agreed -- except that %p converts a pointer to a string, not
    > (necessarily) to an integer.
    >
    > > b) (I'm slightly less sure).  If all pointers were to the top ends of
    > > blocks of memory, and +/- worked the wrong way round for pointers,
    > > you'd never know.

    >
    > I think pointers would have to keep track of the size of the blocks
    > they're pointing to.  For example, given char arr[100], &arr, in
    > your model, points to the end of the 100-byte block, but &arr[0]
    > still has to point to the 0th byte of the block.


    I know of one implementation that ran character arrays from highest
    memory down and binary arrays from lowest memory up on little endian
    processors in order that processors of opposite byte sex could share
    binary structures with each other.
     
    Michael Angelo Ravera, Dec 15, 2010
    #6
  7. Michael Angelo Ravera <> writes:
    > On Dec 15, 12:51 pm, Keith Thompson <> wrote:
    >> Nick <> writes:

    [..]
    >> > b) (I'm slightly less sure).  If all pointers were to the top ends of
    >> > blocks of memory, and +/- worked the wrong way round for pointers,
    >> > you'd never know.

    >>
    >> I think pointers would have to keep track of the size of the blocks
    >> they're pointing to.  For example, given char arr[100], &arr, in
    >> your model, points to the end of the 100-byte block, but &arr[0]
    >> still has to point to the 0th byte of the block.

    >
    > I know of one implementation that ran character arrays from highest
    > memory down and binary arrays from lowest memory up on little endian
    > processors in order that processors of opposite byte sex could share
    > binary structures with each other.


    One implementation of what? If you're referring to a C implementation,
    what do you mean by "binary arrays"?

    --
    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, Dec 16, 2010
    #7
  8. On Dec 15, 4:03 pm, Keith Thompson <> wrote:
    > Michael Angelo Ravera <> writes:
    >
    >
    >
    >
    >
    > > On Dec 15, 12:51 pm, Keith Thompson <> wrote:
    > >> Nick <> writes:

    > [..]
    > >> > b) (I'm slightly less sure).  If all pointers were to the top ends of
    > >> > blocks of memory, and +/- worked the wrong way round for pointers,
    > >> > you'd never know.

    >
    > >> I think pointers would have to keep track of the size of the blocks
    > >> they're pointing to.  For example, given char arr[100], &arr, in
    > >> your model, points to the end of the 100-byte block, but &arr[0]
    > >> still has to point to the 0th byte of the block.

    >
    > > I know of one implementation that ran character arrays from highest
    > > memory down and binary arrays from lowest memory up on little endian
    > > processors in order that processors of opposite byte sex could share
    > > binary structures with each other.

    >
    > One implementation of what?  If you're referring to a C implementation,
    > what do you mean by "binary arrays"?
    >


    Mistyped "binary number", that is to say, integers. It was a whole OS
    that was heavily into Bilaterally Defined Binary Data ("BDBD").
     
    Michael Angelo Ravera, Dec 16, 2010
    #8
  9. Michael Angelo Ravera <> writes:
    > On Dec 15, 4:03 pm, Keith Thompson <> wrote:
    >> Michael Angelo Ravera <> writes:
    >> > On Dec 15, 12:51 pm, Keith Thompson <> wrote:
    >> >> Nick <> writes:

    >> [..]
    >> >> > b) (I'm slightly less sure).  If all pointers were to the top ends of
    >> >> > blocks of memory, and +/- worked the wrong way round for pointers,
    >> >> > you'd never know.

    >>
    >> >> I think pointers would have to keep track of the size of the blocks
    >> >> they're pointing to.  For example, given char arr[100], &arr, in
    >> >> your model, points to the end of the 100-byte block, but &arr[0]
    >> >> still has to point to the 0th byte of the block.

    >>
    >> > I know of one implementation that ran character arrays from highest
    >> > memory down and binary arrays from lowest memory up on little endian
    >> > processors in order that processors of opposite byte sex could share
    >> > binary structures with each other.

    >>
    >> One implementation of what?  If you're referring to a C implementation,
    >> what do you mean by "binary arrays"?

    >
    > Mistyped "binary number", that is to say, integers. It was a whole OS
    > that was heavily into Bilaterally Defined Binary Data ("BDBD").


    My real question is whether it did this for C. Having arrays of char
    and arrays of int, for example, run in opposite directions would
    have some interesting implications for how C pointer arithmetic
    would have to be implemented. For languages that don't tie array
    indexing and pointer arithmetic the way C does, it wouldn't be as
    much of an issue.

    --
    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, Dec 16, 2010
    #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. lime
    Replies:
    14
    Views:
    660
    Stephen Poley
    Nov 17, 2004
  2. William L. Bahn

    Where is error checking on fgets() addressed in FAQ?

    William L. Bahn, May 2, 2004, in forum: C Programming
    Replies:
    7
    Views:
    465
    Dave Thompson
    May 12, 2004
  3. Julia
    Replies:
    79
    Views:
    2,513
    James Dow Allen
    Feb 9, 2007
  4. pereges
    Replies:
    79
    Views:
    1,572
    Keith Thompson
    Jun 19, 2008
  5. Michael Schumacher

    Write-protecting objects addressed via indirect pointers

    Michael Schumacher, Oct 20, 2009, in forum: C Programming
    Replies:
    13
    Views:
    575
    Flash Gordon
    Oct 20, 2009
Loading...

Share This Page