incrementing void *

[subramanian100in]

I saw this question from www.brainbench.com

void *ptr;
myStruct myArray[10];

ptr = myArray;

Which of the following is the correct way to increment the variable
"ptr"?
Choice 1 ptr = ptr + sizeof(ptr);
Choice 2 increment(ptr);
Choice 3 ++(int*)ptr;
Choice 4 ptr = ptr + sizeof(myArray);
Choice 5 ptr = ptr + sizeof(myStruct);

THEIR Correct Answer given in this site is: ptr = ptr +
sizeof(myStruct);

But my answer is ++(int*)ptr. The reason is that ptr being void *, we
cannot add any number to it. It must be cast to a valid object before
incrementing.

Which is correct ?

[Ian Collins]

su**************@yahoo.com, India wrote:

I saw this question from www.brainbench.com

void *ptr;
myStruct myArray[10];

ptr = myArray;

Which of the following is the correct way to increment the variable
"ptr"?
Choice 1 ptr = ptr + sizeof(ptr);
Choice 2 increment(ptr);
Choice 3 ++(int*)ptr;
Choice 4 ptr = ptr + sizeof(myArray);
Choice 5 ptr = ptr + sizeof(myStruct);

THEIR Correct Answer given in this site is: ptr = ptr +
sizeof(myStruct);

But my answer is ++(int*)ptr. The reason is that ptr being void *, we
cannot add any number to it. It must be cast to a valid object before
incrementing.

(int*)ptr isn't an lvalue, so you can not increment it.

Which is correct ?

ptr = ptr + sizeof(myStruct);

--
Ian Collins.

[P.J. Plauger]

"Ian Collins" <ia******@hotmail.comwrote in message
news:55**************@mid.individual.net...

su**************@yahoo.com, India wrote:

>I saw this question from www.brainbench.com

void *ptr;
myStruct myArray[10];

ptr = myArray;

Which of the following is the correct way to increment the variable
"ptr"?
Choice 1 ptr = ptr + sizeof(ptr);
Choice 2 increment(ptr);
Choice 3 ++(int*)ptr;
Choice 4 ptr = ptr + sizeof(myArray);
Choice 5 ptr = ptr + sizeof(myStruct);

THEIR Correct Answer given in this site is: ptr = ptr +
sizeof(myStruct);

But my answer is ++(int*)ptr. The reason is that ptr being void *, we
cannot add any number to it. It must be cast to a valid object before
incrementing.

(int*)ptr isn't an lvalue, so you can not increment it.

Nonsense. There are dangers in incrementing (int *)ptr if
myStruct is not on at least as strong a storage boundary as
int (or if you're on a machine where even ten MyStruct are
smaller than a single int). But lvaleness has nothing to do
with it.

>Which is correct ?

ptr = ptr + sizeof(myStruct);

Nonsense. You can't add anything to a void *.

The posed question doesn't answer the burning question,
"increment by what?". One possible sensible interpretation
is to undo the implicit void cast and write:

ptr = ++((myStruct *)ptr);

Yet another is:

ptr = ++((myStruct[10] *)ptr);

These at least have the virtue of being well defined. But
then so does:

ptr = ++(char *)ptr);

so the problem is at least ambiguous. And we still don't
know what the function increment does.

I predict a very long, unimportant thread.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

[subramanian100in]

I myself know that ++(int *)ptr is not correct. But among the five
choices given and if one choice has to be selected,
only ++(int *)ptr can be incremented because only in this case, object
size is known for doing the incrementation.

[Ian Collins]

P.J. Plauger wrote:

>>
(int*)ptr isn't an lvalue, so you can not increment it.

Nonsense. There are dangers in incrementing (int *)ptr if
myStruct is not on at least as strong a storage boundary as
int (or if you're on a machine where even ten MyStruct are
smaller than a single int). But lvaleness has nothing to do
with it.

Oops, I appear to have posted complete bollocks. Sorry.

--
Ian Collins.

[santosh]

su**************@yahoo.com, India wrote:

I saw this question from www.brainbench.com

void *ptr;
myStruct myArray[10];

ptr = myArray;

Which of the following is the correct way to increment the variable
"ptr"?
Choice 1 ptr = ptr + sizeof(ptr);
Choice 2 increment(ptr);
Choice 3 ++(int*)ptr;
Choice 4 ptr = ptr + sizeof(myArray);
Choice 5 ptr = ptr + sizeof(myStruct);

None. The closest is choice two, depending on what the function
exactly does.

THEIR Correct Answer given in this site is: ptr = ptr +
sizeof(myStruct);

You cannot do any arithmetic on void pointers.

But my answer is ++(int*)ptr. The reason is that ptr being void *, we
cannot add any number to it. It must be cast to a valid object before
incrementing.

But why a cast to int *? The more likely cast would be to myStruct *
or myStruct[10] *. Also you can use a cast to unsigned char * to
access the bytes of the array myArray.

[santosh]

su**************@yahoo.com, India wrote:

I myself know that ++(int *)ptr is not correct.

It's not that it is not correct. It's just likely to be wrong.

But among the five
choices given and if one choice has to be selected,
only ++(int *)ptr can be incremented because only in this case, object
size is known for doing the incrementation.

It would work only if myStruct's alignment requirements are only as
strict as for an int, something that's unlikely unless myStruct
happens to be an obfuscatory typedef for int.

I myself, if forced, would've chosen choice two.

[santosh]

P.J. Plauger wrote:

"Ian Collins" <ia******@hotmail.comwrote in message
news:55**************@mid.individual.net...

su**************@yahoo.com, India wrote:

I saw this question from www.brainbench.com

void *ptr;
myStruct myArray[10];

ptr = myArray;

Which of the following is the correct way to increment the variable
"ptr"?
Choice 1 ptr = ptr + sizeof(ptr);
Choice 2 increment(ptr);
Choice 3 ++(int*)ptr;
Choice 4 ptr = ptr + sizeof(myArray);
Choice 5 ptr = ptr + sizeof(myStruct);

THEIR Correct Answer given in this site is: ptr = ptr +
sizeof(myStruct);

But my answer is ++(int*)ptr. The reason is that ptr being void *, we
cannot add any number to it. It must be cast to a valid object before
incrementing.

[ ... ]

Which is correct ?

ptr = ptr + sizeof(myStruct);

Nonsense. You can't add anything to a void *.

The posed question doesn't answer the burning question,
"increment by what?". One possible sensible interpretation
is to undo the implicit void cast and write:

ptr = ++((myStruct *)ptr);

Shouldn't this be:

ptr = ((myStruct *) ptr) + 1;

and similarly for the others?

