How to get array size from a pointer?

Discussion in 'C Programming' started by ggnguser@gmail.com, Oct 8, 2008.

  1. Guest

    It's part of a test and I'm stumped. There is a function

    void foo(char **x)

    The function signature is given and cannot be changed, so no passing
    of other values. The test case involves defining this variable:

    char *y[] = { /* bunch of stuff */ }

    and calling

    foo(y)

    In the above, "bunch of stuff" is a series of triplets, two strings
    followed by a null string (""). However, the last triplet ends with an
    integer 0. This seems that it's supposed to signify the end of the
    array. However, it appears to me that 0 is the same binary value as
    for the empty string (NUL, \0, whatever). So in effect, one cannot
    test for it as a sentry value because it's actually the same as the
    preceding triplets.

    How then, can the function foo() determine the bounds of the array?
    Knowing the bounds of the particular test case is not sufficient since
    the actual test suite may have arrays of varying size.
    , Oct 8, 2008
    #1
    1. Advertising

  2. Bartc Guest

    <> wrote in message
    news:...
    > It's part of a test and I'm stumped. There is a function
    >
    > void foo(char **x)
    >
    > The function signature is given and cannot be changed, so no passing
    > of other values. The test case involves defining this variable:
    >
    > char *y[] = { /* bunch of stuff */ }
    >
    > and calling
    >
    > foo(y)
    >
    > In the above, "bunch of stuff" is a series of triplets, two strings
    > followed by a null string (""). However, the last triplet ends with an
    > integer 0. This seems that it's supposed to signify the end of the
    > array. However, it appears to me that 0 is the same binary value as
    > for the empty string (NUL, \0, whatever). So in effect, one cannot
    > test for it as a sentry value because it's actually the same as the
    > preceding triplets.


    Any empty string is not necessarily NULL.

    { "ABC","","GHI",0}

    Three non-NULL strings followed by a NULL.

    (vippstar will say NULL is not the same as 0. Whatever; if all you have to
    mark the end is 0, then use it and hope that on your system 0 will never be
    a legal string pointer.)

    --
    bartc
    Bartc, Oct 8, 2008
    #2
    1. Advertising

  3. Guest

    On Oct 8, 4:11 pm, "" <> wrote:
    > It's part of a test and I'm stumped. There is a function
    >
    > void foo(char **x)
    >
    > The function signature is given and cannot be changed, so no passing
    > of other values. The test case involves defining this variable:
    >
    > char *y[] = { /* bunch of stuff */ }
    >
    > and calling
    >
    > foo(y)
    >
    > In the above, "bunch of stuff" is a series of triplets, two strings
    > followed by a null string (""). However, the last triplet ends with an
    > integer 0. This seems that it's supposed to signify the end of the
    > array. However, it appears to me that 0 is the same binary value as
    > for the empty string (NUL, \0, whatever). So in effect, one cannot
    > test for it as a sentry value because it's actually the same as the
    > preceding triplets.


    char *y[] is an array of char * pointers. When a constant integer
    expression with the value 0 appears in integer context, it becomes a
    null pointer constant.
    It's the same if you had written 0 or NULL.

    > How then, can the function foo() determine the bounds of the array?
    > Knowing the bounds of the particular test case is not sufficient since
    > the actual test suite may have arrays of varying size.


    Like strlen(); Strlen iterates until it encounters a byte whose value
    is 0; Your function would iterate until it encounters a pointer whose
    value is NULL.
    , Oct 8, 2008
    #3
  4. Guest

    On Oct 8, 4:22 pm, "Bartc" <> wrote:
    > <> wrote in message
    >
    > news:...
    >
    >
    >
    > > It's part of a test and I'm stumped. There is a function

    >
    > > void foo(char **x)

    >
    > > The function signature is given and cannot be changed, so no passing
    > > of other values. The test case involves defining this variable:

    >
    > > char *y[] = { /* bunch of stuff */ }

    >
    > > and calling

    >
    > > foo(y)

    >
    > > In the above, "bunch of stuff" is a series of triplets, two strings
    > > followed by a null string (""). However, the last triplet ends with an
    > > integer 0. This seems that it's supposed to signify the end of the
    > > array. However, it appears to me that 0 is the same binary value as
    > > for the empty string (NUL, \0, whatever). So in effect, one cannot
    > > test for it as a sentry value because it's actually the same as the
    > > preceding triplets.

    >
    > Any empty string is not necessarily NULL.


    An empty string is _never_ NULL.

    > { "ABC","","GHI",0}
    >
    > Three non-NULL strings followed by a NULL.


    What is a non-NULL string? A string can't be NULL! That doesn't make
    sense.

    > (vippstar will say NULL is not the same as 0. Whatever; if all you have to
    > mark the end is 0, then use it and hope that on your system 0 will never be
    > a legal string pointer.)


    Bollocks. Don't put words in my mouth ever again.
    0 can never be a "legal string pointer".
    NULL is guaranteed to compare unequal to all addresses of objects.
    , Oct 8, 2008
    #4
  5. "" <> writes:

    > It's part of a test and I'm stumped. There is a function
    >
    > void foo(char **x)
    >
    > The function signature is given and cannot be changed, so no passing
    > of other values. The test case involves defining this variable:
    >
    > char *y[] = { /* bunch of stuff */ }
    >
    > and calling
    >
    > foo(y)
    >
    > In the above, "bunch of stuff" is a series of triplets, two strings
    > followed by a null string (""). However, the last triplet ends with an
    > integer 0. This seems that it's supposed to signify the end of the
    > array. However, it appears to me that 0 is the same binary value as
    > for the empty string (NUL, \0, whatever). So in effect, one cannot
    > test for it as a sentry value because it's actually the same as the
    > preceding triplets.


    A little terminology: I'd call it a sentinel and I'd call "" an empty
    string (I see you do to). "Null string" is just too confusing a term
    to use safely.

    Your question: when you write a string literal ("a", "hello", even "")
    as an initialiser for a char * object, the characters in the string
    are put into to an array somewhere (you don't need to care where) and
    a pointer to that array is used as the value of the object. The array
    is null-terminated: a byte with value zero is placed at the end.
    Thus:

    char *empty = "";

    makes empty point to an array somewhere. That array need only contain
    one character: a zero byte (sometimes called a null character).

    C also permits any pointer to be set to a special value to show that
    the pointer does not point to an object. This is a null pointer and
    it quite different to a pointer that points to an array that happens
    to start with a null character. Thus:

    char *nowhere = 0;

    makes nowhere a null pointer. You can also use the macro NULL if you
    have included (one of) the right headers -- stddef.h for example.

    Give a char pointer p, you can tell if it is a null pointer by asking:

    if (p == 0) /* or p == NULL if you prefer */

    In fact, simply writing

    if (!p)

    is enough but to tell if p points to an empty string, you must ask

    if (*p == 0) /* or *p == '\0' if you prefer */

    The same test can also be written p[0] == 0, !p[0] or simply !*p.

    > How then, can the function foo() determine the bounds of the array?
    > Knowing the bounds of the particular test case is not sufficient since
    > the actual test suite may have arrays of varying size.


    In short, it can't, but it can tell the difference between a null
    pointer and a non-null pointer that points at a null character.

    --
    Ben.
    Ben Bacarisse, Oct 8, 2008
    #5
  6. On 8 okt, 15:11, "" <> wrote:
    > It's part of a test and I'm stumped. There is a function
    >
    > void foo(char **x)
    >
    > The function signature is given and cannot be changed, so no passing
    > of other values. The test case involves defining this variable:
    >
    > char *y[] = { /* bunch of stuff */ }
    >
    > and calling
    >
    > foo(y)
    >
    > In the above, "bunch of stuff" is a series of triplets, two strings
    > followed by a null string ("").


    There is no such thing as a null string.
    The string literal "" denotes an empty string, which is a string that
    contains only the terminating '\0' character.

    > However, the last triplet ends with an
    > integer 0. This seems that it's supposed to signify the end of the
    > array. However, it appears to me that 0 is the same binary value as
    > for the empty string (NUL, \0, whatever). So in effect, one cannot
    > test for it as a sentry value because it's actually the same as the
    > preceding triplets.


    First, the binary representation of a null pointer (what you get when
    using 0 in a *pointer* context) is not required to be all-bits-zero
    (although it often is).

    The way you can detect if you are dealing with an empty string or a
    null pointer is like this:
    * Each string, including empty strings, has an address that is
    distinct from NULL.
    * When using strings, you are alweays passing around the addresses of
    the strings.

    >
    > How then, can the function foo() determine the bounds of the array?
    > Knowing the bounds of the particular test case is not sufficient since
    > the actual test suite may have arrays of varying size.


    If you iterate over x, then *x == NULL indicates the end of the array.
    **x == '\0' indicates an empty string (if *x != NULL).

    Bart v Ingen Schenau
    Bart van Ingen Schenau, Oct 8, 2008
    #6
  7. James Kuyper Guest

    Bartc wrote:
    >
    > <> wrote in message
    > news:...
    >> It's part of a test and I'm stumped. There is a function
    >>
    >> void foo(char **x)
    >>
    >> The function signature is given and cannot be changed, so no passing
    >> of other values. The test case involves defining this variable:
    >>
    >> char *y[] = { /* bunch of stuff */ }
    >>
    >> and calling
    >>
    >> foo(y)
    >>
    >> In the above, "bunch of stuff" is a series of triplets, two strings
    >> followed by a null string (""). However, the last triplet ends with an
    >> integer 0. This seems that it's supposed to signify the end of the
    >> array. However, it appears to me that 0 is the same binary value as
    >> for the empty string (NUL, \0, whatever). So in effect, one cannot
    >> test for it as a sentry value because it's actually the same as the
    >> preceding triplets.

    >


    > Any empty string is not necessarily NULL.


    He wrote NUL, not NULL. NUL is the name for an ASCII character which is
    written '\0' in C (when the character set is ASCII).

    Referring to what you said, rather than what he was talking about:

    NULL is necessarily not a an empty string. The only byte in an empty
    string has a null character (NUL on ASCII systems). If NULL expands to
    an expression with arithmetic type, it will certainly compare equal to
    that null character; even if NULL has a pointer type, it will probably
    compare equal to a null character on most systems - (void*)0 is required
    to be a null pointer, but (void*)i is not required to produce the same
    result, even if i==0 (though it usually does).

    However, NULL will never compare equal to an empty string. An empty
    string has a pointer type, and points at the array containing the null
    character which terminates it. In any such comparison, NULL converts to
    a null pointer of the same type, and a null pointer is prohibited from
    comparing equal to any pointer to an actual object.

    > { "ABC","","GHI",0}
    >
    > Three non-NULL strings followed by a NULL.
    >
    > (vippstar will say NULL is not the same as 0. ...


    vippstar is correct. It could be (void*)0, or (8-8) or '\0', among many
    other possibilities. They will all compare equal to 0, however.

    > ... Whatever; if all you have
    > to mark the end is 0, then use it and hope that on your system 0 will
    > never be a legal string pointer.)


    0 is a null pointer constant. When it appears in a pointer context, it
    is treated as a null pointer. A null pointer can never compare equal to
    a pointer to any actual object or pointer. It is legal for a system to
    have a pointer whose bits are all 0 that is not a null pointer. However,
    on such a system, such a pointer can NOT be produced by initializing a
    pointer object with a null pointer constant.
    James Kuyper, Oct 8, 2008
    #7
  8. Bartc Guest

    <> wrote in message
    news:...
    > On Oct 8, 4:22 pm, "Bartc" <> wrote:
    >> <> wrote in message
    >>
    >> news:...
    >>
    >>
    >>
    >> > It's part of a test and I'm stumped. There is a function

    >>
    >> > void foo(char **x)

    >>
    >> > The function signature is given and cannot be changed, so no passing
    >> > of other values. The test case involves defining this variable:

    >>
    >> > char *y[] = { /* bunch of stuff */ }

    >>
    >> > and calling

    >>
    >> > foo(y)

    >>
    >> > In the above, "bunch of stuff" is a series of triplets, two strings
    >> > followed by a null string (""). However, the last triplet ends with an
    >> > integer 0. This seems that it's supposed to signify the end of the
    >> > array. However, it appears to me that 0 is the same binary value as
    >> > for the empty string (NUL, \0, whatever). So in effect, one cannot
    >> > test for it as a sentry value because it's actually the same as the
    >> > preceding triplets.

    >>
    >> Any empty string is not necessarily NULL.

    >
    > An empty string is _never_ NULL.


    I missed where the OP mentioned the null string "", and assumed that NULL
    was also being used to signify an empty string.

    However NULL to represent an empty string can be a useful technique
    (although not recognised by standard functions), hence my comment.

    >
    >> { "ABC","","GHI",0}
    >>
    >> Three non-NULL strings followed by a NULL.

    >
    > What is a non-NULL string? A string can't be NULL! That doesn't make
    > sense.


    Isn't that what I said? A string that is not NULL.

    >> (vippstar will say NULL is not the same as 0. Whatever; if all you have
    >> to
    >> mark the end is 0, then use it and hope that on your system 0 will never
    >> be
    >> a legal string pointer.)

    >
    > B?ll?cks.


    So eloquent.

    --
    Bartc
    Bartc, Oct 8, 2008
    #8
  9. James Kuyper Guest

    Bartc wrote:
    >
    > <> wrote in message
    > news:...
    >> On Oct 8, 4:22 pm, "Bartc" <> wrote:

    ....
    >>> Any empty string is not necessarily NULL.

    >>
    >> An empty string is _never_ NULL.

    >
    > I missed where the OP mentioned the null string "", and assumed that
    > NULL was also being used to signify an empty string.
    >
    > However NULL to represent an empty string can be a useful technique
    > (although not recognised by standard functions), hence my comment.


    No, NULL can be used to represent a missing string. An empty string is a
    string containing one null character; NULL does not qualify.

    >>> { "ABC","","GHI",0}
    >>>
    >>> Three non-NULL strings followed by a NULL.

    >>
    >> What is a non-NULL string? A string can't be NULL! That doesn't make
    >> sense.

    >
    > Isn't that what I said? A string that is not NULL.


    But all strings are not NULL, so that's a pointless phrase. Just say
    "Three strings followed by a null pointer".
    James Kuyper, Oct 8, 2008
    #9
  10. <> wrote:
    > It's part of a test and I'm stumped. There is a function
    >
    > void foo(char **x)
    >
    > The function signature is given and cannot be changed, so no passing
    > of other values. The test case involves defining this variable:
    >
    > char *y[] = { /* bunch of stuff */ }
    >
    > and calling
    >
    > foo(y)
    >
    > In the above, "bunch of stuff" is a series of triplets, two strings
    > followed by a null string (""). However, the last triplet ends with an
    > integer 0. This seems that it's supposed to signify the end of the
    > array. However, it appears to me that 0 is the same binary value as
    > for the empty string (NUL, \0, whatever). So in effect, one cannot
    > test for it as a sentry value because it's actually the same as the
    > preceding triplets.
    >
    > How then, can the function foo() determine the bounds of the array?
    > Knowing the bounds of the particular test case is not sufficient since
    > the actual test suite may have arrays of varying size.


    An empty string ("") is represented as a pointer to a NUL byte (i.e. a byte
    that has the value 0)
    (A string is a pointer to a character array that is terminated by a NUL byte)

    A plain 0 interpreted as a pointer is a null pointer which is different.


    If a particular entry compares equal to NULL then it is a null pointer
    (which in your case would indicate the end of your array 'y' of char
    pointers.) If it does not compare equal to NULL, but points to a byte having
    the value 0, then it is an empty string. (The remaining possibilities are
    that it points to a non-NULL string, or that it is an invalid pointer in
    which case you did something wrong.)





    --
    <Insert your favourite quote here.>
    Erik Trulsson
    Erik Trulsson, Oct 8, 2008
    #10
  11. Guest

    <> wrote:
    >
    > However, it appears to me that 0 is the same binary value as
    > for the empty string (NUL, \0, whatever).


    No. An empty string is like an empty box; a null pointer is no box at
    all.
    --
    Larry Jones

    Rats. I can't tell my gum from my Silly Putty. -- Calvin
    , Oct 8, 2008
    #11
  12. "Bartc" <> writes:
    > <> wrote in message
    > news:...
    >> On Oct 8, 4:22 pm, "Bartc" <> wrote:

    [...]
    >>> Any empty string is not necessarily NULL.

    >>
    >> An empty string is _never_ NULL.

    >
    > I missed where the OP mentioned the null string "", and assumed that
    > NULL was also being used to signify an empty string.
    >
    > However NULL to represent an empty string can be a useful technique
    > (although not recognised by standard functions), hence my comment.

    [...]

    Sure, you can use a null pointer to represent an empty string. You
    can also use the number 42, or the string "this is an empty string",
    to represent an empty string. You can use anything you like to
    represent anything you like, as long as you're consistent about it.

    But a null pointer *is not* an empty string, and it doesn't point to
    an empty string. And, in my opinion, using a null pointer to
    represent an empty string is a bad idea; it's too easy to accidentally
    pass it to a function that doesn't know about your convention, and it
    loses you the ability to distinguish between an empty string and the
    absence of a string.

    Finally, strings are not pointers. A pointer can point to a string; a
    pointer cannot be a string.

    --
    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, Oct 8, 2008
    #12
  13. 0m Guest

    On Oct 9, 12:48 am, Keith Thompson <> wrote:
    >
    > But a null pointer *is not* an empty string, and it doesn't point to
    > an empty string. And, in my opinion, using a null pointer to
    > represent an empty string is a bad idea; it's too easy to accidentally
    > pass it to a function that doesn't know about your convention, and it
    > loses you the ability to distinguish between an empty string and the
    > absence of a string.
    >
    > Finally, strings are not pointers. A pointer can point to a string; a
    > pointer cannot be a string.
    >


    Yes. In my opinion, the null/empty string is this string: ""; the null
    pointer is this value: NULL.
    0m, Oct 8, 2008
    #13
  14. "0m" <> writes:
    > On Oct 9, 12:48 am, Keith Thompson <> wrote:
    >> But a null pointer *is not* an empty string, and it doesn't point to
    >> an empty string. And, in my opinion, using a null pointer to
    >> represent an empty string is a bad idea; it's too easy to accidentally
    >> pass it to a function that doesn't know about your convention, and it
    >> loses you the ability to distinguish between an empty string and the
    >> absence of a string.
    >>
    >> Finally, strings are not pointers. A pointer can point to a string; a
    >> pointer cannot be a string.

    >
    > Yes. In my opinion, the null/empty string is this string: ""; the null
    > pointer is this value: NULL.


    Yes -- but it's not a matter of opinion.

    [news.motzarella.org was having problems, which seem to have been
    cleared up; sorry if this appears twice.]

    --
    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, Oct 8, 2008
    #14
  15. "" <> writes:

    > It's part of a test and I'm stumped. There is a function
    >
    > void foo(char **x)
    >
    > The function signature is given and cannot be changed, so no passing
    > of other values. The test case involves defining this variable:
    >
    > char *y[] = { /* bunch of stuff */ }
    >
    > and calling
    >
    > foo(y)
    >
    > In the above, "bunch of stuff" is a series of triplets, two strings
    > followed by a null string (""). However, the last triplet ends with an
    > integer 0. This seems that it's supposed to signify the end of the
    > array.


    If I understand right, then an appropriate initializer for y would be
    something like

    char *y[] = { "foo", "bar", "", "baz", "qux", "", "xyzzy", "plugh", 0 };

    > However, it appears to me that 0 is the same binary value as
    > for the empty string (NUL, \0, whatever). So in effect, one cannot
    > test for it as a sentry value because it's actually the same as the
    > preceding triplets.


    Well, this may or may not be the case. But it's irrelevant to the
    problem at hand. I think what you may be overlooking is that an empty
    string is not represented by a NULL pointer (which can be got by
    assigning the integer 0 to a pointer), but by a (non-NULL) pointer to
    a null character ('\0'). (Or, if you prefer, an array of chars of
    which the first is '\0'.) So if I write

    char *s = "";

    then the following expressions are all true:

    s != NULL;
    *s == '\0';
    s[0] = '\0';

    Based on this, you could also understand why

    char t[30] = "hello";
    strcat(t, s);

    would leave t unchanged, while strcat(t, NULL) would crash. (If
    you're confused, try writing your own version of strcat and see what
    it would do in each case.)

    In a sense, the point isn't whether the NULL pointer and the null
    character '\0' are represented by the same bits (the C standard makes
    no guarantee one way or the other). The issue is whether you're
    looking at the pointer itself or the thing it points to.

    This is complicated somewhat by the fact that some people write their
    code in such a way that passing NULL where a string is expected has
    the same effect as passing an empty string. But this is something
    that they have to do explicitly. (You could modify your version of
    strcat to do this if you want.) In the situation at hand, this is
    exactly the opposite of what you want; the distinction between the two
    is the information you need.

    > How then, can the function foo() determine the bounds of the array?
    > Knowing the bounds of the particular test case is not sufficient since
    > the actual test suite may have arrays of varying size.


    Hopefully this discussion is enough of a hint. If not, post again.

    By the way, if by "test" you mean this is part of an exam for a
    course, don't forget to properly credit this post as a source of
    information.
    Nate Eldredge, Oct 8, 2008
    #15
  16. Bartc Guest

    "Keith Thompson" <> wrote in message
    news:...
    > "Bartc" <> writes:
    >> <> wrote in message
    >> news:...
    >>> On Oct 8, 4:22 pm, "Bartc" <> wrote:

    > [...]
    >>>> Any empty string is not necessarily NULL.
    >>>
    >>> An empty string is _never_ NULL.

    >>
    >> I missed where the OP mentioned the null string "", and assumed that
    >> NULL was also being used to signify an empty string.
    >>
    >> However NULL to represent an empty string can be a useful technique
    >> (although not recognised by standard functions), hence my comment.

    > [...]
    >
    > Sure, you can use a null pointer to represent an empty string. You
    > can also use the number 42, or the string "this is an empty string",
    > to represent an empty string. You can use anything you like to
    > represent anything you like, as long as you're consistent about it.


    I quite like this other quote in this thread:

    <> wrote in message
    news:...
    > <> wrote:
    > No. An empty string is like an empty box; a null pointer is no box at
    > all.


    If you go to your drawer to get some socks, the absence of a drawer will
    tell you you have no socks, just as well as an empty drawer. And you don't
    have to open the drawer to find out.

    >
    > But a null pointer *is not* an empty string, and it doesn't point to
    > an empty string. And, in my opinion, using a null pointer to
    > represent an empty string is a bad idea; it's too easy to accidentally
    > pass it to a function that doesn't know about your convention, and it
    > loses you the ability to distinguish between an empty string and the
    > absence of a string.


    Well I used null pointers for empty strings before, outside of C. In C, that
    would be problematic because standard functions tend to crash when you pass
    null pointers. But I do still sometimes use null pointers this way, it just
    needs some care.

    --
    Bartc
    Bartc, Oct 8, 2008
    #16
  17. CBFalconer Guest

    "" wrote:
    >
    > It's part of a test and I'm stumped. There is a function
    >
    > void foo(char **x)
    >
    > The function signature is given and cannot be changed, so no passing
    > of other values. The test case involves defining this variable:
    >
    > char *y[] = { /* bunch of stuff */ }
    >
    > and calling
    >
    > foo(y)
    >
    > In the above, "bunch of stuff" is a series of triplets, two strings
    > followed by a null string (""). However, the last triplet ends with an
    > integer 0. This seems that it's supposed to signify the end of the
    > array. However, it appears to me that 0 is the same binary value as
    > for the empty string (NUL, \0, whatever). So in effect, one cannot
    > test for it as a sentry value because it's actually the same as the
    > preceding triplets.


    Maybe "bunch of stuff" is that, but y is not. y is an array of
    pointers to char, and those pointers also point to char arrays that
    are not writeable. The arrays are strings, with a '\0' terminal
    char. The last string is an empty string, and is used to mark the
    end of the array.

    Now consider what foo is. It appears, from your definition, to be
    a function that returns void (i.e. nothing). It also requires a
    parameter, x, which is a pointer to a char pointer.

    Combining those things, the call to foo(y) cannot possibly do
    anything.

    --
    [mail]: Chuck F (cbfalconer at maineline dot net)
    [page]: <http://cbfalconer.home.att.net>
    Try the download section.
    CBFalconer, Oct 9, 2008
    #17
  18. On 9 Oct, 01:27, CBFalconer <> wrote:
    > "" wrote:
    >
    > > It's part of a test and I'm stumped. There is a function

    >
    > > void foo(char **x)

    >
    > > The function signature is given and cannot be changed, so no passing
    > > of other values. The test case involves defining this variable:

    >
    > > char *y[] = { /* bunch of stuff */ }

    >
    > > and calling

    >
    > > foo(y)

    >
    > > In the above, "bunch of stuff" is a series of triplets, two strings
    > > followed by a null string (""). However, the last triplet ends with an
    > > integer 0. This seems that it's supposed to signify the end of the
    > > array. However, it appears to me that 0 is the same binary value as
    > > for the empty string (NUL, \0, whatever). So in effect, one cannot
    > > test for it as a sentry value because it's actually the same as the
    > > preceding triplets.

    >
    > Maybe "bunch of stuff" is that, but y is not.  y is an array of
    > pointers to char, and those pointers also point to char arrays that
    > are not writeable.  The arrays are strings, with a '\0' terminal
    > char.  The last string is an empty string, and is used to mark the
    > end of the array.
    >
    > Now consider what foo is.  It appears, from your definition, to be
    > a function that returns void (i.e. nothing).  It also requires a
    > parameter, x, which is a pointer to a char pointer.
    >
    > Combining those things, the call to foo(y) cannot possibly do
    > anything.
    >
    > --
    >  [mail]: Chuck F (cbfalconer at maineline dot net)
    >  [page]: <http://cbfalconer.home.att.net>
    >             Try the download section.- Hide quoted text -
    >
    > - Show quoted text -


    On 9 Oct, 01:27, CBFalconer <> wrote:

    <snip>

    > Now consider what foo is. It appears, from your definition, to be
    > a function that returns void (i.e. nothing). It also requires a
    > parameter, x, which is a pointer to a char pointer.
    >
    > Combining those things, the call to foo(y) cannot possibly do
    > anything.


    i/o?

    --
    Nick Keighley
    Nick Keighley, Oct 9, 2008
    #18
  19. CBFalconer <> writes:

    > "" wrote:
    >>
    >> It's part of a test and I'm stumped. There is a function
    >>
    >> void foo(char **x)
    >>
    >> The function signature is given and cannot be changed, so no passing
    >> of other values. The test case involves defining this variable:
    >>
    >> char *y[] = { /* bunch of stuff */ }
    >>
    >> and calling
    >>
    >> foo(y)
    >>
    >> In the above, "bunch of stuff" is a series of triplets, two strings
    >> followed by a null string (""). However, the last triplet ends with an
    >> integer 0. This seems that it's supposed to signify the end of the
    >> array. However, it appears to me that 0 is the same binary value as
    >> for the empty string (NUL, \0, whatever). So in effect, one cannot
    >> test for it as a sentry value because it's actually the same as the
    >> preceding triplets.

    >
    > Maybe "bunch of stuff" is that, but y is not. y is an array of
    > pointers to char, and those pointers also point to char arrays that
    > are not writeable. The arrays are strings, with a '\0' terminal
    > char. The last string is an empty string, and is used to mark the
    > end of the array.
    >
    > Now consider what foo is. It appears, from your definition, to be
    > a function that returns void (i.e. nothing). It also requires a
    > parameter, x, which is a pointer to a char pointer.
    >
    > Combining those things, the call to foo(y) cannot possibly do
    > anything.


    Um? Here are some possible definitions for foo that do things.

    void foo(char **x) { x[3] = "Hi mom!"; }
    void foo(char **x) { while (*x) puts(*x++); }
    void foo(char **x) { errno = EDOOFUS; }
    void foo(char **x) { longjmp(somewhere); }
    void foo(char **x) { abort(); }
    Nate Eldredge, Oct 9, 2008
    #19
  20. Richard Bos Guest

    "Bartc" <> wrote:

    > "Keith Thompson" <> wrote in message
    > > "Bartc" <> writes:
    > >> However NULL to represent an empty string can be a useful technique
    > >> (although not recognised by standard functions), hence my comment.

    > >
    > > Sure, you can use a null pointer to represent an empty string. You
    > > can also use the number 42, or the string "this is an empty string",
    > > to represent an empty string. You can use anything you like to
    > > represent anything you like, as long as you're consistent about it.

    >
    > I quite like this other quote in this thread:
    >
    > <> wrote in message
    > > No. An empty string is like an empty box; a null pointer is no box at
    > > all.

    >
    > If you go to your drawer to get some socks, the absence of a drawer will
    > tell you you have no socks, just as well as an empty drawer. And you don't
    > have to open the drawer to find out.


    I take it, then, that you've never worked with databases much. I assure
    you, there is a world of difference between "We have no record of this
    person" and "We have a record of this person, and his phone number field
    is blank".
    Basically, it's like asking how many legs a fish has, and how many legs
    a null string has. In the first case, the answer is "none"; in the
    second case, it's "What have you been smoking?".

    > > But a null pointer *is not* an empty string, and it doesn't point to
    > > an empty string. And, in my opinion, using a null pointer to
    > > represent an empty string is a bad idea; it's too easy to accidentally
    > > pass it to a function that doesn't know about your convention, and it
    > > loses you the ability to distinguish between an empty string and the
    > > absence of a string.

    >
    > Well I used null pointers for empty strings before, outside of C. In C, that
    > would be problematic because standard functions tend to crash when you pass
    > null pointers. But I do still sometimes use null pointers this way, it just
    > needs some care.


    No, it needs a situation where there is no difference between "doesn't
    exist" and "is blank". Those situations are rarer than most people, even
    most programmers with no database experience, believe.

    Richard
    Richard Bos, Oct 9, 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. sangeetha

    Array of pointer Vs Pointer to Array

    sangeetha, Oct 8, 2004, in forum: C Programming
    Replies:
    9
    Views:
    338
    Tim Rentsch
    Oct 9, 2004
  2. terry

    Get array size by a pointer dynamically

    terry, Nov 14, 2004, in forum: C Programming
    Replies:
    4
    Views:
    391
    Lawrence Kirby
    Nov 15, 2004
  3. erfan

    Array of pointer and pointer of array

    erfan, Jan 28, 2008, in forum: C Programming
    Replies:
    6
    Views:
    663
    Martin Ambuhl
    Jan 28, 2008
  4. RSL
    Replies:
    14
    Views:
    3,217
  5. , India

    pointer to an array vs pointer to pointer

    , India, Sep 20, 2011, in forum: C Programming
    Replies:
    5
    Views:
    439
    James Kuyper
    Sep 23, 2011
Loading...

Share This Page