Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #10100 > unrolled thread

Unexpected output

Back to article view | Back to comp.lang.c

Contents

  Unexpected output Mazen <neurohacks@gmail.com> - 2011-09-10 12:36 -0700
    Re: Unexpected output China Blue Corn Chips <chine.bleu@yahoo.com> - 2011-09-10 12:59 -0700
      Re: Unexpected output Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-09-10 16:42 -0400
        Re: Unexpected output Mazen <neurohacks@gmail.com> - 2011-09-10 17:51 -0700
          Re: Unexpected output Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-09-10 20:38 -0600
          Re: Unexpected output pete <pfiland@mindspring.com> - 2011-09-10 22:41 -0400
          Re: Unexpected output Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-09-11 09:35 -0400
            Re: Unexpected output gazelle@shell.xmission.com (Kenny McCormack) - 2011-09-11 13:39 +0000
          Re: Unexpected output "BartC" <bc@freeuk.com> - 2011-09-11 15:26 +0100
        Re: Unexpected output Paul N <gw7rib@aol.com> - 2011-09-11 12:08 -0700
          Re: Unexpected output Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-09-11 17:43 -0400
      Re: Unexpected output Mazen <neurohacks@gmail.com> - 2011-09-10 13:24 -0700
        Re: Unexpected output China Blue Corn Chips <chine.bleu@yahoo.com> - 2011-09-10 15:02 -0700
      Re: Unexpected output Kenneth Brody <kenbrody@spamcop.net> - 2011-09-12 10:01 -0400
    Re: Unexpected output arni <arnmin@gmail.com> - 2011-09-10 13:31 -0700
      Re: Unexpected output Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-09-10 16:49 -0400
        Re: Unexpected output arni <arnmin@gmail.com> - 2011-09-10 14:13 -0700
          Re: Unexpected output Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-09-10 17:26 -0400
            Re: Unexpected output Mazen <neurohacks@gmail.com> - 2011-09-10 17:59 -0700
              Re: Unexpected output Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-09-10 20:52 -0600
                Re: Unexpected output China Blue Corn Chips <chine.bleu@yahoo.com> - 2011-09-10 19:55 -0700
                Re: Unexpected output Nick Keighley <nick_keighley_nospam@hotmail.com> - 2011-09-11 06:03 -0700
                  Re: Unexpected output James Kuyper <jameskuyper@verizon.net> - 2011-09-11 14:04 -0400
              Re: Unexpected output Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-09-11 11:22 +0100
              Re: Unexpected output Keith Thompson <kst-u@mib.org> - 2011-09-11 11:01 -0700
                Re: Unexpected output Phil Carmody <thefatphil_demunged@yahoo.co.uk> - 2011-09-13 14:09 +0300
          Re: Unexpected output Seebs <usenet-nospam@seebs.net> - 2011-09-13 06:44 +0000
      Re: Unexpected output "Morris Keesan" <mkeesan@post.harvard.edu> - 2011-09-10 17:16 -0400
    Re: Unexpected output "BartC" <bc@freeuk.com> - 2011-09-10 23:20 +0100
    Re: Unexpected output August Karlstrom <fusionfile@gmail.com> - 2011-09-11 22:55 +0200
      Re: Unexpected output Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-09-11 22:51 +0100
        Re: Unexpected output pete <pfiland@mindspring.com> - 2011-09-11 22:25 -0400
        Re: Unexpected output August Karlstrom <fusionfile@gmail.com> - 2011-09-12 15:34 +0200
          Re: Unexpected output Ben Bacarisse <ben.usenet@bsb.me.uk> - 2011-09-12 19:55 +0100
            Re: Unexpected output August Karlstrom <fusionfile@gmail.com> - 2011-09-13 19:22 +0200

Page 2 of 2 — ← Prev page 1 [2]

#10120

In article <1blitv6bah.fsf@snowball.wb.pfeifferfamily.net>,
 Joe Pfeiffer <pfeiffer@cs.nmsu.edu> wrote:

> I would be very surprised if anybody actually knows how many ways there
> are to provoke undefined output.  I supposed searching the standard for

A good evaluation programmer would have an idea.

-- 
I remember finding out about you,  |With the nutty taste of wild hickory nuts.
Everyday my mind is all around you,|            I'm whoever you want me to be.
Looking out from my lonely room    |       Annoying Usenet one post at a time.
Day after day.                     |         At least I can stay in character.
Celle est une langue. C'est francais et tres, tres sexuel.

[toc] | [prev] | [next] | [standalone]

#10130

