strangest systems I've sent email from

[Sean Conner]

It was thus said that the Great Liam Proven once stated:
> On 29 April 2016 at 19:49, Mouse <mouse at rodents-montreal.org> wrote:
> > 
> > It's true that C is easy to use unsafely.  However, (a) it arose as an
> > OS implementation language, for which some level of unsafeness is
> > necessary, and (b) to paraphrase a famous remark about Unix, I suspect
> > it is not possible to eliminate the ability to do stupid things in C
> > without also eliminating the ability to do some clever things in C.
> 
> I think that the key thing is not to offer people alternatives that
> make it safer at the cost of removal of the clever stuff. It's to
> offer other clever stuff instead. C is famously unreadable, and yet
> most modern languages ape its syntax.

  By the late 80s, C was available on many different systems and was not yet
standardized.  The standards committee was convened in an attempt to make
sense of all the various C implementations and bring some form of sanity to
the market.  All those "undefined" and "implementation" bits of C?  Yeah,
competing implementations.

  For instance, why is signed integer arithmetic so underspecified?  So that
it could run on everything from a signed-magnitude machine [1] to a
pi-complement machine (with e-states per bit [2]).  Also, to give C
implementors a way to optimize code [3][6].

  And because of the bizarre systems C can potentially run on, pointer
arithmetic is ... odd as well [4].

  It also doesn't help that bounds checking arrays is a manual process, but
then again, it would be a manual process on most CPUs [5] anyway ... 

  -spc (Wish the C standard committee had the balls to say "2's complement
	all the way, and a physical bit pattern of all 0s is a NULL pointer"
	... )

[1]	I think there was only one signed-magnitude CPU commercially
	available, ever!  From the early 60s!  Seriously doubt C was ever
	ported to that machine, but hey!  It could be!

[2]	2.71828 ... 

[3]	Often to disasterous results.  An agressive C optimizer can optimize
	the following right out:

		if (x + 1 < x ) { ... }

	Because "x+1" can *never* be less than "x" (signed overflow?  What's
	that?)

[4]	Say, a C compiler an 8088.  How big is a pointer?  How big of an
	object can you point to?  How much code is involved with "p++"?

[5]	Except for, say, the Intel 432.  Automatic bounds checking on that
	one.  

[6]	Trapping on signed overflow is still contentious today.  While some
	systems can trap immediate on overflow (VAX, MIPS), the popular CPUs
	today can't.  It's not to say they can't test for it, but that's the
	problem---they have to test after each possible operation.  And not
	all instructions that manipulate values affects the overflow bit
	(it's not uncommon on the x86, for instance, to use an LEA
	instruction (which does not affect flags) to multiple a value by
	small constants (like 17 say) which is faster than a full multiple
	and probably uses fewer registers and prevents clogging the
	piplelines).