C standards and committees (was Re: strangest systems I've sent email from)
swiftgriggs at gmail.com
Fri May 20 17:49:36 CDT 2016
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
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
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 .
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  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
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.
More information about the cctalk