From mboxrd@z Thu Jan  1 00:00:00 1970
From: erik quanstrom <quanstro@quanstro.net>
Date: Mon, 29 Oct 2012 21:10:41 -0400
To: 9fans@9fans.net
Message-ID: <a7d7fa571d182bc1e59c2f91324be275@kw.quanstro.net>
In-Reply-To: <20121030003501.AE691B827@mail.bitblocks.com>
References: <15723310.yIARpoJMSL@coil>
	<4824335454f1b1d47dbc8439b4af8ea3@kw.quanstro.net>
	<20121029223541.8C198B827@mail.bitblocks.com>
	<0f05642b113b3ecfc160e82a9ca4db32@brasstown.quanstro.net>
	<20121029232652.5160BB827@mail.bitblocks.com>
	<74f73b64cc6de4a3bd10367591439816@kw.quanstro.net>
	<20121030003501.AE691B827@mail.bitblocks.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Subject: Re: [9fans] caveat... optimizer? the `zero and forget' thread on HN
Topicbox-Message-UUID: ccd3a868-ead7-11e9-9d60-3106f5b1d025

On Mon Oct 29 20:36:26 EDT 2012, bakul@bitblocks.com wrote:
> Not a question of fault but IMHO a programmer, like a
> carpenter or anyone who does real work, has to experiment and
> learn the strengths and weaknesses of his tools of his trade
> if he wants to become competent.
>
> The language standard can only mandate what you can do within
> the language.  For instace, if the blog writer had done this:
>
>     ...
>     memcpy(a, 0, sizeof a);
>     for (i = 0; i < sizeof a; i++)
> 	assert(a[i] == 0);
>     return 0;
> }
>
> He would have seen that every a[i] was indeed 0. But if you
> use means external to the language (such as used a debugger or
> look at the assembly language) to check side-effects, you get
> to see the underside of optimization. Ugly, confusing and
> possibly surprising. If you want to do something not covered
> in the standard, learn what the compiler does and find a
> compiler dependent way.

you are arguing for a cartoon hammer that runs away when you're
not looking at it.

> > and i can design a standards-compatable compiler that will break
> > most any c program.
>
> Care to give an example? I am genuinely interested. The C
> standard is far from perfect but it has worked well enough.
> [Where is doug gywn when we need him?]

oh, there are a number of obvious under-handed tricks.  let's see,
for an intel compiler, change the structure padding to something bizarre
like 3 bytes.  that will break a large number of linux drivers.  (the 57711
for sure!)  rearrange structure elements other than the first.
you can change from signed-preserving to unsigned preserving.
that'll catch a lot of folks out.  do ones-complement arithmetic
(i believe that's still legal).  have 10-bit bytes. 20 bit shorts, 40 bit
ints, 45-bit longs and 80-bit vlongs.  (i'm not sure that's completely
legal, but you get the point.)  make pointers to different types different
sizes.  the list goes on.  the combinations are silly, too.  default
unsigned characters with unsigned preserving behavior.  good luck
debugging that!

and since you would allow compilers to mess with side effects, we could
have a genuine field day.

> > what i think has broken down is common sense among compiler
> > writers.  they're too focused on being fast, and not focused enough
> > on being *useful*.
>
> I agree but I am afraid they do that because that is what the
> market demands.  Pretty much most of the software that the
> Internet runs on + used by most people + businesses uses C or
> C++ so C/C++ and their standards have been *useful* (but see
> below). Fast does matter when you scale up (a big company may
> need 18K servers instead of 20K and that results in savings
> and less heat generation).

i don't understand your use of the world "useful".  to me, the c
standard has become like a political issue.  it's something to
game for personal advantage.

- erik