Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Are they equivalent ?

Reply
Thread Tools

Are they equivalent ?

 
 
grid
Guest
Posts: n/a
 
      12-13-2005
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
~
 
Reply With Quote
 
 
 
 
Kenneth Brody
Guest
Posts: n/a
 
      12-13-2005
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: <(E-Mail Removed)>

 
Reply With Quote
 
 
 
 
Eric Sosman
Guest
Posts: n/a
 
      12-13-2005


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.

--
http://www.velocityreviews.com/forums/(E-Mail Removed)

 
Reply With Quote
 
Skarmander
Guest
Posts: n/a
 
      12-13-2005
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.
 
Reply With Quote
 
Skarmander
Guest
Posts: n/a
 
      12-13-2005
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.
 
Reply With Quote
 
grid
Guest
Posts: n/a
 
      12-13-2005

>> *((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
~
 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      12-13-2005


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.

--
(E-Mail Removed)

 
Reply With Quote
 
Jordan Abel
Guest
Posts: n/a
 
      12-13-2005
On 2005-12-13, Kenneth Brody <(E-Mail Removed)> 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++)
 
Reply With Quote
 
Old Wolf
Guest
Posts: n/a
 
      12-13-2005
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).

 
Reply With Quote
 
Eric Sosman
Guest
Posts: n/a
 
      12-13-2005


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.

--
(E-Mail Removed)

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Tokina, Sigma, Tamron --- Are they equivalent in quality? Dave Digital Photography 40 04-11-2007 12:34 PM
Re: "memset" vs "= {0}"...Are they equivalent if your initializing variables? C++ 1 09-23-2004 02:03 PM
Re: "memset" vs "= {0}"...Are they equivalent if your initializing variables? C++ 0 09-23-2004 01:28 PM
"memset" vs "= {0}"...Are they equivalent if your initializing variables? Nollie@runtime.com C++ 17 09-22-2004 06:06 PM
they turn, they power, they make nice pics Keith and Jenn Z. Digital Photography 0 09-21-2003 04:16 AM



Advertisments