lkml.org 
[lkml]   [1999]   [May]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: fork() Problem?
    From
    Date
    "Richard B. Johnson" <root@chaos.analogic.com> writes:

    > > K&R 2nd Edition, page 208 says:
    > >
    > > "The type of an assignment expression is that of its left operand,
    > > and the value is the value stored in the left operand after the
    > > assignment has taken place."
    > >
    > > The ANSI C standard says in section 6.3.16:
    > >
    > > "An assignment expression has the value of the left operand after
    > > the assignment, but is not an lvalue."
    > >
    > > This means the expression "i=foo()" evaluates to whatever the value of
    > > 'i' is after the assignment; if 'i' is zero, then the expression
    > > evaluates to zero.
    > >
    >
    > No it does not. It means, exactly what it says. It says that the
    > type is that of the left operand (promotion rules) and the value
    > is the value stored in the left operand after the assignment has
    > taken place. It says nothing more.

    Did you even bother to read what I wrote? I said that the expression
    evaluates to whatever is stored in "i", and you tell me that I'm wrong
    and that it's really whatever is stored in "i". Huh? Do you not
    understand what the word "evaluates" means, or are you just trying to
    be difficult?

    By the way, this has absolutely nothing to do with type promotion. If
    you think it does, I'd appreciate a reference to the part of the
    standard that says it does.

    > > Since page 208 tells us that "i=foo()" has the type "int", which is an
    > > arithmetic type, "i=foo()" is a perfectly legal expression for an if
    > > statement. Its behaviour is well-defined and documented by both K&R
    > > and the ANSI standard. If "i=foo()" evaluates to non-zero, the
    > > statement is executed. If "i=foo()" evaluates to zero, the statement
    > > is not executed. Simple.
    > >
    >
    > No. It does not say that at all.

    Okay, then what _does_ it say? I'd appreciate it if you explained to
    me why you think this is wrong, since the standard appears to me to be
    quite clear on the matter.

    > Even 'gcc' knows that the operation is incorrect, but you have to
    > turn on -Wall.
    >
    > xxx.c: In function `main':
    > xxx.c:13: warning: suggest parentheses around assignment used as truth value

    Are the words "warning" and "suggest" somehow unclear? Note that
    nowhere in that message does the word "error" appear. Adding the extra
    set of parentheses is a style choice that many people use to indicate
    that they really meant to use an assignment and not a boolean
    '=='. It's much like adding a comment to switch statements when you
    use fallthrough; it's a convenience to people who read your code, not
    a language requirement.


    --nat

    --
    nat lanza --------------------- research programmer, parallel data lab, cmu scs
    magus@cs.cmu.edu -------------------------------- http://www.cs.cmu.edu/~magus/
    there are no whole truths; all truths are half-truths -- alfred north whitehead

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:51    [W:0.024 / U:0.056 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site