Violating sequence point?

[Frederick Gotham]

Here's a sample function which converts a string to all uppercase:

#include <assert.h>
#include <ctype.h>

void StringUp( char *p )
{
do assert( *p >= 0 );
while( *p = toupper( *p ), *p++ );
}


Would the "Sequence point rule" be violated if the code were changed to the
following:


#include <assert.h>
#include <ctype.h>

void StringUp( char *p )
{
do assert( *p >= 0 );
while( *p++ = toupper( *p ) );
}

 

[Andrew Poelstra]

Here's a sample function which converts a string to all uppercase:

#include <assert.h>
#include <ctype.h>

void StringUp( char *p )
{
do assert( *p >= 0 );
while( *p = toupper( *p ), *p++ );
}

Why is that assert() there? I can see no use for it. Why is the do there?
There's no use for any of that line.

Would the "Sequence point rule" be violated if the code were changed to the
following:


#include <assert.h>
#include <ctype.h>

void StringUp( char *p )
{
do assert( *p >= 0 );
while( *p++ = toupper( *p ) );
}

I think that's okay. It's still best to be clear:
while (*p = toupper ((unsigned char) *p))
*p++;

While that's terrible style IMO, there's no ambiguity.

 

[Andrew Poelstra]

Why is that assert() there? I can see no use for it. Why is the do there?
There's no use for any of that line.

Never mind; I read your other post explaining your logic. You should
probably put a comment in there.

(For others' benefit, the test is because casting to unsigned char is more
of a bandaid than a solution.)

 

[Ben Pfaff]

Would the "Sequence point rule" be violated if the code were changed to the
following: [...]
void StringUp( char *p )
{
do assert( *p >= 0 );
while( *p++ = toupper( *p ) );
}

Yes. There is no sequence point intervening between the
modification of p (in *p++) and its use (in *p). Although a
function call contains a sequence point, the compiler may elect
to evaluate the left side of the assignment and the function
argument before invoking the function call.

Furthermore, toupper may be (and often is) implemented as a macro
that does not contain the same sequence point that the equivalent
function does.

 

[Robert Gamble]

Here's a sample function which converts a string to all uppercase:

#include <assert.h>
#include <ctype.h>

void StringUp( char *p )
{
do assert( *p >= 0 );
while( *p = toupper( *p ), *p++ );
}


Would the "Sequence point rule" be violated if the code were changed to the
following:


#include <assert.h>
#include <ctype.h>

void StringUp( char *p )
{
do assert( *p >= 0 );
while( *p++ = toupper( *p ) );
}

Yes, as would be:

while (*p = toupper(*p++) );

Robert Gamble

 

[spibou]

Never mind; I read your other post explaining your logic. You should
probably put a comment in there.

Which post would that be ?

 

[Richard Heathfield]

Andrew Poelstra said:

Never mind; I read your other post explaining your logic. You should
probably put a comment in there.

(For others' benefit, the test is because casting to unsigned char is more
of a bandaid than a solution.)

But the test is deeply flawed and the cast is a perfectly reasonable
solution to the problem of toupper requiring a character representable as
unsigned char. It may be a band-aid, but it's a highly effective band-aid.
In fact, I can only think of one case where it won't work - and that is the
case where sizeof(int) is 1, which is well-known to be an
assumption-bending situation in lots of other ways too. The reason it
causes problems with toupper is that it offers no way to distinguish
between (char)-1 and (int)-1. Casting doesn't help in such a case.

 

[lovecreatesbeauty]

Yes, as would be:

while (*p = toupper(*p++) );

Robert Gamble

This is more similar to i = i++; that is stated in the FAQ, URL
<http://www.c-faq.com/ansi/experiment.html> .

lovecreatesbeauty

 

[Ben Bacarisse]

Yes, as would be:

while (*p = toupper(*p++) );

My reading of the standard suggests that this (whether the above is
undefined behaviour) can't be decided from the standard alone since an
implementation may implement toupper as a function (rather than as a
macro /and/ a function). A minor change:

while (*p = (toupper)(*p++));

makes it well-defined (modulo the signedness of p) for any conforming
implementation.

Of course, it is quite reasonable to lump all constructs that an
implementation /may/ render undefined as undefined but there is, I think,
a technical difference.

 

[Tom St Denis]

void StringUp( char *p )
{
do assert( *p >= 0 );
while( *p = toupper( *p ), *p++ );
}

I appreciate that your are experimenting with the language but I feel a
word of advice is in order. Don't EVER CODE LIKE THAT in fielded code.
Be very explicit about what you want and let the optimizer worry about
things like that.

Also your assert is kinda useless.

Just write it as