On Sep 11, 3:52 am, Joe Pfeiffer <pfeif...@cs.nmsu.edu> wrote:
> Mazen <neuroha...@gmail.com> writes:
>
> > I have learned the attempting to assign a value to a variable and
> > fetching the value of it in the same expression will produce an
> > undefined behaviour. What are some of the other cases that produce
> > undefined behaviour? This is interesting!
>
> That isn't what you should have learned, because that's perfectly well
> defined.  If your printf() had been
>
>   printf("%d ", i = +j);
>   printf("%d\n", i = -j);
>
> it would have printed the 2 -2 you expected -- though the first
> assignment to i would still have been silly, and doing the second
> assignment in the printf() would still have been useless obfuscation.
>
> What was undefined was the order in which your three arguments
> to printf() were evaluated, in a context where different orders of
> evaluation would give different results.
>
> I would be very surprised if anybody actually knows how many ways there
> are to provoke undefined output.

I think there's an appendix in the standard that lists the undefined
bahaviours


 I supposed searching the standard for
> the word "undefined" would help, but of course that would only tell you
> all the ways the standard actually says something is undefined, and miss
> all the possible things you could do that just don't have definitions.
>
> But, frankly, the only reason to want to know what isn't defined is to
> avoid doing it.  And "don't write obviously silly code" (like your
> original printf() ) is one of the most basic rules for doing that.

[toc] | [prev] | [next] | [standalone]

#10137

On 09/11/2011 09:03 AM, Nick Keighley wrote:

> I think there's an appendix in the standard that lists the undefined
> bahaviours

I don't think you said what you meant to say: "undefined behaviors" is a
category that includes all behaviors; a set far easier to describe than
to list. :-) The list would be of negligible value even if it the list
could easily be created.

Annex J.2 does list features that program can have that can cause the
behavior to be undefined. Note, however, that it cannot be
all-inclusive. Behavior that is undefined "by omission of any explicit
definition of behavior" (4p6), is inherently difficult to identify and list.
-- 
James Kuyper

[toc] | [prev] | [next] | [standalone]

#10127

Mazen <neurohacks@gmail.com> writes:
<snip>
> I have learned the attempting to assign a value to a variable and
> fetching the value of it in the same expression will produce an
> undefined behaviour. What are some of the other cases that produce
> undefined behaviour? This is interesting!

If that were true, C would not allow:

  x = x + 1;

The wording is:

  "Between the previous and next sequence point an object shall have its
  stored value modified at most once by the evaluation of an
  expression. Furthermore, the prior value shall be read only to
  determine the value to be stored."

so you may read the value (x) to determine the value to be stored (x +
1).  However, in your case, the problem was modifying the value twice.

To understand the rule, you have to know where the sequence points are in
a C program.  The standard has a list (edited here for clarity):

  1. The call to a function, after the arguments have been evaluated

  2. The end of the first operand of the following operators: logical
     AND &&; logical OR ||; conditional ?; comma , .

  3. The end of a full declarator: declarators.

  4. The end of a full expression: an initializer; the expression in an
     expression statement; the controlling expression of a selection
     statement (if or switch); the controlling expression of a while or
     do statement; each of the expressions of a for statement; the
     expression in a return statement.

  5. Immediately before a library function returns.

  6. After the actions associated with each formatted input/output
     function conversion specifier.

  7. Immediately before and immediately after each call to a comparison
     function, and also between any call to a comparison function and
     any movement of the objects passed as arguments to that call.

As has been pointed out, the comma in number 2 is the operator and does
not appear in a normal function call -- that comma is just syntax for
the call.  Number 7 is about the internals of the qsort and bsearch
library functions.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#10136

Mazen <neurohacks@gmail.com> writes:
[...]
> I have learned the attempting to assign a value to a variable and
> fetching the value of it in the same expression will produce an
> undefined behaviour.

As Joe Pfeiffer points out, that's not quite correct.

>                      What are some of the other cases that produce
> undefined behaviour? This is interesting!

Grab a copy of the latest C99 draft from

    http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf

and read section J.2.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

[toc] | [prev] | [next] | [standalone]

#10182

Keith Thompson <kst-u@mib.org> writes:
> Mazen <neurohacks@gmail.com> writes:
> [...]
> > I have learned the attempting to assign a value to a variable and
> > fetching the value of it in the same expression will produce an
> > undefined behaviour.
> 
> As Joe Pfeiffer points out, that's not quite correct.
> 
> >                      What are some of the other cases that produce
> > undefined behaviour? This is interesting!
> 
> Grab a copy of the latest C99 draft from
> 
>     http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf
> 
> and read section J.2.

This might be a better introduction, to lead up to the formality 
of the official docs:
  http://c-faq.com/expr/index.html

Phil
-- 
"Religion is what keeps the poor from murdering the rich."
-- Napoleon

[toc] | [prev] | [next] | [standalone]

#10178

On 2011-09-10, arni <arnmin@gmail.com> wrote:
> On Sep 10, 11:49?pm, Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
>> On 9/10/2011 4:31 PM, arni wrote:
>> > Shouldn't it be i+=j and i-=j?.. Then you'll get 2 -2.

