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

On 2006-07-05, Frederick Gotham <fgothamNO@SPAM.com> 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++ );
>     }
>
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

On 2006-07-05, Andrew Poelstra <apoelstra@wpsoftware.net> wrote:
> On 2006-07-05, Frederick Gotham <fgothamNO@SPAM.com> 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++ );
>>     }
>>
> 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

Frederick Gotham <fgothamNO@SPAM.com> writes:

> 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

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

Andrew Poelstra wrote:

> On 2006-07-05, Andrew Poelstra <apoelstra@wpsoftware.net> wrote:
> > On 2006-07-05, Frederick Gotham <fgothamNO@SPAM.com> 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++ );
> >>     }
> >>
> > 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 ?

Andrew Poelstra said:

> On 2006-07-05, Andrew Poelstra <apoelstra@wpsoftware.net> wrote:
>> On 2006-07-05, Frederick Gotham <fgothamNO@SPAM.com> 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++ );
>>>     }
>>>
>> 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)

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

Robert Gamble <rgamble99@gmail.com> wrote:
>
> 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.

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

Ben Bacarisse wrote:
> Robert Gamble <rgamble99@gmail.com> wrote:
>> 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

Ben Bacarisse wrote:
> Robert Gamble <rgamble99@gmail.com> wrote:
> >
> > 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

Flash Gordon <spam@flash-gordon.me.uk> wrote:
> Ben Bacarisse wrote:
>> Robert Gamble <rgamble99@gmail.com> wrote:
>>> 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.

In article <44abf5f7$0$4383$da0feed9@news.zen.co.uk>
Ben Bacarisse  <spam@bsb.me.uk> wrote:
>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 (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.

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.
  =============================================================

Chris Torek <nospam@torek.net> wrote:
> In article <44abf5f7$0$4383$da0feed9@news.zen.co.uk>
> Ben Bacarisse  <spam@bsb.me.uk> wrote:
>>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.