«

"BartC" <> writes:
> "Eric Sosman" <> wrote in message
> news:js03uf$sb3$...
> > On 6/21/2012 5:08 PM, BartC wrote:
>
> >> "Yogesh Yadav Pacheria" <> wrote in message
> >> news:8404c4f1-a3b7-46b7-ad9c-...
>
> >>> int i = 0;
> >>> i = ++i + ++i + ++i;
> >>> printf("%d",i);
>
> >>> Output should be 6
> >>>
> >>> But In GCC it's 7
>
> >> I agree it ought to be 6.
> >
> > Nitwit.
>
> Yet, given the OP's program, and a randomly assigned but unknown compiler,
> what result would you put your money on, if you were obliged to gamble?

I would not waste my time with such idiotic games. One easy way to
make that easier is to not waste time with idiotic people.

Phil
--
> I'd argue that there is much evidence for the existence of a God.
Pics or it didn't happen.
-- Tom (/. uid 822)

Tim Rentsch <> writes:
> Eric Sosman <> writes:
> > On 6/21/2012 5:08 PM, BartC wrote:
> >> "Yogesh Yadav Pacheria" <> wrote in message
> >> news:8404c4f1-a3b7-46b7-ad9c-...
> >>> I tried this Code
> >>>
> >>> int main()
> >>> {
> >>> int i = 0;
> >>> i = ++i + ++i + ++i;
> >>> printf("%d",i);
> >>> }
> >>>
> >>> Output should be 6
> >>>
> >>> But In GCC it's 7
> >>>
> >>> How and plz tell the order of evalution of pre and post bot
> >>
> >> I agree it ought to be 6.
> >
> > Nitwit.
>
> Did you not read the rest of his comments? He explained further
> on that C allows other possibilities, and this comment is only
> expressing an opinion.

His opinion is that C should be not-C.

Phil
--
> I'd argue that there is much evidence for the existence of a God.
Pics or it didn't happen.
-- Tom (/. uid 822)

Phil Carmody <> writes:

> Tim Rentsch <> writes:
>> Eric Sosman <> writes:
>> > On 6/21/2012 5:08 PM, BartC wrote:
>> >> "Yogesh Yadav Pacheria" <> wrote in message
>> >> news:8404c4f1-a3b7-46b7-ad9c-...
>> >>> I tried this Code
>> >>>
>> >>> int main()
>> >>> {
>> >>> int i = 0;
>> >>> i = ++i + ++i + ++i;
>> >>> printf("%d",i);
>> >>> }
>> >>>
>> >>> Output should be 6
>> >>>
>> >>> But In GCC it's 7
>> >>>
>> >>> How and plz tell the order of evalution of pre and post bot
>> >>
>> >> I agree it ought to be 6.
>> >
>> > Nitwit.
>>
>> Did you not read the rest of his comments? He explained further
>> on that C allows other possibilities, and this comment is only
>> expressing an opinion.
>
> His opinion is that C should be not-C.

Maybe, but not necessarily. It could just as easily be an opinion
about implementations rather than the C language itself. There is
nothing incompatible with the behavior suggested and what the C
language requires.

However, even if it is an opinion about the C language, so what?
There are plenty of things about C that I think exhibit varying
degrees of wrongheadedness in terms of language design. In fact
I don't know anyone who thinks everything about C is right and
nothing about it should be changed. Expressing an opinion about
C's perceived shortcomings doesn't per se make one a nitwit. As
it happens I personally disagree with this opinion about the C
language (assuming it is an opinion about the language and not
about implementations, which is a whole other story), but I don't
think it's so outrageous a viewpoint that anyone holding it must
be hopelessly addled.

On Friday, June 22, 2012 2:34:58 PM UTC+1, Ben Bacarisse wrote:
> "BartC" <> writes:

<snip>

> I've never liked the view that anything can happen with undefined code;
> it sounds too much like a cheap pedagogical trick to say that the above
> could format your drive.

a poster on here used to claim he'd seen a system pop up the old DOS dialog box saying "Are You Sure You Want To Reformat C". For some sort of UB (not tricks with ++ but (I think) some sort of out of bounds thing).

> But the other extreme -- we all know what
> *should* happen, don't we? -- is equally unconvincing. When the C
> language does not define the meaning of a bit of code, something else
> does, and that's enough for me. I don't want to write code whose
> meaning is in the hands of unknown entities. This point of view covers
> the much more significant case where I *know* what entity will define
> the meaning of otherwise undefined code -- POSIX, for example.

I've seen program behaviour change due to UB when a compiler was upgraded (same manufacturer). Changing optimisation can do it too.

<snip>

"Tim Rentsch" <> wrote in message
news:...
> Phil Carmody <> writes:

>> His opinion is that C should be not-C.
>
> Maybe, but not necessarily. It could just as easily be an opinion
> about implementations rather than the C language itself. There is
> nothing incompatible with the behavior suggested and what the C
> language requires.
>
> However, even if it is an opinion about the C language, so what?

