A C showstopper

[spinoza1111]

spinoza1111wrote:

Don't be silly. It was an attempt -- a broadly successful attempt -- to
formalise C in a way that allowed existing widely-used implementations
to conform with only a reasonable amount of work.

....as opposed to fixing them...

Maybe so. But each bit of additional definedness requires work from
most of the implementors, and work in committee to make the choice.
None of the participants had unbounded resouces. "Undefined" means,
amonst other things, "not enough return on investment".

At some point one has to leave this model of ROI and tradeoffs, since
it assumes a functioning system.

No, it doesn't. Why on Earth do you think so?


This is all your own invention.

No, it's what happened. Enlightenment became folklore.

(fx:snip)


The /comma operator/ had that meaning before that standard, as I recall.
The /comma separator/ -- which is what appears in argument lists -- didn't.

That was a very stupid decision indeed.

 

[spinoza1111]

In C# (and Java) all the arguments are be executed sequentially
left-to-right, but in C they can be executed in any order, and not even
necessarily sequentially.

It's not any different than the order of operations in most expressions.
In C:

   f() + g() + h()

evaluates the arguments in any order, unlike C# which goes
left-to-right.

That's nuts. What it means is that different compilers give different
answers, and that means all but one answer is wrong: it also means
that we no longer know (post C99) the right answer.

This is progress?

To implement the new standard, one would have to do random number
generation.

The real intent of this nonsense was to make as many existing
compilers work without change so that important stakeholders continued
to make money. The public (the programmer: the end user) be damned.

You know as well as I that prior to C99, most compilers went left to
right. It was a defacto standard, and the C99 group should have
certified this. Instead, they chose to please fat cat corporations.

# The order of evaluation of the function designator, the actual
# arguments, and subexpressions within the actual arguments is
# unspecified, but there is a sequence point before the actual call.

# J.1 Unspecified behavior
#
# The following are unspecified:

# The order in which subexpressions are evaluated and the order in which
# side effects take place, except as specified for the function-call (),
# &&, ||, ?:, and comma operators (6.5).

Personally, I like this sort of evaluation.  And certainly C isn't the
only popular language to do it this way.

"Unspecified" is NOT an evaluation.

It would have been better had Microsoft taken over the C language and
effectively standardized it by being the biggest kid on the block, as
it has done with Basic: the best thing that ever happened to Basic, a
Basically crummy language, was Visual Basic, Microsoft's property.
Microsoft should have done the same for C. Rather have one big bad
greedy corporation than a lot of small greedy corporations, since it's
easier to change the big corporation from within and without.

 

[spinoza1111]

spinoza1111wrote:

That is a huge insult to a bunch of people who give up about a month a year unpaid to work together to document standard
practices for the benefit of all who use C.

I don't think you were unpaid. Even if you were, you were working on
behalf of the fiduciary interest of compiler vendors and not for the
general public, and as such you probably used public monies for
private ends. The behavior of members of your committees towards
Herbert Schildt only persuades me that you need to be "insulted".

Talk about the politics of personal destruction, this is it.

You messed with something created by members of the general public and
your standards effort failed, resulting in the confusion you see here
and campaigns of personal destruction such as that against Schildt.
You were unequal to the task, since you failed to DEFINE a commonly
acceptable C and transformed the most obvious answers (such as left to
right evaluation) into Eleusinian mysteries in order to preserve Holy
Corporate Profits, well in the spirit of a society which can't provide
health insurance but spends trillions rescuing banks and killing
Afghani and Palestinian children.

Your job was to DEFINE a common C and write a free reference compiler
for it, running interpretively with complete compile time and run time
diagnostics, so as to have a free way of evaluating other compilers,
and changing the code of broken compilers. But your spiritual fathers
laughed at the Algol people when they did this, and criticised them
for being late as if they were schoolchildren. Afraid of this
criticism, you made any hard question undefined.

The politics of personal destruction is when a PERSON such as Herb
Schildt has to endure, for years, an insulting Wikipedia entry for
doing an honest job for McGraw Hill. It's when a PERSON such as Jacob
Navia is called a "drama queen" for being MAN enough to defend himself
to people who are used to the corporate game of kicking people in the
guts and normalizing deviance. It's when a PERSON such as myself is
attacked for being "off topic" when he breaks the rule of *omerta*
about culture and oppression that is prevelant among programmers.