[Keith Thompson]

"P.J. Plauger" <pj*@dinkumware.comwrites:

"Ian Collins" <ia******@hotmail.comwrote in message
news:55**************@mid.individual.net...

>su**************@yahoo.com, India wrote:

>>I saw this question from www.brainbench.com

void *ptr;
myStruct myArray[10];

ptr = myArray;

Which of the following is the correct way to increment the variable
"ptr"?
Choice 1 ptr = ptr + sizeof(ptr);
Choice 2 increment(ptr);
Choice 3 ++(int*)ptr;
Choice 4 ptr = ptr + sizeof(myArray);
Choice 5 ptr = ptr + sizeof(myStruct);

THEIR Correct Answer given in this site is: ptr = ptr +
sizeof(myStruct);

But my answer is ++(int*)ptr. The reason is that ptr being void *, we
cannot add any number to it. It must be cast to a valid object before
incrementing.

(int*)ptr isn't an lvalue, so you can not increment it.

Nonsense. There are dangers in incrementing (int *)ptr if
myStruct is not on at least as strong a storage boundary as
int (or if you're on a machine where even ten MyStruct are
smaller than a single int). But lvaleness has nothing to do
with it.

Um, are you sure you're not thinking of the C++ rules?

The result of a cast is not an lvalue, and the argument to "++" must
be an lvalue, so Choice 3 is a constraint violation. (Both gcc and
Sun's C compiler complain about it; that doesn't prove anything, but
it does bolster my confidence.) You can add 1 to it, but you can't
increment it with "++".

(Choices 1, 4, and 5 are also constraint violations, since addition
isn't defined for void*. Choice 2 *could* be correct if "increment"
were a carefully crafted macro, but I don't think that's the intent.)

>>Which is correct ?

>ptr = ptr + sizeof(myStruct);

Nonsense. You can't add anything to a void *.

The posed question doesn't answer the burning question,
"increment by what?". One possible sensible interpretation
is to undo the implicit void cast and write:

ptr = ++((myStruct *)ptr);

Yet another is:

ptr = ++((myStruct[10] *)ptr);

These at least have the virtue of being well defined. But
then so does:

ptr = ++(char *)ptr);

so the problem is at least ambiguous. And we still don't
know what the function increment does.

All three of these, if a cast yielded an lvalue, would modify ptr
twice between sequence points and therefore invoke undefined behavior
(<PICKY>and the last one has a missing parenthesis</PICKY>). Changing
"++" to "1 + " should fix that.

I understand that *some* casts in C++ yield lvalues, but I don't know
the rules. Perhaps the question on brainbench.com was actually about
C++? Or maybe it was just wrong.

I'm hesitant to take the risk of disagreeing with P.J. Plauger, but
either I'm right or I'm about to learn something.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

"santosh" <sa*********@gmail.comwrites:

su**************@yahoo.com, India wrote:

>I saw this question from www.brainbench.com

void *ptr;
myStruct myArray[10];

ptr = myArray;

Which of the following is the correct way to increment the variable
"ptr"?
Choice 1 ptr = ptr + sizeof(ptr);
Choice 2 increment(ptr);
Choice 3 ++(int*)ptr;
Choice 4 ptr = ptr + sizeof(myArray);
Choice 5 ptr = ptr + sizeof(myStruct);

None. The closest is choice two, depending on what the function
exactly does.

[...]

If increment is a function, it can't modify ptr. It could be a macro,
though.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Servé Laurijssen]

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...

>Nonsense. There are dangers in incrementing (int *)ptr if
myStruct is not on at least as strong a storage boundary as
int (or if you're on a machine where even ten MyStruct are
smaller than a single int). But lvaleness has nothing to do
with it.

Um, are you sure you're not thinking of the C++ rules?

The result of a cast is not an lvalue, and the argument to "++" must
be an lvalue, so Choice 3 is a constraint violation. (Both gcc and
Sun's C compiler complain about it; that doesn't prove anything, but
it does bolster my confidence.) You can add 1 to it, but you can't
increment it with "++".

it doesnt work in C++ either. +1 would be best

[Richard Tobin]

In article <vd******************************@giganews.com>,
P.J. Plauger <pj*@dinkumware.comwrote:

>>But my answer is ++(int*)ptr. The reason is that ptr being void *, we
cannot add any number to it. It must be cast to a valid object before
incrementing.

>(int*)ptr isn't an lvalue, so you can not increment it.

>Nonsense. There are dangers in incrementing (int *)ptr if
myStruct is not on at least as strong a storage boundary as
int (or if you're on a machine where even ten MyStruct are
smaller than a single int). But lvaleness has nothing to do
with it.

You can add 1 to (int *)ptr, but you can't assign the result to
it, because (int *)ptr is indeed not an lvalue (since some draft
of C89).

You can do ptr = (int *)ptr + 1 which converts the value back
to void * before assigning it to plain uncast ptr.

-- Richard

>The posed question doesn't answer the burning question,
"increment by what?". One possible sensible interpretation
is to undo the implicit void cast and write:

ptr = ++((myStruct *)ptr);

I think you're temporarily confused. You can't apply ++ to cast
expressions in standard C.

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[Richard Tobin]

In article <ln************@nuthaus.mib.org>,
Keith Thompson <ks***@mib.orgwrote:

>The result of a cast is not an lvalue, and the argument to "++" must
be an lvalue, so Choice 3 is a constraint violation. (Both gcc and
Sun's C compiler complain about it; that doesn't prove anything, but
it does bolster my confidence.)

gcc has traditionally allowed this as an extension; gcc 4.0 reports

warning: target of assignment not really an lvalue; this will be a
hard error in the future

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[santosh]

Keith Thompson wrote:

"santosh" <sa*********@gmail.comwrites:

su**************@yahoo.com, India wrote:

I saw this question from www.brainbench.com

void *ptr;
myStruct myArray[10];

ptr = myArray;

Which of the following is the correct way to increment the variable
"ptr"?
Choice 1 ptr = ptr + sizeof(ptr);
Choice 2 increment(ptr);
Choice 3 ++(int*)ptr;
Choice 4 ptr = ptr + sizeof(myArray);
Choice 5 ptr = ptr + sizeof(myStruct);

None. The closest is choice two, depending on what the function
exactly does.

[...]

If increment is a function, it can't modify ptr. It could be a macro,
though.

Yes, careless of me. It's unlikely to be a macro though, given that
it's in lower case.

[ais523]

On Mar 9, 11:02 am, "santosh" <[e-mail]:

Keith Thompson wrote:

"santosh" <[e-mail]:

[e-mail], India wrote:
>I saw this question fromwww.brainbench.com