> There are plenty of things about C that I think exhibit varying
> degrees of wrongheadedness in terms of language design. In fact
> I don't know anyone who thinks everything about C is right and
> nothing about it should be changed.

(I'm interested in language design and many of the threads I participated in
were on those subjects. They necessarily have to involve ideas from outside
C. Although this wasn't meant to be one of them; nothing was proposed.)

> Expressing an opinion about
> C's perceived shortcomings doesn't per se make one a nitwit. As
> it happens I personally disagree with this opinion about the C
> language (assuming it is an opinion about the language and not
> about implementations, which is a whole other story), but I don't
> think it's so outrageous a viewpoint that anyone holding it must
> be hopelessly addled.

(I discuss my comment some more in comp.programming, under the same subject
line. But the bottom line is that that throwaway remark wasn't about C at
all.)

"Eric Sosman" wrote in message news:js1rqu$li8$...

> I don't know whether BartC is actually evil

(It's nice to know some people in this group have more open minds than Mr
ES!)

--
BartC

writes:

> On Friday, June 22, 2012 2:34:58 PM UTC+1, Ben Bacarisse wrote:
>> "BartC" <> writes:
>
> <snip>
>
>> I've never liked the view that anything can happen with undefined code;
>> it sounds too much like a cheap pedagogical trick to say that the above
>> could format your drive.
>
> a poster on here used to claim he'd seen a system pop up the old DOS
> dialog box saying "Are You Sure You Want To Reformat C". For some
> sort of UB (not tricks with ++ but (I think) some sort of out of
> bounds thing).

Exactly. Even beginners soon realise that "anything can happen" is not
really true. The truth should be scary enough.

>> But the other extreme -- we all know what
>> *should* happen, don't we? -- is equally unconvincing. When the C
>> language does not define the meaning of a bit of code, something else
>> does, and that's enough for me. I don't want to write code whose
>> meaning is in the hands of unknown entities. This point of view covers
>> the much more significant case where I *know* what entity will define
>> the meaning of otherwise undefined code -- POSIX, for example.
>
> I've seen program behaviour change due to UB when a compiler was
> upgraded (same manufacturer). Changing optimisation can do it too.

Yup, or even just using different compiler options. You want to be the
one defining what your programs mean, not leaving up to other entities
(unless you need to like in my POSIX example).

--
Ben.

On 6/25/2012 3:27 AM, wrote:
>[...]
> I've seen program behaviour change due to UB when a compiler was upgraded (same manufacturer). Changing optimisation can do it too.

Even an "unrelated" change to the program can expose UB in
an unchanged section. See also "Heisenbug."

--
Eric Sosman
d

"BartC" <> writes:

> "Tim Rentsch" <> wrote in message
> news:...
>> Phil Carmody <> writes:
>
>>> His opinion is that C should be not-C.
>>
>> Maybe, but not necessarily. It could just as easily be an opinion
>> about implementations rather than the C language itself. There is
>> nothing incompatible with the behavior suggested and what the C
>> language requires.
>>
>> However, even if it is an opinion about the C language, so what?
>
>> There are plenty of things about C that I think exhibit varying
>> degrees of wrongheadedness in terms of language design. In fact
>> I don't know anyone who thinks everything about C is right and
>> nothing about it should be changed.
>
> (I'm interested in language design and many of the threads I participated in
> were on those subjects. They necessarily have to involve ideas from outside
> C. Although this wasn't meant to be one of them; nothing was proposed.)
>
>> Expressing an opinion about
>> C's perceived shortcomings doesn't per se make one a nitwit. As
>> it happens I personally disagree with this opinion about the C
>> language (assuming it is an opinion about the language and not
>> about implementations, which is a whole other story), but I don't
>> think it's so outrageous a viewpoint that anyone holding it must
>> be hopelessly addled.
>
> (I discuss my comment some more in comp.programming, under the same subject
> line. But the bottom line is that that throwaway remark wasn't about C at
> all.)

May I courteously suggest that it would have been better if that
had been made clear in your comment. Perhaps something along
the lines of "In a more sensibly designed language, this would ...".
That is better all around, I think, ie, both for the OP and for
other folks (I would count myself as one of these) who are more
entrenched in C as defined by the Standard.

> "Eric Sosman" wrote in message news:js1rqu$li8$...
>
>> I don't know whether BartC is actually evil
>
> (It's nice to know some people in this group have more open minds than
> Mr ES!)

In most cases I try to read postings based on what they say and
not on who is doing the saying. Also I am willing to listen to
other points of view, reasonably expressed, even if I don't
necessarily agree with them. Now if the reasoning backing up
a point of view is gibberish, then I am perfectly willing to
call it gibberish, but that's about the reasoning, not about
just having a different view. Some people don't make that
distinction.

"Eric Sosman" <> wrote in message
news:js1rqu$li8$...

> For someone whose understanding of C is shaky at best (see recent
> threads concerning unsigned arithmetic), BartC spouts off an awful lot
> of rash opinions.

I've just read through the thread again, or what's left of it on my server.
(I assume you mean the "condition true or false..." thread.)

You're right, I didn't know stuff about 'closed operations', 'finite groups'
and 'additive inverses', or whether a denotation such as 82537 is called a
constant or a literal. But you shouldn't need do.

For those who haven't read it, the OP there was wondering why C was saying
that '-1 < 5' (when expressed in a certain way) was False. My 'rash
opinion' was suggesting that that was wrong!

Of course no-one is allowed to have opinion on that, unless they're a
complete expert on the language and know the Standard inside out!
Explanations why things are as they are are all very well, but people,
including non-conformist outsiders like me, should be allowed to question
them.

> I read his drivel mostly because some of it needs
> contradicting lest it mislead readers:

Most of my points still stand. I think they were perfectly reasonable in the
context of a proposed 'fantasy' change to the language. I don't think anyone
was misled in that thread.

(I sometimes like to side with OPs. If their post brings up something
questionable in the language, then I find that interesting. If they expect
things to work a certain way, then perhaps that's the way they should work!

When I was designing user interfaces, then I used the same reasoning. It was
just easier than complicated explanations and a thicker user manual.

Although C itself is a closed book here, I'm designing two languages of my
own. I have to decide, from time to time, whether to adopt an existing
practice, eg. from C, or find another way. In the case of C's mixed
arithmetic handling, I once asked for a 'rationale' for it, and that thread
gave me most of it. (A belated thanks...). However I decided to do my own
thing there**.)

(** On one language, unsigned types are partly eliminated, which is one way
to deal with the problem. On the other more C-like language, mixed
arithmetic was going to use signed, as presenting fewer surprises. But I
think I will insist on explicit casting instead; then any surprises won't be
as unexpected.

In the case of i=0; i=++i+ ++i+ ++i, I don't guarantee the result of that
either. But that has nothing to do with the common-sense expectation of what
such an expression might do. Ie. end up with i==6! Sadly everyone missed the
point. I know I'm risking a third 'nitwit' remark from Eric, or something
equally belittling, but I'm no longer bothered.)

--
Bartc

"Bartc" <> writes:

> "Eric Sosman" <> wrote in message
> news:js1rqu$li8$...
>
>> For someone whose understanding of C is shaky at best (see recent
>> threads concerning unsigned arithmetic), BartC spouts off an awful lot
>> of rash opinions.
>
> I've just read through the thread again, or what's left of it on my server.
> (I assume you mean the "condition true or false..." thread.)
>
> You're right, I didn't know stuff about 'closed operations', 'finite groups'
> and 'additive inverses', or whether a denotation such as 82537 is called a
> constant or a literal. But you shouldn't need do.

No you shouldn't, and of course you don't, but suggesting that you do
is a good way to stir up this month-old controversy again.

What you need to know, though, is the language's rules and it's that
rather mundane fact that you lament. You don't like the fact that C is
not obvious, that some results are unexpected, that you have to know
quite a lot of details to avoid surprises.

> For those who haven't read it, the OP there was wondering why C was saying
> that '-1 < 5' (when expressed in a certain way) was False. My 'rash
> opinion' was suggesting that that was wrong!

For those who haven't read it, Bartc is characterising the question so
as to make it look absurd. -1 < 5 is always 1 in C, and no relational
expression is ever "False" (I'm not sure what the significance of the
capital F is but it looks significant).

Here, again, C shows its readiness to confound those who don't know the
rules. C's relational operators produce an int result (either 0 or 1)
and never produce a Boolean result, despite the fact that C has a Boolean
type called _Bool (yes, they didn't make even the type name obvious).

I am not sure, but I suspect that Eric's remark about "rash opinions" is
more likely to be about your suggestions for how C's mixed type
arithmetic should be done. I think it *is* rash to suggest how a
programming language should behave unless you know it very well indeed.

> Of course no-one is allowed to have opinion on that, unless they're a
> complete expert on the language and know the Standard inside out!
> Explanations why things are as they are are all very well, but people,
> including non-conformist outsiders like me, should be allowed to question
> them.

Are you confusing being allowed with being agreed with? No one stopped
you from questioning things as they are as far as I can tell.

<snip>
> ... I'm designing two languages of my own.
<snip>
> In the case of i=0; i=++i+ ++i+ ++i, I don't guarantee the result of that
> either. But that has nothing to do with the common-sense expectation of what
> such an expression might do. Ie. end up with i==6! Sadly everyone missed the
> point.

No, I don't think everyone did miss your point.

Just in case, here's mine again: the notion of common sense is not
applicable to programming languages, as this very thread shows. For
people who don't program but who have common sense in abundance, the
only response to seeing

i=0; i=++i+ ++i+ ++i;

should be to ask what that notation means. People who know one or two
languages in which that sequence of tokens has a well-defined meaning
would be most rash to assume it has the same meaning in another
language. To make such an assumption is not common sense -- it's the
opposite of common sense. Such people (coming from a C# and Java
background for example) may well have a deceptive expectation, but their
common sense should save them from it.

Try it yourself. What does this do:

f = (+1);

and is any language which does not match what your expectation flawed as
a result?

<snip>
--
Ben.