Re: Draft Secure C

Robert Gamble wrote:
Richard Heathfield wrote:
Robert Gamble said:
Jack wrote:
http://www.open-std.org/jtc1/sc22/wg14/
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1135.pdf

Has anyone gone through this?

Yes.

Is this useful?

Not in my opinion, but others differ.

Will it make it to the next standard?

Let's hope not.

Well, let's at least hope that we don't start designing a new Standard until
C99 has been widely implemented. What would be the *point*?

I think that a new Standard with carefully thought-out features which
reflect what the community values most may actually serve to increase
adoption of the rest of the C99 features faster than not. If a new
version provided functionality that the majority of the community could
get excited about and rally behind there is little doubt that
implementors would move at a much faster pace to implement it.

Absolutely correct. The Standard Committee may, or may not realize
this, but one thing is for sure, they do *NOT* realize that they
themselves are the reason this has not happened.

[...] Such a
venture would need to be extremely careful not to get bogged down with
the kinds of drastic changes, "special interests", and (what some
consider) unnecessary bloat that C99 brought along with it lest it
further jeopardize the relevance of the Standard, but success may be
the only thing that redeems it.

The C standard committee does not see the value of the language they
have ownership over, they don't see problems in the industry, and are
completely blind to the problems of the C language. There is a long
list of highly desirable features that the C language is crying out for
(no, not operator overloading -- I mean actual *functionality*) that
nobody is even thinking about.

[...] TR 24731 qualifies for at least "special interest" and bloat.

Huh? TR 24731 qualifies as *PLACEBO*. It does *NOT* accomplish what
it claims to set out to do. Because of the RSIZE_MAX fiasco, the
standard just continues to create portability problems. The thing is
just utter nonsense is what it is. The Robert Seacord proposal is a
little better (claimed to be targetted towards something different) but
*WAY* too slow. (It was sugggested by someone that I propose Bstrlib
to the C standard, however, manditory availability of the source is
considered one of its features.)

The *intended* scope of TR 24731 is not what I would call special
interest. Certainly any text processing programs should be using some
kind of alternate string functionality versus the CLIB's C strings.
Its just that TR 24731 is hardly any better.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

.

Relevant Pages

  • Re: Teaching new tricks to an old dog (C++ -->Ada)
    ... > the standard language. ... Or did they just implemented some 80% of the new features? ... there was a fully compiant C compiler available. ...
    (comp.lang.ada)
  • Re: Teaching new tricks to an old dog (C++ -->Ada)
    ... > the standard language. ... Or did they just implemented some 80% of the new features? ... there was a fully compiant C compiler available. ...
    (comp.lang.cpp)
  • Re: Specifications for operator overloading
    ... but in the real world C is the language in which operating ... of features? ... the compiler writers ... standard through a back door, the same one they are trying to use now ...
    (comp.lang.c)
  • Re: Why code completion and early error checking are needed
    ... > identifiers visible in the current scope when it provides code completion ... You can if you rely on parsing standard code only, ... > large-scale projects using a different programming language. ... Most of the features above can be implemented using the existing language. ...
    (comp.lang.cpp)
  • Re: Cracking DES with C++ is faster than Java?
    ... introduced since the last C++ standard). ... there is no intrinsic penalty for C features in C++. ... but as soon as you use a feature in one language that isn't in the ... standard class instance ...
    (comp.lang.java)