>void *ptr;
>myStruct myArray[10];

>ptr = myArray;

>Which of the following is the correct way to increment the variable
>"ptr"?
>Choice 1 ptr = ptr + sizeof(ptr);
>Choice 2 increment(ptr);
>Choice 3 ++(int*)ptr;
>Choice 4 ptr = ptr + sizeof(myArray);
>Choice 5 ptr = ptr + sizeof(myStruct);

None. The closest is choice two, depending on what the function
exactly does.

[...]

If increment is a function, it can't modify ptr. It could be a macro,
though.

Yes, careless of me. It's unlikely to be a macro though, given that
it's in lower case

There are several lowercase macros in the standard; stdin (as long as
<stdio.his #included) is one I can think of off the top of my head,
and I know there are others. Anyway, the problem here is that the
answer to 'what is the correct way to increment a void* variable' is
'you don't increment void* variables'; incrementing a void* variable
can't sensibly be defined because void is an incomplete type. The
(incorrect, because sizeof(void) can't be taken) "ptr = (char*)ptr +
sizeof(void);" would come nearest to what the question is asking. On
the other hand, the answer to "what is the correct way to cause ptr to
point at the element of myArray after the one it's currently pointing
at" would be ptr=1+(myStruct*)ptr, assuming that myStruct is a typedef
for a user-defined struct type (which would seem plausible from the
name, but this hasn't been stated). Out of the choices actually given,
2 is the only one that stands a chance of being correct (if increment
is a carefully-defined macro); 1, 4, and 5 all try to do arithmetic on
void* (impossible because void is incomplete), and 3 isn't legal in C
(but is an extension I've seen on more than one compiler, and which I
would use in some cases if it were portable, obviously using myStruct*
rather than int*).
--
ais523

[Eric Sosman]

su**************@yahoo.com, India wrote:

I saw this question from www.brainbench.com

void *ptr;
myStruct myArray[10];

ptr = myArray;

Which of the following is the correct way to increment the variable
"ptr"?
Choice 1 ptr = ptr + sizeof(ptr);
Choice 2 increment(ptr);
Choice 3 ++(int*)ptr;
Choice 4 ptr = ptr + sizeof(myArray);
Choice 5 ptr = ptr + sizeof(myStruct);

THEIR Correct Answer given in this site is: ptr = ptr +
sizeof(myStruct);

But my answer is ++(int*)ptr. The reason is that ptr being void *, we
cannot add any number to it. It must be cast to a valid object before
incrementing.

Which is correct ?

Unless I'm very much mistaken, all five are wrong.

1) Pointer arithmetic is not defined for pointers
to incomplete types. (6.5.6/2)

2) The C language has no keyword, built-in function,
or macro named `increment'.

3) The `++' operator requires a modifiable lvalue as
its operand, and `(int*)ptr' is not a modifiable
lvalue. (6.5.3.1/1, 6.3.2.1/1)

4) See 1.

5) See 1.

A possible quibble could be advanced in favor of 2.
One could make the answer correct (for some definition of
"correct") by introducing an `increment' macro that would
in some sense "increment" its operand. That's trick
question territory, though, and beneath contempt.

--
Eric Sosman
es*****@acm-dot-org.invalid

[AdrianH]

On Mar 9, 12:43 am, "[e-mail], India"
<[e-mail]:

I saw this question fromwww.brainbench.com

void *ptr;
myStruct myArray[10];

ptr = myArray;

Which of the following is the correct way to increment the variable
"ptr"?
Choice 1 ptr = ptr + sizeof(ptr);
Choice 2 increment(ptr);
Choice 3 ++(int*)ptr;
Choice 4 ptr = ptr + sizeof(myArray);
Choice 5 ptr = ptr + sizeof(myStruct);

THEIR Correct Answer given in this site is: ptr = ptr +
sizeof(myStruct);

Who is 'THEIR'?

But my answer is ++(int*)ptr. The reason is that ptr being void *, we
cannot add any number to it. It must be cast to a valid object before
incrementing.

Which is correct ?

I would say "none of the above... maybe".

Choice 1 ptr = ptr + sizeof(ptr);

No, ptr is a void * and void has no size, thus it cannot move the
pointer and is considered an error.

Choice 2 increment(ptr);

This cannot work in C, there is no way of passing ptr by reference
unless you do so explicitly with the & operator.

Choice 3 ++(int*)ptr;

This is the maybe as this may or may not produce an lvalue given
certain compilers. It is not recommended.

Choice 4 ptr = ptr + sizeof(myArray);

Same answer as Choice 1.

Choice 5 ptr = ptr + sizeof(myStruct);

Same answer as Choice 1.

That said, choice 2 and 3 are close, and could work if tweaked:

Choice 2
increment(ptr); // wrong, passing by value cannot change
ptr's value
increment(&ptr); // could work if increment takes a ** and
wraps what actually happens.
Choice 3
++(int*)ptr;
++*(int**)&ptr;

That said, my mod to choice 3 may not work either under some systems
as I think that I read somewhere that conversion of a pointer may not
work as there are special pointers to certain types. I.e. a int
pointer may not be the same as a double pointer. Unfortunately, I
don't remember the reference but should still work in most cases.

The safest bet is doing this:

int * intPtr = (int*)ptr;
++intPtr;
ptr = (void*)intPtr;

Which in my mind would be what is happening internally if you did +
+*(int**)&ptr; If increment is wrapped in a macro which does this,
than it would work. A more generalised macro would be:

#define increment(fromType, toType, ptr) do { \
toType * _tmpPtr_ = (toType*)ptr; \
++_tmpPtr_; \
ptr = (fromType*)_tmpPtr_; \
} while (0)

and then do this:

increment(void, int, ptr);

An increment function that assumes to increment a void pointer as if
it were an int would be:
void increment(void** prt)
{
int* intPtr = (int*)*prt;
++intPtr;
*ptr = (void*)intPtr;
}

but a more generalised solution would be this:

void increment(void** ptr, size_t size)
{
char* charPtr = (char*)*prt;
charPtr += size;
*ptr = (void*)charPtr;
}

the first would be used like:

increment(&ptr);

the second would be used like:

increment(&ptr, sizeof(int));

Does this make sense to you?
Adrian

[Adrian Hawryluk]

AdrianH wrote:

On Mar 9, 12:43 am, "[e-mail], India"
Choice 3
++(int*)ptr;

I've also seen people use this trick, though how portable it is I'm not
sure due to the possiblity that a pointer to different types may not
necessarily be the same (in size or otherwise).

typedef union {
void * vp;
int * ip;
} p;

p ptr = <whatever>; // assigned to void *
++p.ip;
Adrian

