[OT] lcc first experience

[Ben Bacarisse]

as it turns out, binary constants like this are actually quite
error-prone. I discovered it was better to go back to hexadecimal
constants in quite a few cases. The binary constants were mainly
useful in short binary numbers (where hex-vs-binary became pretty
much a matter of taste).

If C were to steal another feature from Ada, we could fix this,
*and* the equivalent problem with other large constants (in any
base), by adding "_" as an ignored digit separator. Then we could
write:

0b1101_0110_0010_1101_1000_0101_1110_0000_0001_1110_1111_0001_0011

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.

 

[Paul Hsieh]

FYI any non-zero integral value is taken as TRUE, while zero is
taken as FALSE, by all C logical expressions.

Noooo ... really?!?!?

[...] So you don't need
the confusing extra garbage in the statement.

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.

[...] The purpose of the
extra parentheses is only to suppress the gcc warning.

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.

 

[Walter Roberson]

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.

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,

all statements have side-
effects.

as there are numerous C statements possible that have no side-
effects.

 

[jacob navia]

Walter Roberson wrote:
[snip]

I must therefore disagree with the claim that,


as there are numerous C statements possible that have no side-
effects.

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?

 

[Spiros Bousbouras]

Walter Roberson wrote:

[snip]

I must therefore disagree with the claim that,

as there are numerous C statements possible that have no side-
effects.

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.

I have no idea what you think the intent of the sentence
was. Personally I took it literally.

 

[Walter Roberson]

Walter Roberson wrote:
[snip]

I must therefore disagree with the claim that,

You know perfectly well what the intent of the sentence was,

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.

and
you just want to show how clever you are.

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.

Try to write a program
consisting of only

jumps
labels
empty lists
constants

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

 

[Keith Thompson]

Walter Roberson wrote:
[snip]

I must therefore disagree with the claim that,


as there are numerous C statements possible that have no side-
effects.

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?

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.

 

[muntyan]

Walter Roberson wrote:
[snip]

I must therefore disagree with the claim that,
all statements have side-
effects.
as there are numerous C statements possible that have no side-
effects.

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.

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

Now, let's try not to be silly OK?

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.

"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

 

[Walter Roberson]

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

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.

 

[Paul Hsieh]

Walter Roberson wrote:
[snip]

I must therefore disagree with the claim that,
all statements have side-
effects.

You know perfectly well what the intent of the sentence was,

No, I do *not* understand the intent of that portion of the sentance
at all. [...]

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.

[...] When Paul Heish [...]

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.

[...] Paul has a recognized expertise in some aspects of C, [...]

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.

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.

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?

 

[Richard Tobin]

The real warning is that its visually difficult to spot the
difference between = and ==.

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.

Adding the extra parenthesis doesn't literally fix this;

It makes it very implausible that you have made a typing error.

-- Richard

 

[Richard Tobin]

C is an uncommon language in that it does not require a comparison
operator in its if statements

Really? Which ones do?

-- Richard

 

[vippstar]

[...] Paul has a recognized expertise in some aspects of C, [...]

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.

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.

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?

All of which are off-topic for this group, with exception the
correction you received on a C remark you made.

 

[muntyan]

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,

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

[snip]

Quotes from the C standard were necessary in order to communicate
with precision.

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

 

[Keith Thompson]

Really? Which ones do?

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

 

[Spiros Bousbouras]

[...]
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.
[...]

(void) printf("No side-effects here, nossir!\n");

I believe also an assignment counts as a side effect so
(void) (a=b) is another counterexample to Paul Hsieh's
claim.

 

[Spiros Bousbouras]

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.

Common Lisp also works this way albeit there the comparison is with
the empty list rather than zero:

(if x (print "True") (print "False"))

will print True if x is not the empty list and False if it is the
empty list.

 

[Richard Tobin]

Common Lisp also works this way albeit there the comparison is with
the empty list rather than zero:

(if x (print "True") (print "False"))

will print True if x is not the empty list and False if it is the
empty list.

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

 

[Walter Roberson]

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

Check the ordering on the messages. My note about person who
distinguishes between functions and procedures was in reply to Jacob's
reply to my message. So what Jacob was replying to contained no
anecdotes.

"I-wont-tell-name" ?? I never took particular note of the name of
that particular person. There are a number of people I remember clearly
enough to be fairly sure it was -not- them, but I don't cross-reference
everyone's peculiarities (and I doubt anyone considers me important
enough to bother to cross-reference -my- pecularities.)

The paragraph about the poster who makes the distinction noted, was
in illustration of the fact that there are posters here who employ
(and expect others to understand and employ) words in senses
other than the senses of those words that are defined by the C standard.
The paragraph was written to show how it was indeed reasonable
for me -not- to know what Paul meant. Even now, after Paul has
indicated that he "made a boo-boo", I find that I have no idea
what notion he was trying to convey in that particular phrase.

It wasn't a case of "I'm going to pretend I don't understand because
that's not what the standard says": it was a case of "I can't think
of -any- reasonable interpretation of that phrase that could be
considered correct." -You- might have thought that I was
"playing with words" or "bull-shitting", but I know that -I- was
thinking of neither of those things at the time I was writing those
postings.

 

[muntyan]

Check the ordering on the messages. My note about person who
distinguishes between functions and procedures was in reply to Jacob's
reply to my message. So what Jacob was replying to contained no
anecdotes.

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-wont-tell-name" ?? I never took particular note of the name of
that particular person. There are a number of people I remember clearly
enough to be fairly sure it was -not- them, but I don't cross-reference
everyone's peculiarities (and I doubt anyone considers me important
enough to bother to cross-reference -my- pecularities.)

The paragraph about the poster who makes the distinction noted, was
in illustration of the fact that there are posters here who employ
(and expect others to understand and employ) words in senses
other than the senses of those words that are defined by the C standard.
The paragraph was written to show how it was indeed reasonable
for me -not- to know what Paul meant. Even now, after Paul has
indicated that he "made a boo-boo", I find that I have no idea
what notion he was trying to convey in that particular phrase.

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!

It wasn't a case of "I'm going to pretend I don't understand because
that's not what the standard says": it was a case of "I can't think
of -any- reasonable interpretation of that phrase that could be
considered correct."

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

-You- might have thought that I was
"playing with words" or "bull-shitting", but I know that -I- was
thinking of neither of those things at the time I was writing those
postings.

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