«

Chris Torek <> writes:
<snip>
> 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_111 0_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.

--
Ben.

On May 7, 2:48 pm, CBFalconer <cbfalco...@yahoo.com> wrote:
> Paul Hsieh wrote:
> > Tomás Ó hÉilidhe <t...@lavabit.com> wrote:
> ... snip ...
> >> I've actually taken its advice and started doing:
> >> if ((i=5)) DoWhatever();
>
> > Whenever I do that I usually write it as:
> > if (0 != (i = 5)) DoWhatever();
> > to make it absolutely crystal clear what I mean.
>
> 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.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

In article <cf0c2e4c-e25f-4ceb-a45d->,
Paul Hsieh <> wrote:

>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.
--
"I was very young in those days, but I was also rather dim."
-- Christopher Priest

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.

GRANTED!

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

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



--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

On 8 May, 18:42, jacob navia <ja...@nospam.com> wrote:
> 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.

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

In article <fvve2b$i0q$>, jacob navia <> wrote:
>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.

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".
--
"MAMA: Oh--So now it's life. Money is life. Once upon a time freedom
used to be life--now it's money. I guess the world really do change.
WALTER: No--it was always money, Mama. We just didn't know about it."
-- Lorraine Hansberry

jacob navia <> writes:
> 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.
>
> 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.

--
Keith Thompson (The_Other_Keith) <kst->
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

On May 8, 1:55 pm, Keith Thompson <ks...@mib.org> wrote:
> jacob navia <ja...@nospam.com> writes:
> > 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.
>
> > 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.

"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

In article <c3cb0c48-bc72-4b53-af6b->,
<> wrote:

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

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

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.
--
"The whole history of civilization is strewn with creeds and
institutions which were invaluable at first, and deadly
afterwards." -- Walter Bagehot

On May 8, 11:28 am, rober...@ibd.nrc-cnrc.gc.ca (Walter Roberson)
wrote:
> In article <fvve2b$i0...@aioe.org>, jacob navia <ja...@nospam.org> wrote:
> >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?

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/