[Richard Heathfield]

Adrian Hawryluk said:

AdrianH wrote:

>On Mar 9, 12:43 am, "[e-mail], India"
Choice 3
++(int*)ptr;

I've also seen people use this trick, though how portable it is I'm
not sure due to the possiblity that a pointer to different types may
not necessarily be the same (in size or otherwise).

typedef union {
void * vp;
int * ip;
} p;

p ptr = <whatever>; // assigned to void *
++p.ip;

This will indeed fail on implementations where the representations of
void * and int * differ. For example, to quote the FAQ: "Some 64-bit
Cray machines represent int * in the lower 48 bits of a word; char *
additionally uses some of the upper 16 bits to indicate a byte address
within a word."

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[spacecriter \(Bill C\)]

su**************@yahoo.com wrote:

I saw this question from www.brainbench.com

void *ptr;
myStruct myArray[10];

ptr = myArray;

Which of the following is the correct way to increment the variable
"ptr"?
Choice 1 ptr = ptr + sizeof(ptr);
Choice 2 increment(ptr);
Choice 3 ++(int*)ptr;
Choice 4 ptr = ptr + sizeof(myArray);
Choice 5 ptr = ptr + sizeof(myStruct);

THEIR Correct Answer given in this site is: ptr = ptr +
sizeof(myStruct);

But my answer is ++(int*)ptr. The reason is that ptr being void *, we
cannot add any number to it. It must be cast to a valid object before
incrementing.

Which is correct ?

How about something along the lines of:

ptr = &myArray[j++];

--
Bill C. "I am NOT lost.... I'm *exploring*"

[Adrian Hawryluk]

spacecriter (Bill C) wrote:

su**************@yahoo.com wrote:

>I saw this question from www.brainbench.com

void *ptr;
myStruct myArray[10];

ptr = myArray;

Which of the following is the correct way to increment the variable
"ptr"?
Choice 1 ptr = ptr + sizeof(ptr);
Choice 2 increment(ptr);
Choice 3 ++(int*)ptr;
Choice 4 ptr = ptr + sizeof(myArray);
Choice 5 ptr = ptr + sizeof(myStruct);

THEIR Correct Answer given in this site is: ptr = ptr +
sizeof(myStruct);

But my answer is ++(int*)ptr. The reason is that ptr being void *, we
cannot add any number to it. It must be cast to a valid object before
incrementing.

Which is correct ?

How about something along the lines of:

ptr = &myArray[j++];

What about it?

--
Adrian

[spacecriter \(Bill C\)]

Adrian Hawryluk wrote:

spacecriter (Bill C) wrote:

>su**************@yahoo.com wrote:

>>I saw this question from www.brainbench.com

void *ptr;
myStruct myArray[10];

ptr = myArray;

Which of the following is the correct way to increment the variable
"ptr"?
Choice 1 ptr = ptr + sizeof(ptr);
Choice 2 increment(ptr);
Choice 3 ++(int*)ptr;
Choice 4 ptr = ptr + sizeof(myArray);
Choice 5 ptr = ptr + sizeof(myStruct);

THEIR Correct Answer given in this site is: ptr = ptr +
sizeof(myStruct);

But my answer is ++(int*)ptr. The reason is that ptr being void *,
we cannot add any number to it. It must be cast to a valid object
before incrementing.

Which is correct ?

How about something along the lines of:

ptr = &myArray[j++];

What about it?

I meant to say that this will produce the desired effect (implied by their
"correct" option number 5) without operating on the poiner directly.

--
Bill C. "I am NOT lost.... I'm *exploring*"
'01 FXDXT
'94 Shadow VLX
yank "yercrank" to e-mail

[Ian Collins]

Richard Tobin wrote:

In article <vd******************************@giganews.com>,
P.J. Plauger <pj*@dinkumware.comwrote:

>>>>But my answer is ++(int*)ptr. The reason is that ptr being void *, we
cannot add any number to it. It must be cast to a valid object before
incrementing.

>>>(int*)ptr isn't an lvalue, so you can not increment it.

>>Nonsense. There are dangers in incrementing (int *)ptr if
myStruct is not on at least as strong a storage boundary as
int (or if you're on a machine where even ten MyStruct are
smaller than a single int). But lvaleness has nothing to do
with it.

You can add 1 to (int *)ptr, but you can't assign the result to
it, because (int *)ptr is indeed not an lvalue (since some draft
of C89).

You can do ptr = (int *)ptr + 1 which converts the value back
to void * before assigning it to plain uncast ptr.

>>The posed question doesn't answer the burning question,
"increment by what?". One possible sensible interpretation
is to undo the implicit void cast and write:

ptr = ++((myStruct *)ptr);

I think you're temporarily confused. You can't apply ++ to cast
expressions in standard C.

Thank you Richard, so I didn't post total bollocks after all.

--
Ian Collins.

[Adrian Hawryluk]

spacecriter (Bill C) wrote:

Adrian Hawryluk wrote:

>spacecriter (Bill C) wrote:

>>su**************@yahoo.com wrote:
I saw this question from www.brainbench.com

void *ptr;
myStruct myArray[10];

ptr = myArray;

Which of the following is the correct way to increment the variable
"ptr"?
Choice 1 ptr = ptr + sizeof(ptr);
Choice 2 increment(ptr);
Choice 3 ++(int*)ptr;
Choice 4 ptr = ptr + sizeof(myArray);
Choice 5 ptr = ptr + sizeof(myStruct);

THEIR Correct Answer given in this site is: ptr = ptr +
sizeof(myStruct);

But my answer is ++(int*)ptr. The reason is that ptr being void *,
we cannot add any number to it. It must be cast to a valid object
before incrementing.

Which is correct ?
How about something along the lines of:

ptr = &myArray[j++];

What about it?

I meant to say that this will produce the desired effect (implied by their
"correct" option number 5) without operating on the poiner directly.

It looks correct to me. It is just like saying:

prt = &myArray[j];
j += 1;

Personally, I don't see any reason nowadays for the ++/-- pre/post
operators. Yeah, their somewhat covenant, but they can make code hard
to read. I think the comma operator is more understandable as the
sequence point is *right* there.
Adrian

[P.J. Plauger]

"Ian Collins" <ia******@hotmail.comwrote in message
news:55**************@mid.individual.net...

Richard Tobin wrote:

>In article <vd******************************@giganews.com>,
P.J. Plauger <pj*@dinkumware.comwrote:

>>>>>But my answer is ++(int*)ptr. The reason is that ptr being void *, we
>cannot add any number to it. It must be cast to a valid object before
>incrementing.

