C standards and committees (was Re: strangest systems I've sent email from)

[Swift Griggs]

On Fri, 20 May 2016, Sean Conner wrote:
> By the late 80s, C was available on many different systems and was not 
> yet standardized.

There were lots of standards, but folks typically gravitated toward K&R or 
ANSI at the time. Though I was a pre-teen, I was a coder at the time.  
Those are pretty raw and primitive compared to C99 or C11, but still quite 
helpful, for me at least. Most of the other "standards" were pretty much a 
velvet glove around vendor-based "standards", IMHO.

> 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.

I'm pretty negative on committees, in general. However, ISO and ANSI 
standards have worked pretty well, so I suppose they aren't totally 
useless _all_ the time.

Remember OSI networking protocols? They had a big nasty committee for all 
their efforts, and we can see how that worked out. We got the "OSI model" 
(which basically just apes other models already well established at the 
time). That's about it (oh sure, a few other things like X.500 inspired 
protocols but I think X.500 is garbage *shrug* YMMV). Things like TPx 
protocols never caught on. Some would say it was because the world is so 
unenlightened it couldn't recognize the genius of the commisar^H^H^H 
committee's collective creations. I have a somewhat different viewpoint.

> All those "undefined" and "implementation" bits of C?  Yeah, competing 
> implementations.

Hehe, what is a long long? Yes, you are totally right. Still, I assert 
that C is still the defacto most portable language on Earth. What other 
language runs on as many OS's and CPUs ? None that I can think of.

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

Yeah, it's kind of an extension of the same issue, too many undefined grey 
areas. In practice, I don't run into these types of issues much. However, 
to be fair, I typically code on only about 3 different platforms, and they 
are pretty similar and "modern" (BSD, Linux, IRIX).

> 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 ...

I'm in the "please don't do squat for me that I don't ask for" camp. I 
know that horrifies and disgusts some folks who want GC and auto-bounds 
checking everywhere they can cram it in. Would SSA form aid with all kinds 
of fancy compiler optimizations, including some magic bounds checking? 
Sure. However, perhaps because I'm typical of an ignorant C coder, I would 
expect the cost of any such feature would be unacceptable to some. Also, 
there are plenty of C variants or special compilers that can do such 
things. Also, there are a few things that can be run with LD_PRELOAD which 
can help to find issues where someone has forgot to do proper bounds 
checking. Once people get on the "C sucks, put on some baby gates" bus, 
most of the actual working C coders get off at the next stop. Not judging, 
just observing. I've seen this over and over and over and ... 

>   -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"
> 	... )

I'm right there with you on this one! 

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

Hmm, well, people (me included in days gone by) tend to abuse signed 
scalars to simply get bigger integers. I really wish folks would embrace 
uintXX_t style ints ... problem solved, IMHO. It's right there for them in 
C99 to use.

> Except for, say, the Intel 432.  Automatic bounds checking on that one.

You can't always rely on the hardware, but perhaps that's your point.

> Trapping on signed overflow is still contentious today.  While some 
> systems can trap immediate on overflow (VAX, MIPS), the popular CPUs 
> today can't.

Hmmm, well I'm guessing most compilers on those platforms would support 
that (and hey, great!). 

> It's not to say they can't test for it, but that's the problem---they 
> have to test after each possible operation.

That's almost always the case when folks want rubber bumpers on C. That's 
really emblematic of my issues with that seemly instinctual reaction some 
folks have to C.

-Swift