Re: Urgent C Questions

On Thu, 17 Jan 2008 04:39:44 -0600, Chris Hills wrote
(in article <SFioyTKwBzjHFAdw@xxxxxxxxxxxxxxxxxxxx>):

In article <0001HW.C3B42CEF05E37886F01846D8@xxxxxxxxxxxxxxxx>, Randy
Howard <randyhoward@xxxxxxxxxxxxxxxxx> writes

We'll have to wait and see, not to mention whatever C0x does to muddy
up the waters again. That said, since C99 isn't readily available in
compilers (real support, not bits and pieces), it will take a miracle
by the C committee to make anyone adopt any more changes if they are
perceived as unnecessary as that batch from 99.

There have been suggestions within ISO C to drop some features of C99
in C20** I think it has been realised that no one is going to fully
implement C99 so there is no point on building a new standard on top of
it.

That is pretty interesting. It's not often that a tech body has the
spine to admit in so public a fashion that their last product was in
need of a good bulldozing.

What is needed is to sort of go back to C95 and move forward again
looking at what has actually been implemented and I think the comment
was "implemented by more than two mainstream compilers."

Just go back to C95 and leave it the hell alone. :-)

ISO C is going to have to move back to what the serious users are
actually doing i.e. real world C Which will screw all those here who
want only ISO C as described in all versions of ISO/ANSI C and K&R but
not as used in reality.

"real world C" means more than one thing, imo. Those that are working
on things that need to run on a lot of different platforms tend to be
more of a stickler for the sandbox model where you only do the things
guaranteed to be valid pretty much everywhere, and if you must jump
outside that, you do it by breaking out the nonstandard pieces and port
the implementation to each platform with conditional code (often behind
an abstraction API).

Another group of "real world C" programmers only care about one, or a
very limited number of platforms, and will write in a variant of C that
is known to work for those, and don't care one way or the other if it
runs on a DS9K, or even a recent OS they don't support.

In both of those cases, existing C compilers are "plenty good". Often
compiling either their own "variant", like stock gcc without the
conformance switches turned on, or strict C89/90/95 conformance enabled
gets both goals achieved.

Neither group needs to see the C standard change much, if at all.

There is another group though that wants C to be more of a true subset
of C++, for reasons that I have never shared. You may have a different
take on it, but getting two different standards bodies to make a
serious attempt at that happening seems unlikely. The very fact that
two different bodies are responsible for it pretty much demonstrates
that yes, in fact they are different languages, and that's fine. It
seems ludicrous to spend a lot of effort to make them more directly
linked just because the names of the languages are very similar.

Where will the pedants here go if items are dropped from ISO C?

I hate to break the news to you, but almost all of the "real world C"
crowd doesn't care one way or the other what the C committee does
anymore. They had all they really needed to get their job done in
1989. The "pedants" will probably be forced to start complaining about
code that is not C20xx clean. And if no compilers are available for it
a decade later, they'll be very lonely, just like the C99 pedants are
today.

By the
current definition of what C is from most of them it will include C99
and therefore things that are no longer legal...

If this C20xx standard comes to pass, it'll probably be yet another $18
(or quite a bit more for a while, then getting reduced when nobody buys
it to $18) pdf file, which will be quietly ignored by the compiler
vendors.

It's possible that something magical will happen, and everything wrong
with C99 will disappear, and everything good about it will stay around,
plus a few new things of value will appear, and gcc, icc, msvc, and 20
or 30 embedded compilers will all move to adopt it ASAP; the programmer
community will all clamor for it and start a mass email and telephone
campaign to the vendor of choice. It's also possible that my local dog
catcher will be named as Imperious Overlord of the Planet by universal
world acclaim. Both are about equally likely.

And if gets() isn't completely deprecated this time, I'll know they're
just pulling my leg anyway. :)

I expect It will probably get left in so as not to break a lot of
existing code.

So it'll be another joke. Hint: All three programs in the world that
use gets() in a perfectly safe way can be modified in a matter of
minutes to work without it, and all the remainder are broken already.

The notion that "we don't want to break code by removing a feature that
makes it almost impossible for it not to be broken by default" is one
of the more silly things I've seen done outside of government.

--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw





.

Relevant Pages

  • Re: C99: Suggestions for style(9)
    ... started and a decade ago there was a new C standard. ... switched to C99 as default ... so not any more old style declarations are added. ... how today's compilers handle unaliased local variables. ...
    (freebsd-hackers)
  • Re: Why the C committee doesnt provide an implementation when the standard is published?
    ... It is THE de-facto standard on the desktop. ... have pointed out recently the current crop of MS compilers are very good ... diverged one way whilst C went a different way 95 and C99. ... and quite a number of C99 language features. ...
    (comp.lang.c)
  • Re: Some general questions about C and good practice
    ... C89 is the 1989 ANSI standard, the first official standard for the ... C99 is the 1999 ISO standard. ... the C90 standard, but very few implementations fully support it. ... but few compilers yet implement ...
    (comp.lang.c)
  • Re: Rounding double
    ... substantial subsets of C99, but neither implements the entire C99 ... standard, and based on that, I want to write a ... unimplemented features for *all* the compilers I might want to use. ... C90 standard. ...
    (comp.lang.c)
  • Re: Whats the deal with C99?
    ... Intel compilers offer some c99 support ... I've never heard before that C99 is a rejected standard. ... but it's true for all mainstream compilers. ...
    (comp.lang.c)