>>>>(int*)ptr isn't an lvalue, so you can not increment it.

>>>Nonsense. There are dangers in incrementing (int *)ptr if
myStruct is not on at least as strong a storage boundary as
int (or if you're on a machine where even ten MyStruct are
smaller than a single int). But lvaleness has nothing to do
with it.

You can add 1 to (int *)ptr, but you can't assign the result to
it, because (int *)ptr is indeed not an lvalue (since some draft
of C89).

You can do ptr = (int *)ptr + 1 which converts the value back
to void * before assigning it to plain uncast ptr.

>>>The posed question doesn't answer the burning question,
"increment by what?". One possible sensible interpretation
is to undo the implicit void cast and write:

ptr = ++((myStruct *)ptr);

I think you're temporarily confused. You can't apply ++ to cast
expressions in standard C.

Yep. Been writing too much C++ lately. The irony is that I'm the
guy who insisted that ++x be an rvalue in C89.

Thank you Richard, so I didn't post total bollocks after all.

But I contributed at least a partial version of same.

Thanks for the re-education.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

[Malcolm McLean]

"Adrian Hawryluk" <ad**************************@nospam.comwrote

Personally, I don't see any reason nowadays for the ++/-- pre/post
operators. Yeah, their somewhat covenant, but they can make code hard to
read. I think the comma operator is more understandable as the sequence
point is *right* there.

Preincrement can go.
Postincrement is idiomatic. It means "do something to this, then go on to
the next one".
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[pete]

su**************@yahoo.com, India wrote:

>
I saw this question from www.brainbench.com

void *ptr;
myStruct myArray[10];

ptr = myArray;

Which of the following is the correct way to increment the variable
"ptr"?
Choice 1 ptr = ptr + sizeof(ptr);
Choice 2 increment(ptr);
Choice 3 ++(int*)ptr;
Choice 4 ptr = ptr + sizeof(myArray);
Choice 5 ptr = ptr + sizeof(myStruct);

THEIR Correct Answer given in this site is: ptr = ptr +
sizeof(myStruct);

But my answer is ++(int*)ptr. The reason is that ptr being void *, we
cannot add any number to it. It must be cast to a valid object before
incrementing.

Which is correct ?

ptr = (char *)ptr + sizeof *myArray;

--
pete

[Old Wolf]

On Mar 9, 6:51 pm, "P.J. Plauger" <[e-mail]:

>
ptr = ++((myStruct[10] *)ptr);

These at least have the virtue of being well defined.

As well as what has already been mentioned, this attempted
cast is a syntax error. I guess you mean (mystruct (*)[10]).

[Adrian Hawryluk]

Malcolm McLean wrote:

>
"Adrian Hawryluk" <ad**************************@nospam.comwrote

>Personally, I don't see any reason nowadays for the ++/-- pre/post
operators. Yeah, their somewhat covenant, but they can make code hard
to read. I think the comma operator is more understandable as the
sequence point is *right* there.

Preincrement can go.
Postincrement is idiomatic. It means "do something to this, then go on
to the next one".

Still leads to bad code. Take for instance:

x = y++ + y++;

That has no sequence point between the y++s. x could equal to
(y+1)+(y+1) or (y+1)+(y+2). This goes for all operators except comma
',' which is defined as a sequence point.

Though I guess the same could be said for:

x = (y+=1) + (y+=1);

and other variants. The best thing to do is just not use operators with
side-effects inside an equation.
Adrian