while (*p) { *p = toupper(*p); ++p; }

And be done with.

Tom

 

[Flash Gordon]

My reading of the standard suggests that this (whether the above is
undefined behaviour) can't be decided from the standard alone since an
implementation may implement toupper as a function (rather than as a
macro /and/ a function). A minor change:

while (*p = (toupper)(*p++));

makes it well-defined (modulo the signedness of p) for any conforming
implementation.

No it doesn't. Even with toupper being a function (or forcing it to use
the function) there is no sequence point between evaluating p to get the
address to be written to and evaluating *p++ to find the value to be
passed to toupper, only between evaluating *p++ and calling toupper (and
obviously therefore writing the result to *p whatever that happens to be
at the time). So, for instance, the compiler could do:

A1 = p
p++
*A1 = toupper(*A1)

Or it could do
p++
*p = toupper(*p)

Or, since it is undefined behaviour, anything else it wants. However,
something along the lines of the one of the two examples I show above is
most likely.

Of course, it is quite reasonable to lump all constructs that an
implementation /may/ render undefined as undefined but there is, I think,
a technical difference.

I would tend to do that, but in this case it is not relevant.

 

[Robert Gamble]

My reading of the standard suggests that this (whether the above is
undefined behaviour) can't be decided from the standard alone since an
implementation may implement toupper as a function (rather than as a
macro /and/ a function). A minor change:

while (*p = (toupper)(*p++));

makes it well-defined (modulo the signedness of p) for any conforming
implementation.

No, the construct is undefined even if toupper is a function.

Robert Gamble

 

[Ben Bacarisse]

No it doesn't. Even with toupper being a function (or forcing it to use
the function) there is no sequence point between evaluating p to get the
address to be written to and evaluating *p++ to find the value to be
passed to toupper, only between evaluating *p++ and calling toupper

Ah, thank you, I was not thinking straight -- of course the sequence
point from the call comes too late to make any difference.

Since this has made me go read it all over again, and I can hardly loose
more face by posting more daft stuff, I venture to ask what the meaning
of "access" is in the phrase in section 6.5.2.2:

"If an attempt is made to modify the result of a function call or
to access it after the next sequence point, the behavior is
undefined."

It can't mean "use" since that would seem to render a simple
expression such as f() + g() undefined. Can somone give an example of
such an UB-causing access?

 

[Chris Torek]

Since this has made me go read it all over again, and I can hardly lose
more face by posting more daft stuff, I venture to ask what the meaning
of "access" is in the phrase in section 6.5.2.2:

"If an attempt is made to modify the result of a function call or
to access it after the next sequence point, the behavior is
undefined."

It can't mean "use" since that would seem to render a simple
expression such as f() + g() undefined. Can somone give an example of
such an UB-causing access?

This refers to code like the following:

#include <stdio.h>

struct S { int a[10]; };

struct S new_s(void) {
struct S val;
int i;

for (i = 0; i < 10; i++)
val.a = i;
return val;
}

int main(void) {
int *p;

printf("%d\n", new_s().a[2]); /* defined; prints 2 */

new_s().a[2] = 42; /* undefined - modifies result of function call */

p = new_s().a;
printf("%d\n", p[2]); /* undefined - access after sequence point */

return 0;
}

 

[Stan Milam]

I appreciate that your are experimenting with the language but I feel a
word of advice is in order. Don't EVER CODE LIKE THAT in fielded code.
Be very explicit about what you want and let the optimizer worry about
things like that.

Also your assert is kinda useless.

Just write it as

while (*p) { *p = toupper(*p); ++p; }

And be done with.

Tom

Thank you! To the point and done with it!

--
Regards,
Stan Milam
=============================================================
Charter Member of The Society for Mediocre Guitar Playing on
Expensive Instruments, Ltd.
=============================================================

 

[Ben Bacarisse]

Since this has made me go read it all over again, and I can hardly lose
more face by posting more daft stuff, I venture to ask what the meaning
of "access" is in the phrase in section 6.5.2.2:

"If an attempt is made to modify the result of a function call or
to access it after the next sequence point, the behavior is
undefined."

It can't mean "use" since that would seem to render a simple
expression such as f() + g() undefined. Can somone give an example of
such an UB-causing access?

This refers to code like the following:

#include <stdio.h>

struct S { int a[10]; };

struct S new_s(void) {
struct S val;

return val;
}

int main(void) {
int *p;

p = new_s().a;
printf("%d\n", p[2]); /* undefined - access after sequence point */

return 0;
}

Duh! Of course. Access means to read (or modify) an *object* so to
violate this constraint a program must be able to refer to the object
that is the result of the function and not just its value.

Thanks.