Are they equivalent ?

Discussion in 'C Programming' started by grid, Dec 13, 2005.

  1. grid

    grid Guest

    Hi,
    I have a certain situation where a particular piece of code works on a
    particular compiler but fails on another proprietary compiler.It seems
    to have been fixed but I just want to confirm if both statements are
    similar :

    *((char **)v)++ == *((char **)v++)

    Where v is a pointer to an array of characters,defined as
    char *v[];

    I am passing "v" to a function expecting a char * .

    Apologize for not being able to provide a minimum compilable program.

    Tx
    ~
     
    grid, Dec 13, 2005
    #1
    1. Advertising

  2. grid wrote:
    >
    > Hi,
    > I have a certain situation where a particular piece of code works on a
    > particular compiler but fails on another proprietary compiler.It seems
    > to have been fixed but I just want to confirm if both statements are
    > similar :
    >
    > *((char **)v)++ == *((char **)v++)

    [...]

    No, they are not similar.

    *((char **)v)++

    Dereferences v and post-increments what it points to.

    *((char **)v++)

    Post-increments v itself, and then dereferences it.

    --
    +-------------------------+--------------------+-----------------------------+
    | Kenneth J. Brody | www.hvcomputer.com | |
    | kenbrody/at\spamcop.net | www.fptech.com | #include <std_disclaimer.h> |
    +-------------------------+--------------------+-----------------------------+
    Don't e-mail me at: <mailto:>
     
    Kenneth Brody, Dec 13, 2005
    #2
    1. Advertising

  3. grid

    Eric Sosman Guest

    Kenneth Brody wrote On 12/13/05 10:46,:
    > grid wrote:
    >
    >>Hi,
    >> I have a certain situation where a particular piece of code works on a
    >>particular compiler but fails on another proprietary compiler.It seems
    >>to have been fixed but I just want to confirm if both statements are
    >>similar :
    >>
    >>*((char **)v)++ == *((char **)v++)

    >
    > [...]
    >
    > No, they are not similar.


    Right so far.

    > *((char **)v)++
    >
    > Dereferences v and post-increments what it points to.


    No; this one's a constraint violation. Syntactically,
    it asks for the value of `v' to be converted to type `char**',
    then for that value to be post-incremented, meanwhile
    dereferencing the non-incremented value. The constraint
    violation is the attempt to post-increment the expression
    `((char**)v)', which is not an lvalue.

    > *((char **)v++)
    >
    > Post-increments v itself, and then dereferences it.


    Right. Note that the "it" refers to the converted
    value of `v' as it was before being incremented.

    --
     
    Eric Sosman, Dec 13, 2005
    #3
  4. grid

    Skarmander Guest

    grid wrote:
    > Hi,
    > I have a certain situation where a particular piece of code works on a
    > particular compiler but fails on another proprietary compiler.It seems
    > to have been fixed but I just want to confirm if both statements are
    > similar :
    >
    > *((char **)v)++ == *((char **)v++)
    >
    > Where v is a pointer to an array of characters,defined as
    > char *v[];


    These expressions are not equivalent, and if 'v' is truly an array type (as
    opposed to a char**) they are both illegal.

    "*((char **)v)++" casts 'v', postincrements it and dereferences it, which is
    illegal because the operand of the increment operator may not be a cast
    expression (it's not an lvalue).

    "*((char **)v++)" postincrements 'v', casts it and dereferences it, which is
    illegal because the operand of the increment operator may not be of array
    type. This will work if 'v' is a char**, however, in particular if it's a
    function argument declared as "char *v[]". But in this case the cast is
    superfluous, and the statement as a whole is equivalent to simply "*v++"
    (dereferencing and postincrement have the same precedence, and associate
    right-to-left).

    It's unclear what expression you're going for. You might also mean "v[0]++",
    which is equivalent to "(*(char **)v)++" (or simply "(*v)++").

    S.
     
    Skarmander, Dec 13, 2005
    #4
  5. grid

    Skarmander Guest

    Skarmander wrote:
    > grid wrote:
    >> Hi,
    >> I have a certain situation where a particular piece of code works on
    >> a particular compiler but fails on another proprietary compiler.It
    >> seems to have been fixed but I just want to confirm if both statements
    >> are similar :
    >>
    >> *((char **)v)++ == *((char **)v++)
    >>
    >> Where v is a pointer to an array of characters,defined as
    >> char *v[];

    >

    <snip>
    > It's unclear what expression you're going for. You might also mean
    > "v[0]++", which is equivalent to "(*(char **)v)++" (or simply "(*v)++").


    Note that this only applies if 'v' is really an array of *pointers* to
    characters, as your declaration implies. I carelessly glossed over your
    assertion that 'v' is a *pointer to an array*. Then the declaration is
    wrong: it should be "char (*v)[]", mind the parentheses.

    Needless to say, this changes everything... You should be able to work out
    the meaning of the expressions and determine what exactly it is you're going
    for with the information I provided in the previous post, though.

    S.
     
    Skarmander, Dec 13, 2005
    #5
  6. grid

    grid Guest


    >> *((char **)v)++
    >>
    >> Dereferences v and post-increments what it points to.
    >>
    >>

    >
    > No; this one's a constraint violation. Syntactically,
    >it asks for the value of `v' to be converted to type `char**',
    >then for that value to be post-incremented, meanwhile
    >dereferencing the non-incremented value. The constraint
    >violation is the attempt to post-increment the expression
    >`((char**)v)', which is not an lvalue.
    >
    >
    >

    This is code which I dont have any control over.It was initially used as
    simply "*v++".
    But later due to some cleanup and to supress lint warnings changed to
    the above.Does the increment operator work this way :
    *((char **)v) = *((char **)v) + 1
    So that the lvalue cast is a constraint violation.
    I do get the following errors in the proprietary compiler for which I
    have been to forced to change the code :
    Warning : Cast is not lvalue; ++ requires lvalue.
    Error : Modifiable lvalue required with operator "++".

    'v' is as I mentioned earlier a array of pointers to char (an array of
    strings) ,
    char *v[] ;
    And the code moves over these strings one by one passing each string to
    a function ( which expects a char *).Since here we have an array of char
    pointers, I am getting the error on non-modifiable lvalue since an array
    address is a constant.But then that was the reason for the cast to char
    **,to make it increment the pointer over the char *'s.

    >> *((char **)v++)
    >>
    >> Post-increments v itself, and then dereferences it.
    >>
    >>

    >
    > Right. Note that the "it" refers to the converted
    >value of `v' as it was before being incremented.
    >
    >
    >

    I tried it like this to circumvert the errors,but seem to have got the
    logic wrong.Since this increments 'v' prior to the dereferencing,I would
    be missing the first string that gets passed to the fucntion because I
    will get the strings from the second string onwards.
    Ofcourse dereferencing and incrementing 'v' without the cast should work
    fine (*v++), but the first statement seems to work on a particular
    platform.If this is a constraint violation it should be caught on both
    the compilers.

    Thanks for all the insights.
    Appreciate your comments.
    TIA
    ~
     
    grid, Dec 13, 2005
    #6
  7. grid

    Eric Sosman Guest

    grid wrote On 12/13/05 13:30,:
    >>> *((char **)v)++
    >>>
    >>> Dereferences v and post-increments what it points to.
    >>>
    >>>

    >>
    >> No; this one's a constraint violation. Syntactically,
    >>it asks for the value of `v' to be converted to type `char**',
    >>then for that value to be post-incremented, meanwhile
    >>dereferencing the non-incremented value. The constraint
    >>violation is the attempt to post-increment the expression
    >>`((char**)v)', which is not an lvalue.
    >>
    >>
    >>

    >
    > This is code which I dont have any control over.


    Does that mean you cannot change it? The code is
    incorrect C; if you can't change it, you can't fix it.

    > It was initially used as
    > simply "*v++".
    > But later due to some cleanup and to supress lint warnings changed to
    > the above.Does the increment operator work this way :
    > *((char **)v) = *((char **)v) + 1
    > So that the lvalue cast is a constraint violation.


    It's just like `int x; (double)x = 3.14159;' or
    like `(2 + 2)++' or like `printf("hello\n") = 42;'.
    You cannot assign new values to such things.

    > I do get the following errors in the proprietary compiler for which I
    > have been to forced to change the code :
    > Warning : Cast is not lvalue; ++ requires lvalue.
    > Error : Modifiable lvalue required with operator "++".


    The proprietary compiler is correct. But "forced to
    change?" I thought you said you have no control over
    this code ...

    > 'v' is as I mentioned earlier a array of pointers to char (an array of
    > strings) ,
    > char *v[] ;


    As it stands and in isolation, this declaration of
    `v' is incorrect and requires a diagnostic. Please
    provide the rest of the context.

    > And the code moves over these strings one by one passing each string to
    > a function ( which expects a char *).Since here we have an array of char
    > pointers, I am getting the error on non-modifiable lvalue since an array
    > address is a constant.But then that was the reason for the cast to char
    > **,to make it increment the pointer over the char *'s.
    >
    >
    >>> *((char **)v++)
    >>>
    >>> Post-increments v itself, and then dereferences it.
    >>>
    >>>

    >>
    >> Right. Note that the "it" refers to the converted
    >>value of `v' as it was before being incremented.
    >>
    >>
    >>

    >
    > I tried it like this to circumvert the errors,but seem to have got the
    > logic wrong.Since this increments 'v' prior to the dereferencing,I would
    > be missing the first string that gets passed to the fucntion because I
    > will get the strings from the second string onwards.


    You do not understand the post-increment operator (and
    probably don't understand post-decrement, either.) Go back
    to your C textbook. Snap quiz: assuming appropriate headers
    and other context, what is the output of

    int x = 1;
    printf ("%d\n", x++);
    printf ("%d\n", x);

    > Ofcourse dereferencing and incrementing 'v' without the cast should work
    > fine (*v++), but the first statement seems to work on a particular
    > platform.If this is a constraint violation it should be caught on both
    > the compilers.


    Some popular compilers are not really compilers for C
    but for a C-ish language with some extra decorations the
    compiler writers thought would look festive. I strongly
    suspect you're using gcc, in which case you might find it
    instructive to tell it to shed its garish decor and dress
    more soberly: "gcc -W -Wall -ansi -pedantic ..." will get
    it to behave better.

    --
     
    Eric Sosman, Dec 13, 2005
    #7
  8. grid

    Jordan Abel Guest

    On 2005-12-13, Kenneth Brody <> wrote:
    > grid wrote:
    >>
    >> Hi,
    >> I have a certain situation where a particular piece of code works on a
    >> particular compiler but fails on another proprietary compiler.It seems
    >> to have been fixed but I just want to confirm if both statements are
    >> similar :
    >>
    >> *((char **)v)++ == *((char **)v++)

    > [...]
    >
    > No, they are not similar.
    >
    > *((char **)v)++
    >
    > Dereferences v and post-increments what it points to.
    >
    > *((char **)v++)
    >
    > Post-increments v itself, and then dereferences it.


    wrong - if there's a difference, it's in whether the increment applies
    to the cast version of v [which is not standard C, cast results are not
    lvalues] or to the original.

    *x++ === *(x++)
     
    Jordan Abel, Dec 13, 2005
    #8
  9. grid

    Old Wolf Guest

    Eric Sosman wrote:

    > grid wrote On 12/13/05 13:30,:
    >> char *v[] ;

    >
    > As it stands and in isolation, this declaration of
    > `v' is incorrect and requires a diagnostic. Please
    > provide the rest of the context.


    Conceivably the code was:

    foo(v)
    char *v[];
    {
    ...
    }

    which would explain why the original code successfully
    modified v, and why some compilers had trouble with it.

    Also, char *v[]; in isolation could be a tentative definition
    (but that is unlikely given the rest of the OP's message).
     
    Old Wolf, Dec 13, 2005
    #9
  10. grid

    Eric Sosman Guest

    Old Wolf wrote On 12/13/05 17:02,:
    > Eric Sosman wrote:
    >
    >
    >>grid wrote On 12/13/05 13:30,:
    >>
    >>>char *v[] ;

    >>
    >> As it stands and in isolation, this declaration of
    >>`v' is incorrect and requires a diagnostic. Please
    >>provide the rest of the context.

    >
    >
    > Conceivably the code was:
    >
    > foo(v)
    > char *v[];
    > {
    > ...
    > }


    Aha! You're right -- it's been so many years since
    I wrote a prototypeless function definition that I'd all
    but forgotten they existed.

    > which would explain why the original code successfully
    > modified v, and why some compilers had trouble with it.
    >
    > Also, char *v[]; in isolation could be a tentative definition
    > (but that is unlikely given the rest of the OP's message).


    Yes, the tentative definition angle was one of the
    possibilities I thought of, and one reason I asked for
    the rest of the context. Another possiblity was that
    the code actually said `extern char *v[];'. And the
    third, which I thought most likely, was that the context
    looked like `foo(char *v[]) { ... }' and that the
    semicolon had been tacked on by a reflexive error. But
    now I think it more likely that he's really got an old-
    style function definition, fifteen years out of date.

    Anyhow, once the O.P. provides the context we'll
    know for sure, and maybe be able to fix his problem.

    --
     
    Eric Sosman, Dec 13, 2005
    #10
  11. grid

    aegis Guest

    Skarmander wrote:
    > grid wrote:
    > > Hi,
    > > I have a certain situation where a particular piece of code works on a
    > > particular compiler but fails on another proprietary compiler.It seems
    > > to have been fixed but I just want to confirm if both statements are
    > > similar :
    > >
    > > *((char **)v)++ == *((char **)v++)
    > >
    > > Where v is a pointer to an array of characters,defined as
    > > char *v[];

    >
    > These expressions are not equivalent, and if 'v' is truly an array type (as
    > opposed to a char**) they are both illegal.
    >
    > "*((char **)v)++" casts 'v', postincrements it and dereferences it, which is
    > illegal because the operand of the increment operator may not be a cast
    > expression (it's not an lvalue).
    >
    > "*((char **)v++)" postincrements 'v', casts it and dereferences it, which is
    > illegal because the operand of the increment operator may not be of array
    > type. This will work if 'v' is a char**, however, in particular if it's a
    > function argument declared as "char *v[]". But in this case the cast is
    > superfluous, and the statement as a whole is equivalent to simply "*v++"
    > (dereferencing and postincrement have the same precedence, and associate
    > right-to-left).
    >


    I don't know where you learned this but you need to unlearn it.
    This has nothing at all to do with associativity and everything to do
    with precedence.
    Do not confuse prefix ++ and postfix ++ into being one and the same.
    They are both different. In particular, when the prefix ++ operator is
    used in
    conjunction with the indirection operator, associativity is used
    to disambiguate parsing. However, when postfix ++ operator is used in
    conjunction
    with the indirection operator, we use precedence to disambiguate the
    parsing.
    In this case, postfix ++ operator has higher precedence than the
    indirection
    operator and the same precedence as the prefix ++ operator.

    > It's unclear what expression you're going for. You might also mean "v[0]++",
    > which is equivalent to "(*(char **)v)++" (or simply "(*v)++").
    >
    > S.


    I am bewildered by your statement that 'v[0]++' is equivalent to the
    first
    of your options listed. In what regard does 'v[0]++' imply the use of
    a cast? A cast is an explicit construct. The implication of your
    statement is
    that the subscript operator, for some odd reason, uses a cast
    to do its job. However, the standard has something quite different to
    say about how the subscript operator does its job.

    --
    aegis
     
    aegis, Dec 13, 2005
    #11
  12. grid

    Skarmander Guest

    aegis wrote:
    > Skarmander wrote:
    >> grid wrote:
    >>> Hi,
    >>> I have a certain situation where a particular piece of code works on a
    >>> particular compiler but fails on another proprietary compiler.It seems
    >>> to have been fixed but I just want to confirm if both statements are
    >>> similar :
    >>>
    >>> *((char **)v)++ == *((char **)v++)
    >>>
    >>> Where v is a pointer to an array of characters,defined as
    >>> char *v[];

    >> These expressions are not equivalent, and if 'v' is truly an array type (as
    >> opposed to a char**) they are both illegal.
    >>
    >> "*((char **)v)++" casts 'v', postincrements it and dereferences it, which is
    >> illegal because the operand of the increment operator may not be a cast
    >> expression (it's not an lvalue).
    >>
    >> "*((char **)v++)" postincrements 'v', casts it and dereferences it, which is
    >> illegal because the operand of the increment operator may not be of array
    >> type. This will work if 'v' is a char**, however, in particular if it's a
    >> function argument declared as "char *v[]". But in this case the cast is
    >> superfluous, and the statement as a whole is equivalent to simply "*v++"
    >> (dereferencing and postincrement have the same precedence, and associate
    >> right-to-left).
    >>

    >


    > I don't know where you learned this but you need to unlearn it.

    <snip>

    Argh, the famous C precedence lossage. Postincrement associates
    left-to-right and has higher precedence than dereferencing and preincrement,
    which associate right-to-left.

    Honest slip-up. I don't think I need to retake C 101 just yet. :) Thanks
    for pointing this out.

    <snip>
    >> It's unclear what expression you're going for. You might also mean "v[0]++",
    >> which is equivalent to "(*(char **)v)++" (or simply "(*v)++").
    >>

    >
    > I am bewildered by your statement that 'v[0]++' is equivalent to the
    > first of your options listed. In what regard does 'v[0]++' imply the use
    > of a cast?


    It does not. In the particular context given, these expressions are
    equivalent. The sole reason it is provided is for comparison.

    > A cast is an explicit construct. The implication of your statement is
    > that the subscript operator, for some odd reason, uses a cast to do its
    > job.


    This was not my intent, and I apologize for being unclear.

    S.
     
    Skarmander, Dec 14, 2005
    #12
  13. grid

    Jordan Abel Guest

    On 2005-12-14, Skarmander <> wrote:
    > aegis wrote:
    >> Skarmander wrote:
    >>> grid wrote:
    >>>> Hi,
    >>>> I have a certain situation where a particular piece of code works on a
    >>>> particular compiler but fails on another proprietary compiler.It seems
    >>>> to have been fixed but I just want to confirm if both statements are
    >>>> similar :
    >>>>
    >>>> *((char **)v)++ == *((char **)v++)
    >>>>
    >>>> Where v is a pointer to an array of characters,defined as
    >>>> char *v[];
    >>> These expressions are not equivalent, and if 'v' is truly an array type (as
    >>> opposed to a char**) they are both illegal.
    >>>
    >>> "*((char **)v)++" casts 'v', postincrements it and dereferences it, which is
    >>> illegal because the operand of the increment operator may not be a cast
    >>> expression (it's not an lvalue).
    >>>
    >>> "*((char **)v++)" postincrements 'v', casts it and dereferences it, which is
    >>> illegal because the operand of the increment operator may not be of array
    >>> type. This will work if 'v' is a char**, however, in particular if it's a
    >>> function argument declared as "char *v[]". But in this case the cast is
    >>> superfluous, and the statement as a whole is equivalent to simply "*v++"
    >>> (dereferencing and postincrement have the same precedence, and associate
    >>> right-to-left).
    >>>

    >>

    >
    >> I don't know where you learned this but you need to unlearn it.

    > <snip>
    >
    > Argh, the famous C precedence lossage. Postincrement associates
    > left-to-right and has higher precedence than dereferencing and preincrement,
    > which associate right-to-left.


    postincrement and preincrement on the same expression is a constraint
    violation [as the result of either is not an lvalue] violation, so it
    doesn't particularly matter which way they associate.
     
    Jordan Abel, Dec 14, 2005
    #13
  14. grid

    Chris Torek Guest

    >grid wrote:
    >> I have a certain situation where a particular piece of code works on a
    >> particular compiler but fails on another proprietary compiler. ...
    >>
    >> *((char **)v)++

    [ and ]
    >> *((char **)v++)
    >>
    >> Where v is a pointer to an array of characters,defined as
    >> char *v[];


    [I suspect it is not in fact of type "array of UNKNOWN_SIZE of
    pointer to char". As the speculation elsethread runs, perhaps this
    is a function parameter, so that v really has type "pointer to
    pointer to char".]

    In article <439ef26e$0$11069$4all.nl>
    Skarmander <> wrote:
    >These expressions are not equivalent, and if 'v' is truly an array type (as
    >opposed to a char**) they are both illegal.


    Indeed. Your next few paragraphs, however, suffer somewhat from
    the use of pronouns whose referents are not quite clear:

    >"*((char **)v)++" casts 'v', postincrements it and dereferences it,


    Specifically, this binds / breaks down as:

    (char **) [a cast]
    v [puts the variable "v" in a value context]
    ( )++ [post-increment the parenthesized thing]
    * [apply unary indirection to result of post-increment]

    Hence the "it" that is post-incremented is the result of a cast,
    which is a value (rather than an object); the "it" that is
    "dereferenced" (followed via the unary * operator) is the
    result of the post-increment.

    >which is illegal because the operand of the increment operator may
    >not be a cast expression (it's not an lvalue).


    >"*((char **)v++)" postincrements 'v', casts it and dereferences it,


    In this case, the "it"s (and the expression overall) bind as:

    v++ [post-increment the object (not value) v]
    (char **) [cast, i.e., convert value as if by assignment]
    ( ) [technically-unnecessary parentheses]
    * [apply unary indirection to result of cast]

    >which is illegal because the operand of the increment operator may
    >not be of array type.


    Indeed.

    >This will work if 'v' is a char**, however, in particular if it's a
    >function argument declared as "char *v[]". But in this case the cast is
    >superfluous, and the statement as a whole is equivalent to simply "*v++"
    >(dereferencing and postincrement have the same precedence, and associate
    >right-to-left).


    And this, too, is all quite correct. If v really has type "char **",
    just write "*v++".

    >It's unclear what expression you're going for. You might also mean
    >"v[0]++", which is equivalent to "(*(char **)v)++" (or simply "(*v)++").


    I think I would write this as v[0]++ in most cases, myself.
    --
    In-Real-Life: Chris Torek, Wind River Systems
    Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
    email: forget about it http://web.torek.net/torek/index.html
    Reading email is like searching for food in the garbage, thanks to spammers.
     
    Chris Torek, Dec 17, 2005
    #14
  15. On Tue, 13 Dec 2005 20:50:35 +0530, grid <> wrote:

    >Hi,
    > I have a certain situation where a particular piece of code works on a
    >particular compiler but fails on another proprietary compiler.It seems
    >to have been fixed but I just want to confirm if both statements are
    >similar :
    >
    >*((char **)v)++ == *((char **)v++)
    >
    >Where v is a pointer to an array of characters,defined as
    >char *v[];
    >
    >I am passing "v" to a function expecting a char * .


    If v is defined as an "object" (as opposed to a function parameter) of
    type array of pointers to char, then you cannot pass it to a function
    expecting a pointer to char.

    In the context of a function pointer, an array name evaluates to the
    address of the first element of the array with type pointer to element
    type. Therefore v evaluates to &v[0] with type pointer to pointer to
    char. There is no implicit conversion between char** and char*.

    If your compiler is not issuing a diagnostic for your function call,
    either up the warning level or get one that isn't broken.

    While adding a cast will eliminate the diagnostic, it will also lead
    to undefined, or at the very least unexpected, behavior when the
    function executes. If the function dereferences the pointer, it
    expects to find a char. In this case, it will actually find the first
    byte of an address. What happens after that will probably not be
    pleasant.


    <<Remove the del for email>>
     
    Barry Schwarz, Dec 18, 2005
    #15
    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:
    17
    Views:
    6,510
    Greg Comeau
    Sep 22, 2004
  2. Asfand Yar Qazi
    Replies:
    4
    Views:
    401
    Asfand Yar Qazi
    Nov 12, 2004
  3. Martin M.
    Replies:
    4
    Views:
    344
    Simon Brunning
    Dec 15, 2005
  4. Dave Rudolf
    Replies:
    1
    Views:
    304
    Kai-Uwe Bux
    May 17, 2006
  5. David A. Black
    Replies:
    2
    Views:
    228
    Tim Hunter
    Aug 19, 2004
Loading...

Share This Page