By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,134 Members | 1,796 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,134 IT Pros & Developers. It's quick & easy.

Violating sequence point?

P: n/a

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 ) );
}
--

Frederick Gotham
Jul 5 '06 #1
Share this Question
Share on Google+
15 Replies


P: n/a
On 2006-07-05, Frederick Gotham <fg*******@SPAM.comwrote:
>
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 <http://www.wpsoftware.net/projects/>
To email me, use "apoelstra" at the above address.
"You people hate mathematics." -- James Harris
Jul 5 '06 #2

P: n/a
On 2006-07-05, Andrew Poelstra <ap*******@wpsoftware.netwrote:
On 2006-07-05, Frederick Gotham <fg*******@SPAM.comwrote:
>>
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.
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.)

--
Andrew Poelstra <http://www.wpsoftware.net/projects/>
To email me, use "apoelstra" at the above address.
"You people hate mathematics." -- James Harris
Jul 5 '06 #3

P: n/a
Frederick Gotham <fg*******@SPAM.comwrites:
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.
--
"The fact that there is a holy war doesn't mean that one of the sides
doesn't suck - usually both do..."
--Alexander Viro
Jul 5 '06 #4

P: n/a
Frederick Gotham wrote:
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

Jul 5 '06 #5

P: n/a

Andrew Poelstra wrote:
On 2006-07-05, Andrew Poelstra <ap*******@wpsoftware.netwrote:
On 2006-07-05, Frederick Gotham <fg*******@SPAM.comwrote:
>
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.

Never mind; I read your other post explaining your logic. You should
probably put a comment in there.
Which post would that be ?

Jul 5 '06 #6

P: n/a
Andrew Poelstra said:
On 2006-07-05, Andrew Poelstra <ap*******@wpsoftware.netwrote:
>On 2006-07-05, Frederick Gotham <fg*******@SPAM.comwrote:
>>>
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.

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.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Jul 5 '06 #7

P: n/a

Robert Gamble wrote:
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

Jul 5 '06 #8

P: n/a
Robert Gamble <rg*******@gmail.comwrote:
>
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.

--
Ben.
Working towards a posting to comp.lang.c that is 100% correct.
Jul 5 '06 #9

P: n/a
Frederick Gotham wrote:
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

Jul 5 '06 #10

P: n/a
Ben Bacarisse wrote:
Robert Gamble <rg*******@gmail.comwrote:

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.
No, the construct is undefined even if toupper is a function.

Robert Gamble

Jul 5 '06 #11

P: n/a
Ben Bacarisse wrote:
Robert Gamble <rg*******@gmail.comwrote:
>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.
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.
--
Flash Gordon, living in interesting times.
Web site - http://home.flash-gordon.me.uk/
comp.lang.c posting guidelines and intro:
http://clc-wiki.net/wiki/Intro_to_clc
Jul 5 '06 #12

P: n/a
Flash Gordon <sp**@flash-gordon.me.ukwrote:
Ben Bacarisse wrote:
>Robert Gamble <rg*******@gmail.comwrote:
>>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.

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?

--
Ben.
Jul 5 '06 #13

P: n/a
In article <44**********************@news.zen.co.uk>
Ben Bacarisse <sp**@bsb.me.ukwrote:
>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] = 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;
}
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (4039.22'N, 11150.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.
Jul 5 '06 #14

P: n/a
Tom St Denis wrote:
Frederick Gotham wrote:
> 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
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.
================================================== ===========
Jul 6 '06 #15

P: n/a
Chris Torek <no****@torek.netwrote:
In article <44**********************@news.zen.co.uk>
Ben Bacarisse <sp**@bsb.me.ukwrote:
>>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;
<snip>
return val;
}

int main(void) {
int *p;
<snip>
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.

--
Ben.
Jul 6 '06 #16

This discussion thread is closed

Replies have been disabled for this discussion.