[OT] lcc first experience

Discussion in 'C Programming' started by Morris Dovey, May 6, 2008.

  1. It is one of the things that never made the jump from BCPL to C. BCPL
    had:

    #b_1010_1110
    #o177
    1_234_567

    (B had only decimal and octal, as far as I can tell.)

    I miss the opportunity for clarity.
     
    Ben Bacarisse, May 8, 2008
    #21
    1. Advertisements

  2. Morris Dovey

    Paul Hsieh Guest

    Noooo ... really?!?!?
    C is an uncommon language in that it does not require a comparison
    operator in its if statements, and that all statements have side-
    effects. I specifically put a comparison operator in there to keep
    all my if() statements visually consistent, and to as clearly as
    possible show that *two* operations are happening in that one
    expression (a comparison/control flow, and an assignment.) The
    shorthand of smashing all that stuff together buys you only horizontal
    screen space, which is worthless.
    Which is an incomplete reason for doing something. There are many
    ways to suppress this warning. The question is how do you vacate the
    real complaint that it is trying to warn you about. The real warning
    is that its visually difficult to spot the difference between = and
    ==. Adding the extra parenthesis doesn't literally fix this; instead
    it just gives you a new pattern to try to associate with this "two
    operations in one expression" paradigm. Which is just stupid.

    My method may look a little messy, but its easy to get used to and is
    extremely clear.
     
    Paul Hsieh, May 8, 2008
    #22
    1. Advertisements

  3. ANSI X3.159-1989 (aka C89)
    Appendix A Language Syntax Summary

    A.2.3 Statements

    (3.6) statement:
    labeled-statement
    compound-statement
    expression-statement
    selection-statement
    iteration-statement
    jump-statement

    (3.6.1) labeled-statement:
    identifier : statement
    case constant-expression : statement
    default : statement

    In the first of those choices of 3.6.1, the identifier is a label.
    Does a label have a side-effect? If not, then whether the first form
    of labeled statement has a side effect depends upon whether the
    statement on the right hand side -always- has a side effect, a point
    which remains to be proved at this point in the analysis.

    In the second of those choices of 3.6.1, does a constant-expression
    have a side effect? If not, then whether the second form of labeled
    statement has a side effect depends upon whether the statement
    on the right hand side -always- has a side effect, a point which
    remains to be proved at this point in the analysis.

    In the third of these choices of 3.6.1, does the presence of 'default'
    have a side effect? If not then etc..

    (3.6.2) compound-statement:
    {declaration-list$opt$ statement-list$opt$}

    Please excuse my typographic mangling of the subscript 'opt' to $opt$.

    Does the -absence- of a declaration-list always have a side-effect
    in a compound-statement? If not then determining whether compound-statements
    always have side-effects, reduces down to determining whether
    {statement-list$opt$} always has a side-effect. In such a statement,
    does the -absence- of the statement-list always have a side-effect?
    That is, is there a side-effect associated with the compound-statement
    {}
    ?? If not then we have identified a compound-statement with no side-
    effect, and have thus identified a statement with no side-effect,
    which in turn would allow us to substitute in {} for the 'statement'
    portion in all three choices of labeled-statement, so unless there
    is a side-effect associated with the presence of a label or
    constant-expression or 'default' label, labeled-statements need not
    have any side-effects.

    Similarily, expression-statement (3.6.3) is expression$opt$
    and by simply exercising our option to not put in an expression,
    we appear to have found another form of statement that has no side-effects.

    If we examine section 3.6.3 of C89 properr, we find that it is entitled

    3.6.3 Expression and Null Statements
    and contains a paragraph:

    A null statement (consisting of just a semicolon) performs no operations.

    Personally, I find it difficult to see how there could be a "side-effect"
    associated with a statement that the C89 standard *specifically*
    says "performs no operations", but perhaps I'm just funny that way.


    We can continue this analysis through selection-statement and
    interation-statement and find several forms of each of those which have
    no side-effects.


    This brings us to (3.6.6) jump-statement
    goto identifier ;
    continue ;
    break ;
    return expression$opt$ ;

    At this point there is room for disagreement over what constitutes a
    'side-effect'. If a 'continue;' appears as the terminal statement
    inside a loop, then has it had a side-effect or not, considering the
    action would be the same if it was not there. If a 'break' appears as
    the terminal statement of a loop which does not have post-statements
    with side-effects (e.g., the third part of the for() is empty or has no
    side effects) and which would not have executed any more interations
    anyhow, then is it a side-effect? If a goto statement branches to the
    next line, has it had a side-effect? If a return statement with no
    expression appears as the last line of a void function, then
    does that return have a side-effect?

    I would be prepared to accept for the purposes of discussion
    a definition that indicated that a jump-statement always has a
    side-effect. But jump-statement is only one of the seven forms
    of C89 statements and the other six all have valid (and sometimes useful)
    forms that have no side-effects.

    I must therefore disagree with the claim that,
    as there are numerous C statements possible that have no side-
    effects.
     
    Walter Roberson, May 8, 2008
    #23
  4. Morris Dovey

    jacob navia Guest

    Walter Roberson wrote:
    [snip]
    Yes, and like all regulars you play with words. Try to write a program
    consisting of only

    jumps
    labels
    empty lists
    constants

    You know perfectly well what the intent of the sentence was, and
    you just want to show how clever you are.

    GRANTED!

    You are VERY CLEVER. I am astonished at your IQ.

    Now, let's try not to be silly OK?
     
    jacob navia, May 8, 2008
    #24
  5. I have no idea what you think the intent of the sentence
    was. Personally I took it literally.
     
    Spiros Bousbouras, May 8, 2008
    #25
  6. No, I do *not* understand the intent of that portion of the sentance
    at all.

    One of the semi-regular posters here takes pains to make a
    distinction, of great importance to him, between 'functions' and
    'procedures', saying (if I recall correctly) that 'functions'
    return values but have no side effects, and procedures have side
    effects but return no values. Personally I consider that an
    incorrect and harmful distinction to make in C (since it leaves
    out the possibility of having side effects -and- returning a value,
    which is very common in programming, if only to signal the
    success or failure of the attempted side effects). But it is
    important to that poster.

    When Paul Heish wrote that in C "all statements have side-effects",
    then I demonstrated, with reference to the C89 standard, that
    the claim is untrue, at least as far as C89 defines "statements".
    Paul might be defining "statements" differently; if so then he
    must now indicate what he was referring to. Paul has a recognized
    expertise in some aspects of C, and it would be unfortunate if some
    people therefore took his claim at face value without whatever
    context Paul might supply that would make claim correct in a certain
    light.

    Null statements and other statements without side effects are not
    rare in C. Consider for example,

    bignum_list factor_big_number(bignum_t num_to_factor) {
    /* to be implemented later */
    }

    This form of function is not some kind of special exception: the
    grammar uses compound-statement at that part in function-definition and
    the function body of this factor_big_number is an example of a
    compound-statement in which the optional declaration and optional
    statement list have both been omitted.


    Okay, here's one:

    int main(void) { return 0; }

    That's the unix program 'true'. Add the appropriate include
    and return EX_FAILURE and you have the unix program 'false'.

    That 'return' is a jump-statement I documented in my previous
    posting in this thread.


    But in any case, my success in this challenge is irrelevant.

    Paul Heish said that "all" statements in C had side effects.
    I pointed out not just one but several statement forms in C
    that do not have side effects. Therefore his use of "all" was
    either wrong or implied an unusual meaning of "statement".
    If he had said "nearly all" or "most" then there would have been
    little to talk about, other than perhaps why he bothered to point out
    a tautology.


    Suppose I had made the following claim:

    "All of Jacob's lcc-win versions have stupid fatal errors."

    Would the difference between "all" and "some" not then be of importance
    to you? I'm sure you could easily take into stride if I had said,

    "I think lcc-win is an overall well-done product, but some
    of Jacob's lcc-win versions have stupid fatal errors."

    Because if -none- of your versions -ever- have stupid fatal errors, you
    are doing better than 99.99999% of the population -- it happens to
    all of us from time to time, and we learn from it and go on.
    But if I had said something like that, then wouldn't it have been
    a *very* different meaning if I had used "all" instead of "some"?

    In short, "all" vs "some" *is* an important distinction, not just
    a matter of "being clever".
     
    Walter Roberson, May 8, 2008
    #26
  7. Yes, let's try just a little bit harder not to be silly.

    The quoted statement:

    ... all statements have side-effects ...

    was not, as far as I could tell, a metaphor, a figure of speech, a
    deliberate exaggeration for effect, or anything other than a simple
    literal statement that happened to be factually incorrect.

    Somehow you seem to have interpreted "all statements have
    side-effects" to mean something like "all, or nearly all, C programs
    contain statements with side-effects". That's a very different
    statement, one that the previous poster easily could have made if he
    had chosen to do so. Or perhaps you interpreted it in some other way;
    it's hard to tell.

    I found Walter's refutation unnecessarily long-winded. It would have
    been more than sufficient to present
    ;
    or
    x;
    (where x is a non-volatile object) as a counterexample.

    I haven't mentioned the name of the person who made the statement,
    since I have no desire to make a huge deal out of what was probably a
    simple mistake. (I'm making a somewhat bigger deal out of your
    reaction to it.) But I am somewhat curious about what the previous
    poster actually meant to say.

    This is not about "playing with words". It's about using words to
    communicate.
     
    Keith Thompson, May 8, 2008
    #27
  8. Morris Dovey

    muntyan Guest

    "Communicate" thing ends after first three lines of the "2+2=4"
    essay. The rest ten pages of stuff full of quotes from the C
    standard and anecdotes about I-wont-tell-name are what I call
    bullshit, and what Jacob calls "playing with words". I am making
    a somewhat big deal out of your selective seeing things (like
    anybody cares about who makes a big deal of what).

    Yevgen
     
    muntyan, May 8, 2008
    #28
  9. Are we reading the same postings?? The closest thing I can find
    to an anecdote in the message that Jacob was replying to was when
    I wrote,

    It isn't especially close to what one would normally consider an
    "anecdote", but it was nearly the only place in the message that
    was not direct quotation of or interpretation of the C89 standard.
    (The other place in the message was the place where I said that
    I would be prepared to accept for the purpose of discussion
    that jump-statements have side-effects; that's even less of an
    "anecdote", it seems to me, but if somehow my judgement is
    very faulty today about what an anecdote is or is not, then perhaps
    the latter is what you were referring to...)


    Quotes from the C standard were necessary in order to communicate
    with precision. A "statement" has a precise meaning in C, and
    in order to answer the question of whether "statements" have side-effects
    in C, we must deal with the details of what statements are.

    Could I have given a simple counter-example? Not exactly -- though
    I could have shown the derivation of just one counter-example and
    that would have served as a counter-proof. But that would have left
    open the possibility that I had happened to find a single loop-hole,
    found the "only" statement in C that did not have side effects. To
    my mind, that would have been enough to refute the original statement
    but would have been too close to "playing with words", so instead
    I showed that nearly all of the forms of C "statement" can
    unquestionably exist in forms with no side-effects. The one form
    in which it was questionable, I specifically noted as being a matter
    of semantics and open to reasonable discussion.
     
    Walter Roberson, May 8, 2008
    #29
  10. Morris Dovey

    Paul Hsieh Guest

    Oh for crying out loud. Yes, you got me! I made a boo-boo! I should
    have said that many statements, or the statements in question have
    side-effects. I mean you guys rag on Jacob all the time, but you just
    so perfectly illustrate his point with this inane over the top
    pedantry.

    I mean you don't give a crap at all about the point I was making or
    what one I was responding to, but you go over the top with some
    ridiculously lengthy response about some irrelevant detail when you
    just as easily could have pointed out that casting an expression to
    void removes its side effect (issue resolved in less than a
    sentence). I accept corrections, not sermons.
    Oh, for a second there I thought you were talking about me. I should
    probably go on a long rant about how to spell my name properly. And I
    still haven't found the word "sentance" in my dictionary, but I'm sure
    its there somewhere.
    It would probably be more correct to say that I am an expert
    *programmer*. I know C well enough to know what it *MUST* do, as
    opposed to what the standard says that it *does* do. If you think
    about it, that explains why I get into a lot of arguments with the C
    standard = Bible people here.
    Sure, and its worth a correction. So did you have any comments about
    source code clarity, useful strategies for warning removal,
    intentional operation explicitness, or the value of horizontal code
    size? How about just the lcc-win32 compiler?
     
    Paul Hsieh, May 8, 2008
    #30
  11. I don't think that's the "real warning" at all. It's not that it's
    difficult to visually distinguish, it's that you might well have made
    a typing error, because it's so much less common that the == case.
    The main idea is to catch mistakes, not make your program easier to
    read.

    And it works. Many of the times when I've had this warning, I have
    in fact made a mistake.
    It makes it very implausible that you have made a typing error.

    -- Richard
     
    Richard Tobin, May 8, 2008
    #31
  12. Really? Which ones do?

    -- Richard
     
    Richard Tobin, May 8, 2008
    #32
  13. Morris Dovey

    vippstar Guest

    All of which are off-topic for this group, with exception the
    correction you received on a C remark you made.
     
    vippstar, May 8, 2008
    #33
  14. Morris Dovey

    muntyan Guest

    "One of the semi-regular posters here takes pains to make a
    distinction, of great importance to him..."

    [snip]
    Sure. If one says that unsigned int object may have a value of -1,
    you need to quote the standard, and write a huge essay about why
    that's wrong. Or perhaps one can just say that it was wrong?

    [snip why and how]

    Yevgen
     
    muntyan, May 8, 2008
    #34
  15. Paul's statement is incorrect as written, but there's a correct and
    somewhat interesting statement hiding behind it.

    C is somewhat unusual in the breadth of types that are acceptable as
    conditions in if statements (and while statements, and other contexts
    that require conditions). In particular, an expression of any scalar
    type (i.e., any arithmetic or pointer type) can be used as a
    condition; the result of the expression is implicitly compared to zero
    (the meaning of "zero" varies for different scalar types), so that
    zero is treated as false, and any non-zero value is treated as true.

    For example, in C, this is valid:

    int x = 42;
    ...
    if (x) { /* equivalent to "if (x != 0)" */
    /* ... */
    }

    By contrast, Pascal requires a condition to be of type boolean (pardon
    any syntax errors; it's been a while).

    var
    x: integer;
    ...
    x := 42;
    if x <> 0 then (* would be illegal without the "<> 0" *)
    (* ... *)

    So, in many cases, a comparison operator that would be required in
    some other languages is not required in C.

    This feature, as far as I've seen, is peculiar to C, to languages that
    inherited it from C (C++, Perl, etc.), and perhaps to languages that
    got it from C's ancestors (are there any existing B/BCPL derivatives
    other than C?). Other common languages, particularly Pascal and its
    derivatives, don't do this.

    (Speaking only for myself, this is not among the features of C that I
    particularly like.)
     
    Keith Thompson, May 8, 2008
    #35
  16. I believe also an assignment counts as a side effect so
    (void) (a=b) is another counterexample to Paul Hsieh's
    claim.
     
    Spiros Bousbouras, May 9, 2008
    #36
  17.  
    Spiros Bousbouras, May 9, 2008
    #37
  18. Traditional Lisps are rather like C in this regard. They have a value
    that is commonly used as a terminator or null value that is the same
    as the value interpreted as false. In C, strings are terminated with
    0 and null pointers are treated as false. In traditional Lisps, nil
    and the empty list are the same, and are false.

    It's more or less inevitable that a language without an explicit boolean
    (or "logical") type will work like this, and even some with a boolean
    type have an implicit conversion from numeric zeros, empty sets, and
    so on.

    -- Richard
     
    Richard Tobin, May 9, 2008
    #38
  19.  
    Walter Roberson, May 9, 2008
    #39
  20. Morris Dovey

    muntyan Guest

    Oh, I am so sorry for getting that wrong. Must have confused
    two posts. You can't blame for that though, just look at
    the their size!
    I believe he clearly demonstrated that he didn't even notice
    his mistake - he didn't mean side effect, he meant "value"
    or something like that. I might be wrong here, he might be
    actually using "side effect" in some funny sense. If you care,
    you could ask him. But we don't care, right? We have the standard
    to quote, who cares what he meant!
    So you could state the obvious: he was obviously wrong. You
    chose to demonstrate your writing skills instead (one would
    think that even stating that is silly, since it's obvious,
    but we have innocent newbies who need to be defended, so
    "correcting a mistake" was of course needed).
    Blah blah blah. You took one single thing, you ignored the
    actual point (about if(0 != (foo = blah))). You didn't try
    to *understand*. No idea what you were thinking, but it was
    that - BS.

    Yevgen
     
    muntyan, May 9, 2008
    #40
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.