Are they equivalent ?

[grid]

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
~

[Kenneth Brody]

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:Th*************@gmail.com>

[Eric Sosman]

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.

--
Er*********@sun.com

[Skarmander]

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]

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.

[grid]

*((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
~

[Eric Sosman]

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.

--
Er*********@sun.com

[Jordan Abel]

On 2005-12-13, Kenneth Brody <ke******@spamcop.net> 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++)

[Old Wolf]

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).

[Eric Sosman]

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.

--
Er*********@sun.com

[aegis]

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

[Skarmander]

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.

[Jordan Abel]

On 2005-12-14, Skarmander <in*****@dontmailme.com> 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.

[Chris Torek]

>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 <43***********************@news.xs4all.nl>
Skarmander <in*****@dontmailme.com> 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) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Barry Schwarz]

On Tue, 13 Dec 2005 20:50:35 +0530, grid <pr******@gmail.com> 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>>