It is NOT criticising cowards who falsely don eleemosynary robes when
they give their "donated" time so as to get fatcat jobs with
corporations whose investment they've protected. You are no more
eleemosynary than wikipedia since you could have spent that money
teaching C to prisoners or working in a soup kitchen. Don't you DARE
claim other than naked self-interest and self-promotion, Walter,
because I've seen on comp.programming how you people behave.

 

[spinoza1111]

Walter, here's a guy whose expertise is on C99 yet he calls it "rather
unsuccessful". Even Richard Heathfield has a guilty conscience about
the ethics of making things "undefined" that were in fact perfectly
definable!

<snip>

...and then go on to explain why it's right.

Okay, okay - I suspect we're just looking at this from rather
different perspectives. It happens. (And, given that you are far
closer to the process than I am, your perspective carries far more
weight than mine.)

He's too close. He's what CS Lewis calls a member of the Inner Ring.

 

[Chris Dollin]

...as opposed to fixing them...

"Fixing" implies a standard to fix against. What standard did you
have in mind? (Your own personal prejudices aren't relevant here,
just as mine aren't. Also irrelevant is the twenty-odd years of
hindsight that the committee and implementors of the time didn't
have.)

At some point one has to leave this model of ROI and tradeoffs, since
it assumes a functioning system.

No, it doesn't.

That was a very stupid decision indeed.

You choose to think so; given the reasons why that decision was
made (freedom to generate efficient code), and the constraints of
the time (small, slow computers), and the C user community
(experienced programmers willing to learn the language, razors
and all) I don't agree.

 

[spinoza1111]

spinoza1111wrote:

"Fixing" implies a standard to fix against. What standard did you
have in mind? (Your own personal prejudices aren't relevant here,
just as mine aren't. Also irrelevant is the twenty-odd years of
hindsight that the committee and implementors of the time didn't
have.)

It's just common sense that unless there's an overriding reason NOT to
do so, you do postincrement before you say you're done evaluating an
expression. You treat commas in function lists orthogonally wrt commas
in expressions outside of function calls.

No, it doesn't.

Yes, it does. When you are developing or fixing a language you need
freedom from capitalist considerations. Otherwise the language is
distorted by self-interest. Read Confucius on "the rectification of
names".

You choose to think so; given the reasons why that decision was
made (freedom to generate efficient code), and the constraints of
the time (small, slow computers), and the C user community
(experienced programmers willing to learn the language, razors
and all) I don't agree.

You mean efficient? Or broken? The intent of the comma in expressions
outside function calls was clear. It wasn't a pipe or coroutine
operator. Some idiots made it so in some stupid compiler, and their
employer didn't want to have pay some more idiots to fix things.

 

[Chris Dollin]

That's nuts.

It's not "nuts", measured against the tradeoffs the language is
handling.

What it means is that different compilers give different
answers,

Yes. (Strictly, /may/ give; it's allowed for all compilers to
make the same choice.)

and that means all but one answer is wrong:

No, it means that all the answers are /right/.

it also means that we no longer know (post C99) the right answer.

The post-C99 answer is the same as the pre-C99 answer; "it all
depends".

This is progress?

Yes. Beforehand, one didn't know that one didn't know what the
order of evaluation was, and might think that the accidental
choices of one's local compiler were definitive. Afterwards,
one knew (if one read the standard or a derived work) that
those choices were not definitive.

To implement the new standard, one would have to do random number
generation.

Don't be silly. That the language doesn't mean that the order
of evaluation isn't specified doesn't mean the compiler must
evaluate in a dynamically random order; it means the compiler
can pick an order that satisfies its other goals.

The real intent of this nonsense was to make as many existing
compilers work without change so that important stakeholders continued
to make money. The public (the programmer: the end user) be damned.

Those are three different communities. Only the middle one is
of particular significance in this discussion. That community was
involved in the discussions.

You know as well as I that prior to C99, most compilers went left to
right.

Or right-to-left, a natural choice for implementations that used
a single straightforward function-call mechanism and a push-down
stack.