>> ? ? ?Or not: The behavior would still be undefined, and for the
>> same reason as before.

> Depends on compiler/optimizer implementation.

Whether or not it is undefined does not depend on that.  What you get does.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

[toc] | [prev] | [next] | [standalone]

#10107

On Sat, 10 Sep 2011 16:31:33 -0400, arni <arnmin@gmail.com> wrote:

> On Sep 10, 10:36 pm, Mazen <neuroha...@gmail.com> wrote:
>> Hello,
>>
>> Following is a simple program:
>>
>> #include <stdio.h>
>>
>> int main(void) {
>>   int i = 0, j, k;
>>   j = k = 2;
>>
>>   printf("%d %d\n", i=+j, i=-j);
>>
>>   return 0;
>>
>> }
>>
>> The output is
>> 2 2
>>
>> Shouldn't the second expression be -2 rather than 2? I'm confused.
>> Your insights pls. Thanks!
>
> Shouldn't it be i+=j and i-=j?.. Then you'll get 2 -2.

No.  If modifying i twice in the argument list weren't undefined,
so that one assignment to i and the evaluation of the corresponding
function argument were guaranteed to be complete before the next
argument was evaluated, printf("%d %d\n", i += j, i -= j) would produce
either "2 0" or "0 -2", depending on the order in which the arguments
are evaluated, which is unspecified (not undefined).  The poorly-spaced
code seems to have been intended as printf("%d %d\n", i = +j, i = -j);
-- 
Morris Keesan -- mkeesan@post.harvard.edu

[toc] | [prev] | [next] | [standalone]

#10113

"Mazen" <neurohacks@gmail.com> wrote in message 
news:8787e0b5-b4c3-463f-bd9a-6ffc30034950@x29g2000prh.googlegroups.com...

> #include <stdio.h>
>
> int main(void) {
>  int i = 0, j, k;
>  j = k = 2;
>
>  printf("%d %d\n", i=+j, i=-j);
>
>  return 0;
> }
>
> The output is
> 2 2
>
> Shouldn't the second expression be -2 rather than 2? I'm confused.

It *is* unintuitive. But printf() is a function, and sometimes the 
parameters are evaluated in a funny order:

#include <stdio.h>

int next(void){static int a=0; return ++a;}

int main(void){
 printf("%d %d %d\n",next(),next(),next());
}

gives 1 2 3 on one compiler, and 3 2 1 on another (and doubtless some 
compiler might give 3 1 2!).

Changing main() to resemble your code:

int main(void){
 int i;
 printf("%d %d %d",i=next(),i=next(),i=next());
}

Now I get results on 1 2 3, 3 3 3, and 3 2 1 on three different compilers!

For guaranteed results, you need to use a separate printf() call for each 
term.

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#10142

On 2011-09-10 21:36, Mazen wrote:
> Hello,
>
> Following is a simple program:
>
> #include<stdio.h>
>
> int main(void) {
>    int i = 0, j, k;
>    j = k = 2;
>
>    printf("%d %d\n", i=+j, i=-j);
>
>    return 0;
> }
>
> The output is
> 2 2
>
> Shouldn't the second expression be -2 rather than 2? I'm confused.
> Your insights pls. Thanks!

One obvious insight is that it's best to avoid side effects in 
expressions if possible.


August

-- 
The competent programmer is fully aware of the limited size of his own 
skull. He therefore approaches his task with full humility, and avoids 
clever tricks like the plague. --Edsger Dijkstra

[toc] | [prev] | [next] | [standalone]

#10147

August Karlstrom <fusionfile@gmail.com> writes:

> On 2011-09-10 21:36, Mazen wrote:
>> Hello,
>>
>> Following is a simple program:
>>
>> #include<stdio.h>
>>
>> int main(void) {
>>    int i = 0, j, k;
>>    j = k = 2;
>>
>>    printf("%d %d\n", i=+j, i=-j);
>>
>>    return 0;
>> }
>>
>> The output is
>> 2 2
>>
>> Shouldn't the second expression be -2 rather than 2? I'm confused.
>> Your insights pls. Thanks!
>
> One obvious insight is that it's best to avoid side effects in
> expressions if possible.

The devil is in the detail.  You presumably think that x = 1; is OK so
what about x++?  How do you feel about *cp++ = 0?  Maybe *dp++ = *s++?

At some stage most C programmers need to know what's permitted and what
is not.  They may never need to know the rule itself, but they will
probably come up with the notion that, if an expression can yield two
different results with different (permitted) evaluation orders, then
there be dragons.  This has the advantage of focusing on possible
evaluation orders which is an essential part of C programming.
printf("%d %d", f(), g()) may not be undefined, but the programmer would
be well advised to know that the order of execution is not specified.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#10149

