Re: So what Standard are we working off?

Richard Heathfield wrote:
Frederick Gotham said:

Keith Thompson posted:


When the 1999 updated standard was issued, there was already an
existing standard that had been nearly universally adopted. It wasn't
perfect, but it did make it possible to write actual portable code.
There wasn't nearly as much demand for C99 as the was for C89; it made
the difference between having one standard and having another
different standard.


Do you think the C99 Standard will ever replace the C90 Standard, or do
you think the C community is content with C90 and does not want to change
anything?

I think the part of the C community that cares about portability wants a
widely-implemented standard, which it already has. Until C99 becomes as
widespread as C90, why would anyone use it if they need portability?


Come on, quit being so negative. Having everybody agree on "restrict"
now, for example, is better than a bunch of subtly incompatible type
aliasing optimization extensions later.

And the part of the C community that couldn't give two hoots about
portability aren't interested in the Standard anyway - they just want
something that works on /their/ compiler, and many such people think the
Standard (if they've even heard of it) takes second place to their compiler
documentation.

C99-isms are creeping in, slowly. "restrict" works on Intel C, GCC,
the Sun C, and the HPUX C, and IBM VisualAge for AIX. The stdint.h
typedefs are working their way into just about everywhere. No need for
despair.


Is there anything particularly unpleasant about C99?

The presumption that people are using it, which is a far from accurate
presumption. I am not using C99, and as far as my compiler is concerned the
// comment is a syntax error, and I wish people wouldn't use it in clc
because it means an extra step for me before I can compile the code.
<snip>

I use C99 features where I can. Most have hackish or platform-specific
fallbacks that work well enough. As an example, it's nice to use the
struct hack as a fallback-only thing.

Mark F. Haigh
mfhaigh@xxxxxxxxxxxxx

.

Relevant Pages

  • Re: C portability is a myth
    ... portability has to do with availability, ... I am not convinced yet that it isn't a compiler bug (I saw ... >> was the C standard itself which was the culprit in causing the ... Porting requires effort regardless of whether or not I have conformed ...
    (comp.lang.c)
  • Re: <ctype.h> toLower()
    ... I need to link in the standard C library. ... > know what the target platform is, your compiler doesn't. ... at it -- it might not explain portability, ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Storgae durations
    ... last article you don't even have a conforming C99 implementation on your ... you think there can only be *one* standard? ... compiler, but that's not what I mentioned. ...
    (comp.lang.c)
  • Re: which tutorial to use?
    ... portability, ... extensions that aren't in any standard are widespread, ... It seems to me that // comments were widely portable long before C99, ... that that compiler happens to support. ...
    (comp.lang.c)
  • Re: Storgae durations
    ... last article you don't even have a conforming C99 implementation on your ... you think there can only be *one* standard? ... seen on any compiler. ...
    (comp.lang.c)