--
================================================== ========
Adrian Hawryluk BSc. Computer Science
----------------------------------------------------------
Specialising in: OOD Methodologies in UML
OOP Methodologies in C, C++ and more
RT Embedded Programming
__--------------------------------------------------__
----- [blog: http://adrians-musings.blogspot.com/] -----
'--------------------------------------------------------'
My newsgroup writings are licensed under the Creative
Commons Attribution-Noncommercial-Share Alike 3.0 License
http://creativecommons.org/licenses/by-nc-sa/3.0/
================================================== ========

[Keith Thompson]

Adrian Hawryluk <ad**************************@nospam.comwrites:

Malcolm McLean wrote:

>"Adrian Hawryluk" <ad**************************@nospam.comwrote

>>Personally, I don't see any reason nowadays for the ++/-- pre/post
operators. Yeah, their somewhat covenant, but they can make code
hard to read. I think the comma operator is more understandable as
the sequence point is *right* there.

Preincrement can go.
Postincrement is idiomatic. It means "do something to this, then go
on to the next one".

Still leads to bad code. Take for instance:

x = y++ + y++;

That has no sequence point between the y++s. x could equal to
(y+1)+(y+1) or (y+1)+(y+2). This goes for all operators except comma
',' which is defined as a sequence point.

Though I guess the same could be said for:

x = (y+=1) + (y+=1);

and other variants. The best thing to do is just not use operators
with side-effects inside an equation.

The best thing to do is to learn the rules and not use operators with
side effects *improperly* inside an expression (I'm not sure what you
mean by "equation"). For example, "x = y++;" is perfectly legitimate.
Even if you choose not to write code like that, you'll need to be able
to read and understand it.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[pete]

Adrian Hawryluk wrote:

x = y++ + y++;

That has no sequence point between the y++s. x could equal to
(y+1)+(y+1) or (y+1)+(y+2). This goes for all operators except comma
',' which is defined as a sequence point.

There are also other operators besides the comma operator
which are sequence points.

--
pete

[websnarf]

<[e-mail]:

I saw this question fromwww.brainbench.com

void *ptr;
myStruct myArray[10];

ptr = myArray;

Which of the following is the correct way to increment the variable
"ptr"?

Increment it with respect to what? Its a void * pointer. If they
mean increment it with respect to the unit of item its pointing at
(likely) then they want you to treat ptr as if it were a myStruct *
rather than a void * pointer. But it is also pointing at a
myStruct[10] array (excuse the Java syntax, C doesn't allow for
ordinary english discourse on this matter) so the question is not well
defined.

Choice 1 ptr = ptr + sizeof(ptr);

There is no indication that ptr is pointing at an array of items that
is the same time as the ptr itself (I think this is a logical
impossiblity; though I could be proven wrong -- I am too lazy to work
it out either way at the moment.) Intuitively, in this case, void *
does not point to void * (that would be void **). If you can
establish that sizeof(void*) == sizeof(myStruct) or sizeof(myArray),
then its hard to make a case for the correctness of this answer.

Choice 2 increment(ptr);

This is not Pascal. But technically I guess it would depend on
whether or not a macro named "increment()" was defined that made this
have a valid interpretation that "incremented ptr".

Choice 3 ++(int*)ptr;

There is no definitively described int here. If myStruct has been
defined at the preprocessor level or via a typedef to be an int, then
this is technically ok, but even then would be in bad form.

Choice 4 ptr = ptr + sizeof(myArray);

This is a possible answer. sizeof (myArray) referrs to the whole
array at once (essential 10 sequential myStruct's). So if the unit of
increment that the question is referring to is the whole myArray, then
this increments to the position right past it. Technically this is
legal in C.

If ptr is meant to be pointing at the entries *in* the myArray array
then, this would not be correct. But because the thing is a void *,
we really don't have a clue as to what the programmer really means
here.

Choice 5 ptr = ptr + sizeof(myStruct);

This also a possible correct answer (and the more likely one.) Here
we are treating ptr as if it were a pointer to the *insides* of
myStruct. I.e., as if ptr is really a myStruct * pointer. The result
after this operation will be to make ptr equal to &myStruct[1].

Now the problem with this, of course, is that there is no good reason
to declare ptr as a void *, if this is how you intend to use it. So
this is a question about the output/result of code that is written in
very bad form.

THEIR Correct Answer given in this site is: ptr = ptr +
sizeof(myStruct);

Of course. They didn't think to hard when making or answering the
question.

But my answer is ++(int*)ptr. The reason is that ptr being void *, we
cannot add any number to it. It must be cast to a valid object before
incrementing.

Yeah, but the question is trying to imply that there is an
*appropriate* object, I think. I can see how you are technically
correct here as well, since you basically just make ptr into something
that can be incremented, then increment it.

However since myStruct is not described, it might be typdefed to a
char or something, and your platform might, theoretically have
sizeof(int)=16 (this will occurr or rare machines in roughly 190 years
from now, if you believe in Moore's Law continuing) at which point ptr
will be pointing *past* the end of any knowably legally defined C
object, which would make this wrong.

Which is correct ?

Well they told you which is the correct answer, so I guess that's the
"correct" one. The question isn't so much about legal C, I think, as
it is about "Can you think like the kind of drone we want you to be?"
I mean the questioner has some notions about how one might interpret a
void * pointer in this context, and he just wants you to interpret it
the same way. Nevermind that there isn't a real iron clad way or
reason for doing so (C standard or not).

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

[J. J. Farrell]

On Mar 12, 10:34 am, Adrian Hawryluk <adrian.hawryluk-at-
[e-mail]:

Malcolm McLean wrote:

"Adrian Hawryluk" <[e-mail]

Personally, I don't see any reason nowadays for the ++/-- pre/post
operators. Yeah, their somewhat covenant, but they can make code hard
to read. I think the comma operator is more understandable as the
sequence point is *right* there.

Preincrement can go.
Postincrement is idiomatic. It means "do something to this, then go on
to the next one".

Still leads to bad code. Take for instance:

x = y++ + y++;

That has no sequence point between the y++s. x could equal to
(y+1)+(y+1) or (y+1)+(y+2). This goes for all operators except comma
',' which is defined as a sequence point.

Though I guess the same could be said for:

x = (y+=1) + (y+=1);

and other variants. The best thing to do is just not use operators with
side-effects inside an equation.

Why is that best? Is it best to not use cars because car drivers
sometimes hit things or people? I'd say the best thing to do in C is
to use C operators correctly and write correct C.

[Miojo Lamen]

"su**************@yahoo.com, India" <su**************@yahoo.comwrote in
news:11*********************@v33g2000cwv.googlegro ups.com:

I saw this question from www.brainbench.com

void *ptr;
myStruct myArray[10];

ptr = myArray;

Which of the following is the correct way to increment the variable
"ptr"?
Choice 1 ptr = ptr + sizeof(ptr);
Choice 2 increment(ptr);
Choice 3 ++(int*)ptr;
Choice 4 ptr = ptr + sizeof(myArray);
Choice 5 ptr = ptr + sizeof(myStruct);

THEIR Correct Answer given in this site is: ptr = ptr +
sizeof(myStruct);

But my answer is ++(int*)ptr. The reason is that ptr being void *, we
cannot add any number to it. It must be cast to a valid object before
incrementing.

Which is correct ?

I have also (wrongly) assumed once that void* had the same arithmetic of a
char*.

So, the answers ALL wrong. The resumee of all answers given was:

1,4 and 5 due to the fact that void* have no arithmetic.
(Choice 5 would be correct if void* has the arithmetic of a char*. Read PS
below)
2 because it would be a macro. But no type is passed.
3 would be correct if myStruct had the same size of an int. But it has the
problem that a casted variable is not a lvalue. (Even in this situation Gcc
compiles and only issues a message of a deprecated feature)

Isn't it?

Regards

PS. A little note
Some compilers (Gcc, under DevC++ 4.9.9.2) don't even issue any warnings to
the following code (which I have compiled in strictly ansi mode)
------------
#include <stdio.h>

int main(void)
{
void *p;

printf("%p", p+1);

return 0;
}
---------

[Keith Thompson]

we******@gmail.com writes:

<[e-mail]:

>I saw this question fromwww.brainbench.com

void *ptr;
myStruct myArray[10];

ptr = myArray;

Which of the following is the correct way to increment the variable
"ptr"?

[snip]

>Choice 4 ptr = ptr + sizeof(myArray);

This is a possible answer. sizeof (myArray) referrs to the whole
array at once (essential 10 sequential myStruct's). So if the unit of
increment that the question is referring to is the whole myArray, then
this increments to the position right past it. Technically this is
legal in C.

No, it isn't. C does not define arithmetic on void* pointers (though
some compilers may do so as an extension).

[...]

>Choice 5 ptr = ptr + sizeof(myStruct);

This also a possible correct answer (and the more likely one.)

Again, C does not define arithmetic on void* pointers.

[...]

All five solutions, with the possible exception of "increment(ptr);"
(*if* increment is defined appropriately as a macro) are illegal.
More precisely, they're constraint violations, requiring compiler
diagnostics from any conforming C compiler.

This has already been discussed at considerable length. If you missed
the discussion, you can see it at groups.google.com.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

Miojo Lamen <mi***@nissin.comwrites:
[...]

PS. A little note
Some compilers (Gcc, under DevC++ 4.9.9.2) don't even issue any warnings to
the following code (which I have compiled in strictly ansi mode)
------------
#include <stdio.h>

int main(void)
{
void *p;

printf("%p", p+1);

return 0;
}
---------

<OT>
With "gcc -ansi -pedantic", or even just "gcc -pedantic", I get:

c.c: In function `main':
c.c:7: warning: pointer of type `void *' used in arithmetic

That's gcc 3.4.4 (not "DevC++").
</OT>

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Richard Heathfield]

su**************@yahoo.com, India said:

I saw this question from www.brainbench.com

void *ptr;
myStruct myArray[10];

ptr = myArray;

[...]

>
THEIR Correct Answer given in this site is: ptr = ptr +
sizeof(myStruct);

If that is the case, then the Brainbench test remains meaningless.

But my answer is ++(int*)ptr.

That's wrong, too.

The reason is that ptr being void *, we
cannot add any number to it. It must be cast to a valid object before
incrementing.

Which is correct ?

Avoiding the Brainbench test would be favourite, I think.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.

[CBFalconer]

Adrian Hawryluk wrote:

>

.... snip ...

>
Still leads to bad code. Take for instance:

x = y++ + y++;

That has no sequence point between the y++s. x could equal to
(y+1)+(y+1) or (y+1)+(y+2). This goes for all operators except comma
',' which is defined as a sequence point.

Or anything else, since the result is undefined. Some models of
the DS9000 will exterminate the programmer.

--
If you want to post a followup via groups.google.com, ensure
you quote enough for the article to make sense. Google is only
an interface to Usenet; it's not Usenet itself. Don't assume
your readers can, or ever will, see any previous articles.
More details at: <http://cfaj.freeshell.org/google/>

--
Posted via a free Usenet account from http://www.teranews.com

[Adrian Hawryluk]

J. J. Farrell wrote:

On Mar 12, 10:34 am, Adrian Hawryluk <adrian.hawryluk-at-
[e-mail]:

>Malcolm McLean wrote:

>>"Adrian Hawryluk" <[e-mail]
Personally, I don't see any reason nowadays for the ++/-- pre/post
operators. Yeah, their somewhat covenant, but they can make code hard
to read. I think the comma operator is more understandable as the
sequence point is *right* there.
Preincrement can go.
Postincrement is idiomatic. It means "do something to this, then go on
to the next one".

Still leads to bad code. Take for instance:

x = y++ + y++;

That has no sequence point between the y++s. x could equal to
(y+1)+(y+1) or (y+1)+(y+2). This goes for all operators except comma
',' which is defined as a sequence point.

Though I guess the same could be said for:

x = (y+=1) + (y+=1);

and other variants. The best thing to do is just not use operators with
side-effects inside an equation.

Why is that best? Is it best to not use cars because car drivers
sometimes hit things or people? I'd say the best thing to do in C is
to use C operators correctly and write correct C.

It can be if the car's wheels are apt to fall off, or the driver is
usually drunk. Yes, it is done, it can be done, it will be done. It is
just not always intuitive as to what is happening, and many people learn
a language by use and not reading a thick specification book of it.

I am not illegitimatising the use of it, I am saying that it makes the
code that much more difficult to read. When you have to do it, fine.
When you do it whimsically without need, then you should just enter the
C Obfuscation contest.

Clarity in programming makes for more maintainable, understandable code,
reducing costs across the board.
Adrian

--
================================================== ========
Adrian Hawryluk BSc. Computer Science
----------------------------------------------------------
Specialising in: OOD Methodologies in UML
OOP Methodologies in C, C++ and more
RT Embedded Programming
__--------------------------------------------------__
----- [blog: http://adrians-musings.blogspot.com/] -----
'--------------------------------------------------------'
My newsgroup writings are licensed under the Creative
Commons Attribution-Noncommercial-Share Alike 3.0 License
http://creativecommons.org/licenses/by-nc-sa/3.0/
================================================== ========

[Adrian Hawryluk]

pete wrote:

Adrian Hawryluk wrote:

>x = y++ + y++;

That has no sequence point between the y++s. x could equal to
(y+1)+(y+1) or (y+1)+(y+2). This goes for all operators except comma
',' which is defined as a sequence point.

There are also other operators besides the comma operator
which are sequence points.

Yes, but I didn't describe any here except for the '='.
Adrian

--
================================================== ========
Adrian Hawryluk BSc. Computer Science
----------------------------------------------------------
Specialising in: OOD Methodologies in UML
OOP Methodologies in C, C++ and more
RT Embedded Programming
__--------------------------------------------------__
----- [blog: http://adrians-musings.blogspot.com/] -----
'--------------------------------------------------------'
My newsgroup writings are licensed under the Creative
Commons Attribution-Noncommercial-Share Alike 3.0 License
http://creativecommons.org/licenses/by-nc-sa/3.0/
================================================== ========

[Adrian Hawryluk]

Keith Thompson wrote:

Adrian Hawryluk <ad**************************@nospam.comwrites:

>Malcolm McLean wrote:

>>"Adrian Hawryluk" <ad**************************@nospam.comwrote
Personally, I don't see any reason nowadays for the ++/-- pre/post
operators. Yeah, their somewhat covenant, but they can make code
hard to read. I think the comma operator is more understandable as
the sequence point is *right* there.

Preincrement can go.
Postincrement is idiomatic. It means "do something to this, then go
on to the next one".

Still leads to bad code. Take for instance:

x = y++ + y++;

That has no sequence point between the y++s. x could equal to
(y+1)+(y+1) or (y+1)+(y+2). This goes for all operators except comma
',' which is defined as a sequence point.

Though I guess the same could be said for:

x = (y+=1) + (y+=1);

and other variants. The best thing to do is just not use operators
with side-effects inside an equation.

The best thing to do is to learn the rules and not use operators with
side effects *improperly* inside an expression (I'm not sure what you
mean by "equation"). For example, "x = y++;" is perfectly legitimate.
Even if you choose not to write code like that, you'll need to be able
to read and understand it.

Agreed, somewhat. Read my further post on using when not necessary
making difficult to read code.
Adrian
--
================================================== ========
Adrian Hawryluk BSc. Computer Science
----------------------------------------------------------
Specialising in: OOD Methodologies in UML
OOP Methodologies in C, C++ and more
RT Embedded Programming
__--------------------------------------------------__
----- [blog: http://adrians-musings.blogspot.com/] -----
'--------------------------------------------------------'
My newsgroup writings are licensed under the Creative
Commons Attribution-Noncommercial-Share Alike 3.0 License
http://creativecommons.org/licenses/by-nc-sa/3.0/
================================================== ========

[pete]

Adrian Hawryluk wrote:

>
pete wrote:

Adrian Hawryluk wrote:

x = y++ + y++;

That has no sequence point between the y++s. x could equal to
(y+1)+(y+1) or (y+1)+(y+2).
This goes for all operators except comma
',' which is defined as a sequence point.

There are also other operators besides the comma operator
which are sequence points.

Yes, but I didn't describe any here except for the '='.

I don't understand your meaning.
The assignment operator is not a sequence point.
The comma operator
has nothing to do with the posted code,
so there is no reason to treat the comma operator
differently from any other operators
which have nothing to do with the posted code.

--
pete

[Adrian Hawryluk]

pete wrote:

Adrian Hawryluk wrote:

>pete wrote:

>>Adrian Hawryluk wrote:

x = y++ + y++;

That has no sequence point between the y++s. x could equal to
(y+1)+(y+1) or (y+1)+(y+2).
This goes for all operators except comma
',' which is defined as a sequence point.
There are also other operators besides the comma operator
which are sequence points.

Yes, but I didn't describe any here except for the '='.

I don't understand your meaning.
The assignment operator is not a sequence point.

Er, When evaluating an initializer. Not the '=' exactly.

The comma operator
has nothing to do with the posted code,

x = y++, y++;

Happy? This is a defined expression with a defined result.

so there is no reason to treat the comma operator
differently from any other operators

Actually, there is reason as some are defined as sequence points and
others are not.

which have nothing to do with the posted code.

I had assumed that you could follow the progression. My mistake.
Adrian
--
__________________________________________________ _________
/__________________Adrian_Hawryluk__BSc.___________ _________\
My newsgroup writings are licensed under the Creative
Commons Attribution-Noncommercial-Share Alike 3.0 License
______http://creativecommons.org/licenses/by-nc-sa/3.0/______
\________[blog: http://adrians-musings.blogspot.com/]_______/

[pete]

Adrian Hawryluk wrote:

>
pete wrote:

Adrian Hawryluk wrote:

pete wrote:
Adrian Hawryluk wrote:

x = y++ + y++;

That has no sequence point between the y++s. x could equal to
(y+1)+(y+1) or (y+1)+(y+2).
This goes for all operators except comma
',' which is defined as a sequence point.
There are also other operators besides the comma operator
which are sequence points.

Yes, but I didn't describe any here except for the '='.

I don't understand your meaning.
The assignment operator is not a sequence point.

Er, When evaluating an initializer. Not the '=' exactly.

I still don't see what you're talking about.
There is no initializer being evaluated in the posted code.
The expression (i = ++i + 1) is given as an example
of undefined behavior in the c99 standard.
If assignment was a sequence point,
there would be nothing wrong with that expression,
but assignment just simply isn't a sequence point.

The comma operator
has nothing to do with the posted code,

x = y++, y++;

Happy? This is a defined expression with a defined result.

(x = y++ && y++) also a defined expression.
I don't understand why you said that the comma operator
is unique as an operator with a sequence point.

so there is no reason to treat the comma operator
differently from any other operators

Actually, there is reason as some are defined as sequence points and
others are not.

which have nothing to do with the posted code.

I had assumed that you could follow the progression. My mistake.

There was no progression to follow.

--
pete

[Richard]

Adrian Hawryluk <ad**************************@nospam.comwrites:

J. J. Farrell wrote:

>On Mar 12, 10:34 am, Adrian Hawryluk <adrian.hawryluk-at-
[e-mail]:

>>Malcolm McLean wrote:

"Adrian Hawryluk" <[e-mail]
Personally, I don't see any reason nowadays for the ++/-- pre/post
operators. Yeah, their somewhat covenant, but they can make code hard
to read. I think the comma operator is more understandable as the
sequence point is *right* there.
Preincrement can go.
Postincrement is idiomatic. It means "do something to this, then go on
to the next one".
Still leads to bad code. Take for instance:

x = y++ + y++;

That has no sequence point between the y++s. x could equal to
(y+1)+(y+1) or (y+1)+(y+2). This goes for all operators except comma
',' which is defined as a sequence point.

Though I guess the same could be said for:

x = (y+=1) + (y+=1);

and other variants. The best thing to do is just not use operators with
side-effects inside an equation.

Why is that best? Is it best to not use cars because car drivers
sometimes hit things or people? I'd say the best thing to do in C is
to use C operators correctly and write correct C.

It can be if the car's wheels are apt to fall off, or the driver is
usually drunk. Yes, it is done, it can be done, it will be done. It
is just not always intuitive as to what is happening, and many people
learn a language by use and not reading a thick specification book of
it.

I am not illegitimatising the use of it, I am saying that it makes the
code that much more difficult to read. When you have to do it,
fine. When you do it whimsically without need, then you should just
enter the C Obfuscation contest.

Clarity in programming makes for more maintainable, understandable
code, reducing costs across the board.

You're wasting your time here with that argument. Certain people here
are so convinced of their skills that they think it will never be
necessary to run a debugger over their code. No joking. They appear to
have almost zero experience of working on huge codebases with legacy
support spread over several continents.

[CBFalconer]

pete wrote:

>

.... snip ...

>
(x = y++ && y++) also a defined expression.

No it isn't.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

--
Posted via a free Usenet account from http://www.teranews.com

[Chris Dollin]

CBFalconer wrote:

pete wrote:

>>

... snip ...

>>
(x = y++ && y++) also a defined expression.

No it isn't.

Is it not? The && introduces a sequence point. Am I missing
something?

--
Chris "electric hedgehog" Dollin
"We live for the One, you die for the One." Unsaid /Babylon 5/.

[Richard Tobin]

In article <45***************@yahoo.com>,
CBFalconer <cb********@maineline.netwrote:

>(x = y++ && y++) also a defined expression.

>No it isn't.

Whyever not?

-- Richard
--
"Consideration shall be given to the need for as many as 32 characters
in some alphabets" - X3.4, 1963.

[santosh]

Chris Dollin wrote:

CBFalconer wrote:

pete wrote:

>

... snip ...

>
(x = y++ && y++) also a defined expression.

No it isn't.

Is it not? The && introduces a sequence point. Am I missing
something?

#include <stdio.h>

int main(void) {
int x = 0, y = 0;
(x = y++ && y++);
printf("x == %d\ty == %d\n", x, y);
return 0;
}

$ ./0102
x == 0 y == 1
$

[Chris Dollin]

santosh wrote:

Chris Dollin wrote:

>CBFalconer wrote:

pete wrote:

... snip ...

(x = y++ && y++) also a defined expression.

No it isn't.

Is it not? The && introduces a sequence point. Am I missing
something?

#include <stdio.h>

int main(void) {
int x = 0, y = 0;
(x = y++ && y++);
printf("x == %d\ty == %d\n", x, y);
return 0;
}

$ ./0102
x == 0 y == 1
$

Um, you missed out the explanation. What are you claiming
to demonstrate?

--
Chris "electric hedgehog" Dollin
"Answer the unanswered riddle." /The Riddle-Master of Hed/