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
~
14  2521 
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>
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
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 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. *((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 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
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++)
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 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
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 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.
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.
>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) +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.
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>> This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: John |
last post by:
Is there an equivalent of COM on Linux that I can get through Python.
My need is to have some sort of language independent component
framework. I can think of CORBA but I have to have a server running. I
prefer not to. I just need Python components for local consumption in
other languages. I remember Gnome libs having some thing like this....
|
by: Michael Foord |
last post by:
Please pardon my ignorance on this one - but I'm not certain how the
sign bt is treated in python bitwise operators. I've trying to convert
a javascript DES encryption routine into python.
Javascritp has >>> and >>. >>> is a zero fill bit shift whereas >> is
a sign propagating bit shift. My understanding is that the python >>
is equivalent...
|
by: Robert Dodier |
last post by:
Hello,
Here's a thought that I'm sure has already occurred to
someone else, I just can't find any record of it yet.
An XML document is just a more verbose and clumsy representation
of an ordinary Lisp S-expression. So it's easy enough to translate
some XML into equivalent Lisp. Now I turn it over to the Lisp
parser, which creates the...
|
by: Vannela |
last post by:
Is there any equivalent control in .NET for the Power
builder DataWindow control?
I am explaining the Datawindow architecture to some extent.
Power Builder DataWindow Control has got different
presentation styles and different data sources.
Presentation styles like tabular format , graph format,
grid format, freeform format, Composite...
|
by: Frank Rachel |
last post by:
So I can focus on the correct areas of research, I was wondering if someone
could give me the .NET equivelents for this J2EE architecture:
JSP's make calls to local JavaBean Controls. The controls do a JNDI lookup
to invoke methods on EJB's. The EJB's use local Java classes, and these
classes use JDBC to do database work.
Example:
...
| | |
by: Marty |
last post by:
Hi,
What is the VB.NET equivalent of the VB6 ADODB.Connector and
ADODB.Recordset?
Thanks
Marty
|
by: Tim Conner |
last post by:
Hi,
I am an ex-delphi programmer, and I having a real hard time with the
following simple code (example ):
Which is the equivalent to the following code ?
var
chars : PChar;
sBack, s : String;
|
by: karch |
last post by:
How would this C# contruct be represented in C++/CLI? Or is it even
possible?
PolicyLevel level = (enumerator->Current) as PolicyLevel;
Thanks,
Karch
|
by: Alan Silver |
last post by:
Hello,
I'm converting some old VB6 code to use with ASP.NET and have come
unstuck with the Asc() function. This was used in the old VB6 code to
convert a character to its ASCII numeric equivalent.
Is there such a function available in C#? I can see that VB.NET has one,
but I couldn't see how to get at it in C#.
For example, if I have...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it.
First, let's disable language...
| | |
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it. ...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven tapestry of website design and digital marketing. It's not merely about having a website; it's about crafting an immersive digital experience that...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each protocol has its own unique characteristics and advantages, but as a user who is planning to build a smart home system, I am a bit confused by the...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules.
He will explain when you may want to use classes...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and then checking html paragraph one by one.
At the time of converting from word file to html my equations which are in the word document file was convert...
| | |
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
| |