Ben Bacarisse wrote:
> 
> August Karlstrom <fusionfile@gmail.com> writes:
> 
> > On 2011-09-10 21:36, Mazen wrote:
> >> Hello,
> >>
> >> Following is a simple program:
> >>
> >> #include<stdio.h>
> >>
> >> int main(void) {
> >>    int i = 0, j, k;
> >>    j = k = 2;
> >>
> >>    printf("%d %d\n", i=+j, i=-j);
> >>
> >>    return 0;
> >> }
> >>
> >> The output is
> >> 2 2
> >>
> >> Shouldn't the second expression be -2 rather than 2? I'm confused.
> >> Your insights pls. Thanks!
> >
> > One obvious insight is that it's best to avoid side effects in
> > expressions if possible.
> 
> The devil is in the detail.  You presumably think that x = 1; is OK so
> what about x++? 

(x = 1) has a side effect in an expression.
I avoid side effects in arguments in function calls.

-- 
pete

[toc] | [prev] | [next] | [standalone]

#10150

On 2011-09-11 23:51, Ben Bacarisse wrote:
> August Karlstrom<fusionfile@gmail.com>  writes:
>> One obvious insight is that it's best to avoid side effects in
>> expressions if possible.
>
> The devil is in the detail.  You presumably think that x = 1; is OK so
> what about x++?

Both `x = 1;' and `x++;' are atomic statements (they cannot be 
decomposed into some other sequence of simpler statements), so yes they 
are certainly OK.

> How do you feel about *cp++ = 0?  Maybe *dp++ = *s++?

I feel that there is too much going on in each of these. Of course this 
is to some degree a matter of preference but personally I don't think 
these statements communicate very well and I think they are inherently ugly.

> At some stage most C programmers need to know what's permitted and what
> is not.

Yes, but if you write new code and adhere to the KISS principle you 
don't need to bother with a lot of C's subtleties.


August

-- 
The competent programmer is fully aware of the limited size of his own 
skull. He therefore approaches his task with full humility, and avoids 
clever tricks like the plague. --Edsger Dijkstra

[toc] | [prev] | [next] | [standalone]

#10159

August Karlstrom <fusionfile@gmail.com> writes:

> On 2011-09-11 23:51, Ben Bacarisse wrote:
>> August Karlstrom<fusionfile@gmail.com>  writes:
>>> One obvious insight is that it's best to avoid side effects in
>>> expressions if possible.
>>
>> The devil is in the detail.  You presumably think that x = 1; is OK so
>> what about x++?
>
> Both `x = 1;' and `x++;' are atomic statements (they cannot be
> decomposed into some other sequence of simpler statements), so yes
> they are certainly OK.
>
>> How do you feel about *cp++ = 0?  Maybe *dp++ = *s++?
>
> I feel that there is too much going on in each of these. Of course
> this is to some degree a matter of preference but personally I don't
> think these statements communicate very well and I think they are
> inherently ugly.

That's a logical place to draw the line, but I can't go along with it.
I can't say why except that is seems un-C-like to reject them.  There's
no logic to my point of view -- it seems to be no more that a matter to
taste than anything else.

<snip>
-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#10196

On 2011-09-12 20:55, Ben Bacarisse wrote:
> August Karlstrom<fusionfile@gmail.com>  writes:
>> On 2011-09-11 23:51, Ben Bacarisse wrote:
>>> How do you feel about *cp++ = 0?  Maybe *dp++ = *s++?
>>
>> I feel that there is too much going on in each of these. Of course
>> this is to some degree a matter of preference but personally I don't
>> think these statements communicate very well and I think they are
>> inherently ugly.
>
> That's a logical place to draw the line, but I can't go along with it.
> I can't say why except that is seems un-C-like to reject them.  There's
> no logic to my point of view -- it seems to be no more that a matter to
> taste than anything else.

The question is, when does a statement become too complex? Programming 
should be about reducing complexity, not adding to it. That's why 
structured programming, user defined functions and so on was invented. I 
myself prefer to focus my energy on algorithms rather than on 
intricacies of the programming language.

Also, a complex expression with multiple side effects in a statement 
does not make the algorithm any simpler - only shorter, but not simpler. 
Moreover, it is only shorter notation-wise; if your read such a 
statement aloud or write it in plain English it is not shorter. It just 
makes for a longer and more convoluted sentence.

So, although writing convoluted code is a part of the C tradition, if 
you can resist the temptation of saving a few keystrokes you will 
probably save some maintenance time in the future. As we all know, C 
does not enforce or advocate any particular coding style. On the 
contrary, giving the programmer maximum freedom, and that includes the 
freedom to write clear code, is the spirit of C.


August

-- 
The competent programmer is fully aware of the limited size of his own 
skull. He therefore approaches his task with full humility, and avoids 
clever tricks like the plague. --Edsger Dijkstra

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.c

csiph-web