It was a defacto standard,

It was not.

and the C99 group should have certified this. Instead, they chose
to please fat cat corporations.

Your evidence for this being ...

"Unspecified" is NOT an evaluation.

Neither is it an order of evaluation. It is, however, a specification
of choice of order of evaluation, and it says: it doesn't matter,
pick one that's good for you.

You don't like that choice. (As it happens, neither do I.) That
doesn't mean it isn't a choice, and it doesn't mean that there aren't
good reasons for that choice.

Rather have one big bad greedy corporation than a lot of small
greedy corporations, since it's easier to change the big corporation
from within and without.

My days dose of hysterical laughter has been achieved!

--
"My name is Hannelore Ellicott-Chatham. I *end messes*." Hannelore,
/Questionable Content/

Hewlett-Packard Limited registered no:
registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England

 

[Chris Dollin]

It's just common sense that unless there's an overriding reason NOT to
do so, you do postincrement before you say you're done evaluating an
expression.

C /does/ "do" postincrement before it "says its done evaluating an
expression".

And the overriding reason is "generating efficient code".

You treat commas in function lists orthogonally wrt commas
in expressions outside of function calls.

Um, I'm confused. "Orthogonally" usually means "independently";
you seem to be saying one should treat operator-commas independantly
of parameter-commas. Which they are. Did you mis-write?

If you want the meanings to be the /same/, then you have serious
backward compatability problems. As you know, Bob, the meaning of
the expression `X, Y` is (and was) "evaluate X, discard any result,
evaluate Y, yeild that result". That won't do for argument lists.
Conversely, a plausible meaning for the argument comma in `A, B`
would be "evaluate A and remember the results A'; evaluate B and
remember the results B'; yeild the tuple A' concatenated with B'".

(The concatenations are to make 3-or-more argument lists work.)

Now /this/ doesn't work for the call `f( a, (x, y), b )`. Which
had an /existing meaning/ pre-Standard.

Yes, it does. When you are developing or fixing a language you need
freedom from capitalist considerations.

(a) No, you don't.

(b) ROI isn't just a "capitalist consideration".

Otherwise the language is distorted by self-interest.

We can't help but let our own interests affect what we do. That's
why we exploit diversity and community.

You mean efficient? Or broken? The intent of the comma in expressions
outside function calls was clear.

And inside arguement lists too.

It wasn't a pipe or coroutine operator.

That's true. Neither was it lazy evaluation or polymorphism.

Some idiots made it so in some stupid compiler,

They made the /comma operator/ a pipe or coroutine? I don't think
so. They made /argument lists/ a pipe or coroutine? I don't think
so. They chose an evaluation order that made their code (reasonably)
efficient and their compiler (reasonably) uncomplicated? Yeah,
sounds plausible. And sensible.

and their
employer didn't want to have pay some more idiots to fix things.

It's a hypothesis. So's "Magneto had threatened their children"
or "the CIA put LSD in their water supply."

"There wasn't anything that anyone thought need fixing" seems
more likely, although I'll admit that it's more boring.

 

[Walter Banks]

That's nuts. What it means is that different compilers give different
answers, and that means all but one answer is wrong: it also means
that we no longer know (post C99) the right answer.

This is progress?

To implement the new standard, one would have to do random number
generation.

The real intent of this nonsense was to make as many existing
compilers work without change so that important stakeholders continued
to make money. The public (the programmer: the end user) be damned.

You know as well as I that prior to C99, most compilers went left to
right. It was a defacto standard, and the C99 group should have
certified this. Instead, they chose to please fat cat corporations.

ISO standards codify existing practice backed with supporting documentation. Using the SC22 standards documents to argue specification disagreements is at best a display of ignorance and at worst a dishonest representation of standards documents.

Regards,

 

[Nobody]

That's nuts. What it means is that different compilers give different
answers, and that means all but one answer is wrong: it also means
that we no longer know (post C99) the right answer.

This is progress?

This has nothing to do with C99. Both C89 and C99 explicitly state that
the order of evaluation is undefined. "Typical" behaviour since the K&R
days is for arguments to be evaluated right-to-left (mostly because this
makes it easier to implement variadic functions).

