Sequence points



....are defined in ISO/TEC 9899:TC2 committee draft-May 6 2005, and
yes, preincrement and postincrement is delayed until the sequence
point, and the standard has an elaborate explanation of where sequence
points occur.

They make C programs easier to optimize and pipeline since you don't
want to wait, in p++ for the postincrement to occur (which is a memory
access) after stacking p. You could be a hardass on the order of a
Wirth and insist that p++, as a legacy mistake, be implemented as an
indivisible atomic operation in the interest, under-represented on the
committee, of safety and therefore humanity but it appears that the
Standards committee members were birds of a Feather.

The problem is that this nonsense invalidates existing C code for
ordinary applications from the standpoint of upgrading to a new,
standard compiler, in favor of high-speed military-industrial
applications, the standards committee having neglected the public
interest.

The process was explained as regards the forced innovation of computer-
controlled machine tools in the 1940s in the USA in David Noble's book
Forces of Production (Oxford 1975). The US air force forced the
manufacturers to design and vend overelaborate machine tools capable
of cutting, not only straight Euclidean lines and simple curves for
locomotive repair shops and steel mills, but the far more complex
curves required by military aviation.

The British and other nationalities just trundled along in the rear
with the gear as they did in Afghanistan and Iraq ten years on, being
(as we Pennsylvania Dutch say) too soon old to late smart.

The overelaborate technology was then programmed by white collar
recent graduates in the back office, in Noble's book, but they had no
opportunity to test what were in actuality computer programs.

The shops of the time, immediately after World War II, were dominated
not so much by their managers and their foremen as by men like my
great-grandfather, a skilled machinist who was still working in his
80s in the early 1940s as part of the war effort. The skilled
machinists controlled the pace of production according to their own
combination of scientific knowledge (obtained at night school such as
Case Institute in great-grandfather's Cleveland, later Case Western
Reserve) and a painfully acquired sense of what would actually work
under shop conditions (several of my uncles, who also worked in this
industry, were missing fingers).

But after the US Air Farce got into the act after the war, these men
were told to stand down and merely mount the paper tapes produced by
the college boys. After much grumbling, in Noble's account, they did
so, to see scrap metal, of various interesting shapes, suitable for
rec room decoration in then-fashionable shapes alone, being produced
at high speed in a way that endangered life and limb.

Management in particular set its face, as did John von Neumann at the
time as regards digital computer technology, against the use of the
machine by the lads to produce a tool to make, in turn, an assigned
tool. In the new, militarised regime, all steps were
"Taylorised" (where Frederick Taylor was the 1920s management genius
who decided that workmen were apes who needed to have everything
broken down into a simple vector of steps), and just as Fortran was to
force 1950s programmers to think like apes, the machine tool shop was
to be a place where men like my great-grandfather (who knew several
languages and read several books a week) would act not like men but
like children, always accepting the superior wisdom of his social
superiors.

People like us, even after WWII, weren't real Americans. No, in
Taylor, we were "little Pennsylvania Dutchmen" who couldn't understand
machine tool programming as well as the college boys back from
Princeton. This despite the fact that another uncle died in WWII
fighting Fascism and leading another outgroup of the time, the
Japanese American Nisei of the 442nd Regimental Combat Team.

[For let us not speak falsely now the hour is much too late.]

Noble's book has a happy ending as regards machine tools. The unions,
in direct violation of the Taft-Hartley Act, a bad law, fought for and
won back shop floor control.

Fast forward to 2008. In making the decision it made, the standards
board decided that a relatively small high tech industry of fast
computation is more important than boring applications written by
programmers who expected the effect of p++ to be atomic, because
military and corporate needs trump those of skilled labor and small
business in America. In fact, to preserve itself, this Beast invaded
Iraq in 2003.

I could see the wisdom of the standards team: all I have to do is not
use C, and I am delighted not to use C. The problem is that while
programmers here talk a good game about what studly coders they are
when they write "their" code, most code, including most of "their"
code isn't their property and can be properly spoken of as orphan
code.

Insofar as this code was coded by programmers who expected p++ to be
atomic (in a statement which doesn't assign it), and then changed
under the usual pressure to make some manager look good to assign p
perhaps in some clever alias, then the high and low tech code is of
course a disaster waiting to happen.

A disaster which may be occuring all around us, without anyone knowing
why; recently, NASA suppressed a report about systems failures in
American passenger aviation on a daily basis. At any point, software
could be and probably is involved, software which UNLIKE the P-38s and
Liberty Ships lovingly machined by men like my great grandfather, has
no father.

The men who demanded simple recognition of their skills didn't sit on
any Internet and bully people like little girls, and they didn't blame
book authors for the incomprehensibility of their decisions, which
cannot be explained clearly without using Marx (and, in a practical
sense, especially not then).

I don't think Herb Schildt understood what was going on in the
standard. But if he had, and had explained it properly, there might
have been a revolution. But, probably not.
.



Relevant Pages

  • Re: In answer to RW - again (was: Sorts (revised)
    ... Robert Wagner wrote: ... >>while programmers come and go each year. ... >whether new code should follow obsolete standards. ... standards you had imposed on a shop you'd managed. ...
    (comp.lang.cobol)
  • Re: In the matter of Herb Schildt
    ... A PROFESSIONAL DOES NOT USE TOILET LANGUAGE. ... I don't think I actually care whether I give you the impression that ... Today, standards are funded by companies, and these companies refuse ... Programmers love to fantasize that they are "engineers" being ...
    (comp.lang.c.moderated)
  • Re: The annotated annotated annotated C standard
    ... Standards are the same thing as reference books. ... trying to explain your mess to the vast majority of real programmers. ... block in a usable modern language. ... I've known very few competent programmers in person. ...
    (comp.programming)
  • Re: The problems in comp.lang.c
    ... to get the feel of the newsgroup first. ... I would expect that someone familiar with those standards would ... inform you that none of those language standards addresses ... any doubt that these are topics of interest to C programmers - ...
    (comp.lang.c)
  • Re: A good compiler
    ... One can try to make a language "safe", ... Because the abstraction level is so low, that even careful programmers ... Standard Library string functions like strcpyare not considered secure by today's standards. ... Graphic and web-based applications make extensive use of text input fields and, because of standards like XML, data exchanged between programs is increasingly in string form as well. ...
    (comp.lang.c)