The real intent of this nonsense was to make as many existing
compilers work without change so that important stakeholders continued
to make money. The public (the programmer: the end user) be damned.

You know as well as I that prior to C99, most compilers went left to
right. It was a defacto standard, and the C99 group should have
certified this. Instead, they chose to please fat cat corporations.

This is why no-one takes you seriously. Not only do you make huge leaps of
"logic", but the very premises on which your arguments are based are
factually incorrect.

I know that most compilers have always evaluated right-to-left. In the
days of K&R, before ANSI introduced function protoypes, this was almost
essential for variadic functions to work (remember: in the absence of a
prototype, the caller doesn't *know* that a function is variadic).

 

[Nobody]

Thanks. But it appears to me that the C standard was a corporate
attempt to deprive the C community of its common understanding in C so
that the incompetent employees of vendors wouldn't have to do work and
could indeed be fired. There's too much that is "undefined". It sounds
very grave and wise to say that something is "undefined":

The intent is to allow compilers maximum flexibility. Not to make life
easy for compiler writers, but to allow the compiler to generate efficient
code.

Even Java does some of this, e.g. explicitly stating that updates to long
and double members aren't guaranteed to be atomic, in order to allow
32-bit platforms to implement the language efficiently (i.e. without
having to lock a mutex around every long or double assignment).

 

[Beej Jorgensen]

That's nuts.

Some people would say that forcing a system to evaluate function
arguments and expressions sequentially is nuts, too.

-Beej

 

[Tim Streater]

Wrong. C90 was accepted worldwide (except in Nilgesia, obviously).

Is that a province of Amnesia?

 

[Dik T. Winter]

> The following code
>
> #include <stdio.H>
> int main()
> {
> int i;
> i =3D 10;
> printf("%d %d\n", i++, i++);
> return 0;
> }
>
> when compiled using Microsoft C++ "in C mode" (with an input file with
> type C) displays
>
> 11 10
>
> and this is nonsense.

Nope, it is not since it invokes undefined behaviour, and in that case
everything is allowed.

> The problem is that as of K & R, postincrement
> was well-understood but it appears to me that the 99 standards twerps
> really messed things up on behalf of compiler vendors and their
> incompetent employees.

The problem is not with the postincrement but in the order in which parameters
to functions are evaluated, and whether they are possibly evaluated in
parallel. This problem has been present since C was ported to different
systems, it is only with C90 (the first "formal" standard) that it was
recognised as undefined behaviour.

Algol 60 required a strict left to right evaluation, and it was found that
that had severe restrictions for optimisation, so that writing an
expression one way was much slower than writing it another way which would
be equivalent.

> Not in the vast majority of cases. Normal compilers will generate code
> to fully evaluate i++ to the left of the rightmost comma.

Well, you know, it is just like in good old Fortran where the compiler
was allowed in the expression
R = F(X) * F(X)
to evaluate F (which is assumed to be a function returning a real) only
once and square the result. If F had side-effects that resulted in
different values at different calls the above expression would not be
allowed in the standard.

 

[Dik T. Winter]

>
> Thanks. But it appears to me that the C standard was a corporate
> attempt to deprive the C community of its common understanding in C so
> that the incompetent employees of vendors wouldn't have to do work and
> could indeed be fired. There's too much that is "undefined".

If you think so. In my opinion in C there is much less undefined than in
Fortran, but that is just opinion of course. In fact the first time I
encountered "undefined behaviour" was in Fortran where there are many
cases where something is disallowed by the standard without the
ability of a compiler to detect it (the Fortran equivalent of undefined
behaviour). At least, in C the expression:
r = f(x) * f(x);
requires 'f' to be called twice. In Fortran it is not even required in
the following:
R = F(X)
R = R * F(X)

> As in Wagner (die Meistersinger and Tannhauser), master-ship has
> changed its sign from the positive sign it had in the era of Algol 60,
> when men thought to be clear, to a dark and negative sign.

Yes, in Algol 60 strict left-to-right evaluation, so much so that it
baffled optimisers. On the other hand, Algol 60 had (I agree that it
was by accident) call by name, which could be pretty nasty. And of course
the strange case where you could pass an integer to a procedure that could
later on be used as either a label or a true integer value. Consider the
following program:
"begin"
"integer" label, x;
"procedure" goto(i); "begin" "goto" i "end";
"procedure" eval(i); "begin" x := i "end";
"procedure" goto or eval(i);
"begin" "if" label = 1 "then" goto(i) "else" eval(i) "end";
"for" label := 0, 1 "do" goto or eval(50);
50:
"end"
which is perfectly valid. And if you want to know some pretty nasty
cases of call by name, ask me, I have seen (and programmed) quite a lot.

> This material process has plainly happened in programming, for I am
> old enough to remember a time when you could simply know, and make
> predictions not falsified by corporate horseshit.

Oh, well, in that case you must precede Fortran. Helps me remember when
I had to port Richard Brent's package for long integer arithmetic on our
CDC Cyber, and found that it would only work when compiled without
optimisation, because it used some (undetectable) undefined stuff like:
IOLD = I
JOLD = J
I = - I
IF(J .NE. JOLD) GOTO 1000
where I and J where parameters and the optimiser happily decided that
the test was superfluous because J could never become unequal to JOLD.

> Comma had a meaning before the standard. It meant "do this, and when
> you are done, do this". This meaning should have been preserved. It
> wasn't because of corporate incompetence and greed.

That meaning was not even present in K&R C. Neither was it present in
Fortran (at least not in Fortran 66).

There must be a reason that C is the only older language you are yelling at.

 

[Dik T. Winter]

> The real intent of this nonsense was to make as many existing
> compilers work without change so that important stakeholders continued
> to make money. The public (the programmer: the end user) be damned.

I do not think that gcc has many stakeholders.

> You know as well as I that prior to C99, most compilers went left to
> right. It was a defacto standard, and the C99 group should have
> certified this. Instead, they chose to please fat cat corporations.

Apparently you do not know anything at all. Before C90 (look there: 90),
different systems had compilers that did it differently, and with some
compilers it simply dependend on optimisation level. Darn, I have seen
many bugs in C compilers in my time, but I never did consider this a bug
because I was already used to it since I used C (back in 1985 or something
like that). And before that I knew it from Fortran.

 

[Dik T. Winter]

> In <[email protected]>,
> spinoza1111 wrote: ....
>
> As I have already explained, this is just as true in C90 as in C99.

It was already true before C90.

 

[Kaz Kylheku]

That's freedom for the implementation.

Who cares about freedom for the implementation?

What is the ratio of users to implementors?

Sanely constraining the evaluation order has the benefit of eliminating
an entire class of bugs.

No, it means: if it matters, pre-evaluate. And if it doesn't matter,
it doesn't matter.

It also means that C codebases contain unknown numbers of accidental
dependencies on evaluation order---situations where it does matter, but someone
/didn't/ pre-evaluate.

You must learn to look at an issue from points of view other than
that of a coder. Sure, you can /code/ defensively against any language
feature. Unspecified evaluation order isn't a coding show-stopper.
Hardly anything is. You can code around anything.

 

[Willem]

Kaz Kylheku wrote:
)> That's freedom for the implementation.
)
) Who cares about freedom for the implementation?

Anybody who wants his code optimized properly by the compiler.

) What is the ratio of users to implementors?

Irrelevant given the above.

) Sanely constraining the evaluation order has the benefit of eliminating
) an entire class of bugs.

Not constraining the evaluation order has the benefit of making code
a lot more optimizable.

If you want to be protected from stuff like that, don't use C.

Or perhaps you can ask your compiler vendor to add a flag to enforce
strict evaluation order.


SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT

 

[jameskuyper]

Who cares about freedom for the implementation?

Developers care, or at least they should. Making things easy for
implementors makes it easier for them to create new implementations of
C and to maximize the effiiciency of more mature implementations.

What is the ratio of users to implementors?

Other than the fact that it is both large, and irrelevant, I'm not
sure.

Sanely constraining the evaluation order has the benefit of eliminating
an entire class of bugs.

"Sanity" admits a wide variety of interpretations. Some would consider
it insane to force implementors to either use, or at least emulate, an
evaluation order that might not be the most efficient one.