CERT C Secure Coding Standard - last call for reviewers

Discussion in 'C Programming' started by Robert Seacord, Mar 20, 2008.

  1. We would like to invite the C community to review and comment on the
    current version of the CERT C Secure Coding Standard available online at
    www.securecoding.cert.org <http://www.securecoding.cert.org> before
    Version 1.0 is published. To comment, you can create an account on the
    Secure Coding wiki and post your comments there.

    Our intent is to complete major development of Version 1.0 by April 18,
    2008, with the published version of the standard being available in
    September. Once Version 1.0 of the standard goes to the publisher, we
    will begin development of Version 2.0. That is, we will continue to
    maintain the wiki to further advance the "working version" of the CERT C
    Secure Coding Standard. The published 1.0 version will become the
    official version, until replaced by a future version. It is unlikely a
    subsequent version will be released any time in the next 2-3 years, so
    we would like to ensure that Version 1.0 will be a high quality product
    that will promote and encourage secure coding practices.

    Thanks for any help and assistance you have already provided and for any
    additional contribution you may make. There are currently 184
    individuals who have contributed to the development of this standard,
    without whom this effort could not have succeeded.

    Thanks,
    rCs

    --
    Robert C. Seacord
    Senior Vulnerability Analyst
    CERT/CC
    Work: 412-268-7608
    FAX: 412-268-6989
    Robert Seacord, Mar 20, 2008
    #1
    1. Advertising

  2. Robert Seacord

    Walter Banks Guest

    Robert,

    It has been a while since I looked at your wiki on secure coding and forgot
    how important and clear it was on good coding practice. I would like to
    link the wiki from our website as a service to our customers writing code
    for embedded systems applications.

    Let me know when it is published and I will be happy to have an item
    posted on that as well.

    Nice piece of work

    Walter Banks
    Byte Craft Limited


    Robert Seacord wrote:

    > We would like to invite the C community to review and comment on the
    > current version of the CERT C Secure Coding Standard available online at
    > www.securecoding.cert.org <http://www.securecoding.cert.org> before
    > Version 1.0 is published. To comment, you can create an account on the
    > Secure Coding wiki and post your comments there.
    >
    > Our intent is to complete major development of Version 1.0 by April 18,
    > 2008, with the published version of the standard being available in
    > September. Once Version 1.0 of the standard goes to the publisher, we
    > will begin development of Version 2.0. That is, we will continue to
    > maintain the wiki to further advance the "working version" of the CERT C
    > Secure Coding Standard. The published 1.0 version will become the
    > official version, until replaced by a future version. It is unlikely a
    > subsequent version will be released any time in the next 2-3 years, so
    > we would like to ensure that Version 1.0 will be a high quality product
    > that will promote and encourage secure coding practices.
    >
    > Thanks for any help and assistance you have already provided and for any
    > additional contribution you may make. There are currently 184
    > individuals who have contributed to the development of this standard,
    > without whom this effort could not have succeeded.
    >
    > Thanks,
    > rCs
    >
    > --
    > Robert C. Seacord
    > Senior Vulnerability Analyst
    > CERT/CC
    > Work: 412-268-7608
    > FAX: 412-268-6989
    Walter Banks, Mar 20, 2008
    #2
    1. Advertising

  3. Robert Seacord

    Guest

    On Mar 20, 4:02 pm, Robert Seacord <> wrote:
    > We would like to invite the C community to review and comment on the
    > current version of the CERT C Secure Coding Standard available online atwww.securecoding.cert.org<http://www.securecoding.cert.org> before
    > Version 1.0 is published. To comment, you can create an account on the
    > Secure Coding wiki and post your comments there.

    I read a few pages, quoting from INT01-A:
    >> The size_t type is typically represented by the same number of bits as int,
    >> that is, sizeof(size_t) == sizeof(int)). In this case, n >>might be greater
    >> than INT_MAX. The loop, however, will executes n times because the
    >> comparison i < n is an unsigned comparison. Once i >> > INT_MAX, i takes on
    >> negative values starting with (INT_MIN). Consequently, the memory locations

    Not really. Once i overflows, UB happends and there is nothing
    guaranteed.
    >> referenced by p precede the >> memory referenced by p and a
    >> write-outside-array bounds occurs.

    I assume this collection of documents has more errors such as the one
    I mentioned.
    (The assumption is done because I only read 2 or perhaps 3 pages from
    your link and wasted 10 minutes)
    Another error in the same page is that you clam that code which uses
    'rsize_t' is compliant.

    Secure programming is beyond C's UB. Perfectly conforming programs can
    still be insecure, your pages seem to have neither. (conforming or
    secure programs).

    Update: okay, in that *same* page (INT01-A) I found this code which
    claims to be secure & conforming

    >> #define BUFF_SIZE 10
    >> int main(int argc, char *argv[]){
    >> rsize_t size;
    >> char buf[BUFF_SIZE];
    >> size = atoi(argv[1]); /* vipp: atoi in secure code? */
    >> /* vipp: where are your checks for argc? */
    >> if (size < BUFF_SIZE){
    >> strncpy(buf, argv[2], size); /* vipp: ka-boom */
    >> buf[size] = '\0';
    >> }
    >> }
    , Mar 20, 2008
    #3
  4. Robert Seacord

    jacob navia Guest

    wrote:
    > Another error in the same page is that you clam that code which uses
    > 'rsize_t' is compliant.
    >


    This is explained in:
    https://www.securecoding.cert.org/c...ger values representing the size of an object

    The type size_t generally covers the entire address space. [TR 24731-1]
    introduces a new type rsize_t, defined to be size_t but explicitly used
    to hold the size of a single object. In code that documents this
    purpose by using the type rsize_t, the size of an object can be checked
    to verify that it is no larger than RSIZE_MAX, the maximum size of a
    normal single object, which provides additional input validation for
    library functions. See [STR00-A. Use TR 24731 for remediation of
    existing string manipulation code] for additional discussion of TR 24731-1.

    Any variable that is used to represent the size of an object including
    integer values used as sizes, indices, loop counters, and lengths should
    be declared as rsize_t if available.

    > Secure programming is beyond C's UB. Perfectly conforming programs can
    > still be insecure, your pages seem to have neither. (conforming or
    > secure programs).
    >
    > Update: okay, in that *same* page (INT01-A) I found this code which
    > claims to be secure & conforming
    >
    >>> #define BUFF_SIZE 10
    >>> int main(int argc, char *argv[]){
    >>> rsize_t size;
    >>> char buf[BUFF_SIZE];
    >>> size = atoi(argv[1]); /* vipp: atoi in secure code? */
    >>> /* vipp: where are your checks for argc? */
    >>> if (size < BUFF_SIZE){
    >>> strncpy(buf, argv[2], size); /* vipp: ka-boom */
    >>> buf[size] = '\0';
    >>> }
    >>> }


    This is bogus. The code is trying to explain one specific problem, i.e.
    that signed int comparisons with some constant assume that the integer
    is greater than zero implicitely. To avoid this, rsize_t is recommended.

    Conclusion:

    I wasted 10 minutes to read your message. You have no comprehension
    about what the code examples are intended to show, and you start
    complaining about things that do not concern the example directly.


    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
    jacob navia, Mar 20, 2008
    #4
  5. jacob navia wrote:
    > This is bogus. The code is trying to explain one specific problem, i.e.
    > that signed int comparisons with some constant assume that the integer
    > is greater than zero implicitely. To avoid this, rsize_t is recommended.


    I think the point was valid: If examples are given, they ought
    to follow *all* the "good practice guidelines". The exhibited
    code had *several* security, portability, and reliability issues.

    Concentrating on some presumed benefit of rsize_t rather than
    genuinely serious safety issues is bad strategy and bad tactics.
    Douglas A. Gwyn, Mar 21, 2008
    #5
  6. Robert Seacord

    CBFalconer Guest

    Walter Banks wrote:
    >
    > It has been a while since I looked at your wiki on secure coding
    > and forgot how important and clear it was on good coding practice.
    > I would like to link the wiki from our website as a service to our
    > customers writing code for embedded systems applications.
    >
    > Let me know when it is published and I will be happy to have an
    > item posted on that as well.


    Please do not top-post. Your answer belongs after (or intermixed
    with) the quoted material to which you reply, after snipping all
    irrelevant material. See the following links:

    --
    <http://www.catb.org/~esr/faqs/smart-questions.html>
    <http://www.caliburn.nl/topposting.html>
    <http://www.netmeister.org/news/learn2quote.html>
    <http://cfaj.freeshell.org/google/> (taming google)
    <http://members.fortunecity.com/nnqweb/> (newusers)



    --
    Posted via a free Usenet account from http://www.teranews.com
    CBFalconer, Mar 21, 2008
    #6
  7. Robert Seacord

    CBFalconer Guest

    Robert Seacord wrote:
    >
    > We would like to invite the C community to review and comment on the
    > current version of the CERT C Secure Coding Standard available online
    > at www.securecoding.cert.org <http://www.securecoding.cert.org>
    > before Version 1.0 is published. To comment, you can create an
    > account on the Secure Coding wiki and post your comments there.


    I could find no way to download a draft.

    --
    [mail]: Chuck F (cbfalconer at maineline dot net)
    [page]: <http://cbfalconer.home.att.net>
    Try the download section.



    --
    Posted via a free Usenet account from http://www.teranews.com
    CBFalconer, Mar 21, 2008
    #7
  8. CBFalconer said:

    > Walter Banks wrote:
    >>
    >> It has been a while since I looked at your wiki on secure coding
    >> and forgot how important and clear it was on good coding practice.
    >> I would like to link the wiki from our website as a service to our
    >> customers writing code for embedded systems applications.
    >>
    >> Let me know when it is published and I will be happy to have an
    >> item posted on that as well.

    >
    > Please do not top-post.


    Those who have nothing to say should say nothing, and those who breach
    netiquette guidelines should stop doing so before preaching netiquette to
    others.

    Now - secure coding.

    I have a few questions about the document. Firstly, why is it based on C99?
    Is it because it was written at a time when C99 take-up was anticipated
    more optimistically?

    The trouble is that this dependence makes the document itself less useful
    than it might be. By encouraging the use of inline functions over macros,
    for example, you're actually encouraging people to make their code
    uncompilable under C90. If C99 were as widely implemented as C90, that
    wouldn't be a problem. But it isn't.

    I said I had a few questions, but during the course of asking the last one
    I had two browser crashes. Does the OP have a single-page
    (very-long-page!) version available for download?

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -http://www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
    Richard Heathfield, Mar 21, 2008
    #8
  9. Robert Seacord

    jacob navia Guest

    Richard Heathfield wrote:
    > CBFalconer said:
    >
    >> Walter Banks wrote:
    >>> It has been a while since I looked at your wiki on secure coding
    >>> and forgot how important and clear it was on good coding practice.
    >>> I would like to link the wiki from our website as a service to our
    >>> customers writing code for embedded systems applications.
    >>>
    >>> Let me know when it is published and I will be happy to have an
    >>> item posted on that as well.

    >> Please do not top-post.

    >
    > Those who have nothing to say should say nothing, and those who breach
    > netiquette guidelines should stop doing so before preaching netiquette to
    > others.
    >
    > Now - secure coding.
    >
    > I have a few questions about the document. Firstly, why is it based on C99?
    > Is it because it was written at a time when C99 take-up was anticipated
    > more optimistically?
    >


    C99 is standard C, and they are correct using it. If you do not like
    standard C or feel that you have to wage your personal little war
    against the standard go elsewhere.

    > The trouble is that this dependence makes the document itself less useful
    > than it might be.


    Do not use it then.

    > By encouraging the use of inline functions over macros,
    > for example, you're actually encouraging people to make their code
    > uncompilable under C90.


    C90 is no longer standard C since 1999.

    If C99 were as widely implemented as C90, that
    > wouldn't be a problem. But it isn't.
    >


    There are several implementations. Gcc's implementation is almost
    ready. They did not finish it because C has disappeared from
    their objectives. GNU doesn't care about the language anymore.
    More or less the same with Microsoft, even if their interest on C
    has picked up recently.


    > I said I had a few questions, but during the course of asking the last one
    > I had two browser crashes. Does the OP have a single-page
    > (very-long-page!) version available for download?
    >



    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
    jacob navia, Mar 21, 2008
    #9
  10. jacob navia said:

    > Richard Heathfield wrote:
    >> CBFalconer said:
    >>
    >>> Walter Banks wrote:
    >>>> It has been a while since I looked at your wiki on secure coding
    >>>> and forgot how important and clear it was on good coding practice.
    >>>> I would like to link the wiki from our website as a service to our
    >>>> customers writing code for embedded systems applications.
    >>>>
    >>>> Let me know when it is published and I will be happy to have an
    >>>> item posted on that as well.
    >>> Please do not top-post.

    >>
    >> Those who have nothing to say should say nothing, and those who breach
    >> netiquette guidelines should stop doing so before preaching netiquette
    >> to others.
    >>
    >> Now - secure coding.
    >>
    >> I have a few questions about the document. Firstly, why is it based on
    >> C99? Is it because it was written at a time when C99 take-up was
    >> anticipated more optimistically?
    >>

    >
    > C99 is standard C, and they are correct using it.


    I didn't say they were incorrect to use it. I asked *why* they used it.

    > If you do not like standard C or feel that you have to wage your
    > personal little war against the standard go elsewhere.


    I think my question was reasonable. If you don't like what I write, well,
    nobody is forcing you to read it.

    >> The trouble is that this dependence makes the document itself less
    >> useful than it might be.

    >
    > Do not use it then.


    Is that the recommendation of the OP, too? That people who wish to write
    portable code should not use the CERT C thing? I'd like to hear that from
    him, rather than you, since it's his document.

    >> By encouraging the use of inline functions over macros,
    >> for example, you're actually encouraging people to make their code
    >> uncompilable under C90.

    >
    > C90 is no longer standard C since 1999.


    By that reasoning, lcc-win32 hasn't been a conforming implementation for
    over eight years, and it remains non-conforming today, so please stop
    banging on about it in comp.lang.c all the time because - by *your*
    argument - it isn't a C compiler.

    <snip>

    --
    Richard Heathfield <http://www.cpax.org.uk>
    Email: -http://www. +rjh@
    Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
    "Usenet is a strange place" - dmr 29 July 1999
    Richard Heathfield, Mar 21, 2008
    #10
  11. Robert Seacord

    Ed Prochak Guest

    On Mar 21, 9:23 am, Walter Banks <> wrote:
    > Chuck,
    >
    > Consider me told. I have seen your message I have read your links
    > save the off topic posts that everyone else has to endure. If
    > you must tell me do so privately. I will arrange for my filters to
    > ignore the messages and you will get the satisfaction of pointing
    > out a wrong and the rest of the newgroup will not endure endless
    > off topic threads whose subject line doesn't fit the message
    > of top vs bottom vs 4 line signature (yours is 9 btw).
    >
    > Regards,
    >
    > w..
    >
    > CBFalconer wrote:
    > > Walter Banks wrote:

    >
    > > > It has been a while since I looked at your wiki on secure coding
    > > > and forgot how important and clear it was on good coding practice.
    > > > I would like to link the wiki from our website as a service to our
    > > > customers writing code for embedded systems applications.

    >
    > > > Let me know when it is published and I will be happy to have an
    > > > item posted on that as well.

    >
    > > Please do not top-post. Your answer belongs after (or intermixed
    > > with) the quoted material to which you reply, after snipping all
    > > irrelevant material. See the following links:

    >
    > > --
    > > <http://www.catb.org/~esr/faqs/smart-questions.html>
    > > <http://www.caliburn.nl/topposting.html>
    > > <http://www.netmeister.org/news/learn2quote.html>
    > > <http://cfaj.freeshell.org/google/> (taming google)
    > > <http://members.fortunecity.com/nnqweb/> (newusers)

    >
    > > --
    > > Posted via a free Usenet account fromhttp://www.teranews.com


    But the rest of us will still have to deal with your top posting.
    Please stop. It is annoying.

    Note: I did NOT fix your post, I quoted verbatim. Is it really so hard
    for you to not top post?

    Ed
    Ed Prochak, Mar 21, 2008
    #11
  12. Robert Seacord

    jacob navia Guest

    Walter Banks wrote:
    > Chuck,

    [snip]

    Falconer is our resident troll. Please just ignore him.


    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
    jacob navia, Mar 21, 2008
    #12
  13. Robert Seacord

    Walter Banks Guest

    Chuck,

    Consider me told. I have seen your message I have read your links
    save the off topic posts that everyone else has to endure. If
    you must tell me do so privately. I will arrange for my filters to
    ignore the messages and you will get the satisfaction of pointing
    out a wrong and the rest of the newgroup will not endure endless
    off topic threads whose subject line doesn't fit the message
    of top vs bottom vs 4 line signature (yours is 9 btw).

    Regards,

    w..


    CBFalconer wrote:

    > Walter Banks wrote:
    > >
    > > It has been a while since I looked at your wiki on secure coding
    > > and forgot how important and clear it was on good coding practice.
    > > I would like to link the wiki from our website as a service to our
    > > customers writing code for embedded systems applications.
    > >
    > > Let me know when it is published and I will be happy to have an
    > > item posted on that as well.

    >
    > Please do not top-post. Your answer belongs after (or intermixed
    > with) the quoted material to which you reply, after snipping all
    > irrelevant material. See the following links:
    >
    > --
    > <http://www.catb.org/~esr/faqs/smart-questions.html>
    > <http://www.caliburn.nl/topposting.html>
    > <http://www.netmeister.org/news/learn2quote.html>
    > <http://cfaj.freeshell.org/google/> (taming google)
    > <http://members.fortunecity.com/nnqweb/> (newusers)
    >
    > --
    > Posted via a free Usenet account from http://www.teranews.com
    Walter Banks, Mar 21, 2008
    #13
  14. Robert Seacord

    CBFalconer Guest

    Walter Banks wrote:
    >
    > Consider me told. I have seen your message I have read your links
    > save the off topic posts that everyone else has to endure. If
    > you must tell me do so privately. I will arrange for my filters to
    > ignore the messages and you will get the satisfaction of pointing
    > out a wrong and the rest of the newgroup will not endure endless
    > off topic threads whose subject line doesn't fit the message
    > of top vs bottom vs 4 line signature (yours is 9 btw).


    My attitude has been that you are flipping between areas with
    different standards, and forgetting to flip your attitude. I guess
    that is wrong. At any rate, top-posting is not really acceptable
    in c.l.c., and you would do us a favor by abandoning it.

    --
    [mail]: Chuck F (cbfalconer at maineline dot net)
    [page]: <http://cbfalconer.home.att.net>
    Try the download section.



    --
    Posted via a free Usenet account from http://www.teranews.com
    CBFalconer, Mar 21, 2008
    #14
  15. Robert Seacord

    Guest

    On Mar 20, 9:16 pm, jacob navia <> wrote:
    > wrote:
    > > Another error in the same page is that you clam that code which uses
    > > 'rsize_t' is compliant.

    >
    > This is explained in: https://..
    >
    > The type size_t generally covers the entire address space. [TR 24731-1]
    > introduces a new type rsize_t, defined to be size_t but explicitly used
    > to hold the size of a single object. In code that documents this
    > purpose by using the type rsize_t, the size of an object can be checked
    > to verify that it is no larger than RSIZE_MAX, the maximum size of a
    > normal single object, which provides additional input validation for
    > library functions. See [STR00-A. Use TR 24731 for remediation of
    > existing string manipulation code] for additional discussion of TR 24731-1.

    I do not know why and with what intent rsize_t was introduced, but it
    adds 0 to computer security.
    > Any variable that is used to represent the size of an object including
    > integer values used as sizes, indices, loop counters, and lengths should
    > be declared as rsize_t if available.

    Would you mind explaining the benifits? Because I see no benifit to
    changing all the code I've written so far to use something that adds
    nothing to my codes security and is not in standard C. (or any widely
    implemented standard, for that matter)
    >
    >
    > > Secure programming is beyond C's UB. Perfectly conforming programs can
    > > still be insecure, your pages seem to have neither. (conforming or
    > > secure programs).

    >
    > > Update: okay, in that *same* page (INT01-A) I found this code which
    > > claims to be secure & conforming

    >
    > >>> #define BUFF_SIZE 10
    > >>> int main(int argc, char *argv[]){
    > >>> rsize_t size;
    > >>> char buf[BUFF_SIZE];
    > >>> size = atoi(argv[1]); /* vipp: atoi in secure code? */
    > >>> /* vipp: where are your checks for argc? */
    > >>> if (size < BUFF_SIZE){
    > >>> strncpy(buf, argv[2], size); /* vipp: ka-boom */
    > >>> buf[size] = '\0';
    > >>> }
    > >>> }

    >
    > This is bogus. The code is trying to explain one specific problem, i.e.
    > that signed int comparisons with some constant assume that the integer
    > is greater than zero implicitely. To avoid this, rsize_t is recommended.


    I would not complain about the errors if the link leaded to some
    personal web blog or usenet post clarifying the code is pseudo-secure.
    However the above link comes from CERT/CC, which according to
    wikipedia is a major coordination center and according to them, they
    improve security.
    I don't know what makes you think that errors in security documents &
    papers should be easily excused or ignored.
    If you look at securecoding.cert.org there is a link labeled "Top 10
    Secure Coding Practices", from which practice n10 is
    > 10. Adopt a secure coding standard. Develop and/or apply a secure coding standard for your target development language and platform.

    So, according to them, having a *secure* standard is importand, and I
    do agree at some degree.
    Moreover, this link was posted here, in clc (cross-posted actually;
    comp.lang.c comp.std.c) implying the OP seeks technical errors in his
    documents.
    In fact, mr Seacord (OP) even mentioned so in his post body & title.
    Given this, I don't think the OP would be disappointed with my reply.
    So, after what I said what had to be said,
    > Conclusion:
    >
    > I wasted 10 minutes to read your message. You have no comprehension
    > about what the code examples are intended to show, and you start
    > complaining about things that do not concern the example directly.

    would you like to elaborate?
    But before you do, consider this: I'm not part of any "clique" (nor I
    accuse anybody being a member of a clique) and I'm not trying to troll
    you (perhaps you believe that).
    It is my honest opinion that this security document is bad at it's
    current form.
    , Mar 21, 2008
    #15
  16. Robert Seacord

    santosh Guest

    jacob navia wrote:

    > Richard Heathfield wrote:


    >> If C99 were as widely implemented as C90, that wouldn't be a problem.
    >> But it isn't.

    >
    > There are several implementations. Gcc's implementation is almost
    > ready. They did not finish it because C has disappeared from
    > their objectives. GNU doesn't care about the language anymore.


    How can you say this when the recommended language in the GNU Coding
    Standards is C?

    > More or less the same with Microsoft, even if their interest on C
    > has picked up recently.


    Has it? I see no evidence for that.
    santosh, Mar 21, 2008
    #16
  17. Robert Seacord

    jacob navia Guest

    santosh wrote:
    > jacob navia wrote:
    >
    >> Richard Heathfield wrote:

    >
    >>> If C99 were as widely implemented as C90, that wouldn't be a problem.
    >>> But it isn't.

    >> There are several implementations. Gcc's implementation is almost
    >> ready. They did not finish it because C has disappeared from
    >> their objectives. GNU doesn't care about the language anymore.

    >
    > How can you say this when the recommended language in the GNU Coding
    > Standards is C?
    >


    Because even if they have since years one of the best
    implementations, they do not care enough to fix the
    very small problems their implementation has.

    I just do not understand that they do 95% of the work and then fail
    during *years* to improve anything. Their C99 pges has stayed
    the same for years.

    >> More or less the same with Microsoft, even if their interest on C
    >> has picked up recently.

    >
    > Has it? I see no evidence for that.
    >


    The recent blog entry by the Microsoft representative, and
    their recent TRs and proposals prove this. Thier proposition
    for the "secure" functions, even if they did not really
    change things is a step forward.


    --
    jacob navia
    jacob at jacob point remcomp point fr
    logiciels/informatique
    http://www.cs.virginia.edu/~lcc-win32
    jacob navia, Mar 21, 2008
    #17
  18. Robert Seacord

    santosh Guest

    jacob navia wrote:

    > santosh wrote:
    >> jacob navia wrote:
    >>
    >>> Richard Heathfield wrote:

    >>
    >>>> If C99 were as widely implemented as C90, that wouldn't be a
    >>>> problem. But it isn't.
    >>> There are several implementations. Gcc's implementation is almost
    >>> ready. They did not finish it because C has disappeared from
    >>> their objectives. GNU doesn't care about the language anymore.

    >>
    >> How can you say this when the recommended language in the GNU Coding
    >> Standards is C?
    >>

    >
    > Because even if they have since years one of the best
    > implementations, they do not care enough to fix the
    > very small problems their implementation has.
    >
    > I just do not understand that they do 95% of the work and then fail
    > during *years* to improve anything. Their C99 pges has stayed
    > the same for years.


    That's probably because the gcc developers consider those unimplemented
    features either not useful or problematic (like conflicting with
    similar gcc specific extensions).

    Here is a list of C99 features not fully implemented in mainline gcc:

    1. wide character library support in <wchar.h> and <wctype.h>
    (originally specified in AMD1).
    2.variable-length arrays.
    3.complex (and imaginary) support in <complex.h>.
    4. extended identifiers.
    5. library functions in <inttypes.h>.
    6. extended integer types in <stdint.h>.
    7. additional math library functions in <math.h>.
    8. treatment of error conditions by math library functions
    (math_errhandling)
    9. IEC 60559 (also known as IEC 559 or IEEE arithmetic) support.
    10. additional predefined macro names.
    11. standard pragmas.
    12. deprecate ungetc at the beginning of a binary file.

    Of these 5. 6. don't seem to be present on my version of gcc/glibc, as
    far as I can see.

    7. 10. 11. and 12. ought to be very easy to implement. I don't know why
    they are still unimplemented, though of course 7. and 12. belong to
    glibc rather than gcc proper.

    1., 8. and 9. should also I think, not be too difficult. I personally
    don't care much for 2., 3. and 4.

    All told, it *is* surprising that they would come so close to
    conformance, but then slow down to a crawl.

    >>> More or less the same with Microsoft, even if their interest on C
    >>> has picked up recently.

    >>
    >> Has it? I see no evidence for that.
    >>

    > The recent blog entry by the Microsoft representative, and
    > their recent TRs and proposals prove this. Thier proposition
    > for the "secure" functions, even if they did not really
    > change things is a step forward.


    They need to do more than blog. At least gcc has made a valiant attempt.
    Microsoft seem to treat C as a subset of C++ and only the superset
    worthy of consideration. That of course leaves C99 in a bad way.

    The hot thing these days is "managed" code and "managed" languages,
    something C probably can never be. MS recommend C++ even for drivers.

    BTW, have you considered submitting patches for one or more of the
    missing C99 features in gcc?
    santosh, Mar 21, 2008
    #18
  19. Robert Seacord

    Flash Gordon Guest

    jacob navia wrote, On 21/03/08 19:59:
    > santosh wrote:
    >> jacob navia wrote:
    >>
    >>> Richard Heathfield wrote:

    >>
    >>>> If C99 were as widely implemented as C90, that wouldn't be a problem.
    >>>> But it isn't.
    >>> There are several implementations. Gcc's implementation is almost
    >>> ready. They did not finish it because C has disappeared from
    >>> their objectives. GNU doesn't care about the language anymore.

    >>
    >> How can you say this when the recommended language in the GNU Coding
    >> Standards is C?

    >
    > Because even if they have since years one of the best
    > implementations, they do not care enough to fix the
    > very small problems their implementation has.
    >
    > I just do not understand that they do 95% of the work and then fail
    > during *years* to improve anything. Their C99 pges has stayed
    > the same for years.


    No it hasn't. At the very least one change between gcc 4.2 and gcc 4.3
    is that inline functions are no longer broken and gcc 4.3 was release
    March 5th this year. Of course, this is still *very* slow movement, but
    it is not the complete failure to improve anything you claim.

    You say you care yet you have not finished implementing C99 in your
    compiler yet. If you are going to claim that not completing C99 is a
    sign of lack of care then you had better finish your implementation of
    C99 rather than concentrating on things which are not part of C.

    >>> More or less the same with Microsoft, even if their interest on C
    >>> has picked up recently.

    >>
    >> Has it? I see no evidence for that.

    >
    > The recent blog entry by the Microsoft representative, and
    > their recent TRs and proposals prove this. Thier proposition
    > for the "secure" functions, even if they did not really
    > change things is a step forward.


    So MS are still saying they will not implement C99 because there is not
    demand unlike GNU who have at least implemented most of it yet MS are
    the ones interested in C?

    Also gcc have added one of the other extensions for one target which is
    of interest to some people, namely fixed point data types described in
    n1169.pdf as well as other extensions, so by your suggestion of
    extending the language being a sign of interest GNU is still interested.
    --
    Flash Gordon
    Flash Gordon, Mar 21, 2008
    #19
  20. jacob navia <> writes:
    > santosh wrote:
    >> jacob navia wrote:
    >>
    >>> Richard Heathfield wrote:

    >>
    >>>> If C99 were as widely implemented as C90, that wouldn't be a problem.
    >>>> But it isn't.
    >>> There are several implementations. Gcc's implementation is almost
    >>> ready. They did not finish it because C has disappeared from
    >>> their objectives. GNU doesn't care about the language anymore.

    >>
    >> How can you say this when the recommended language in the GNU Coding
    >> Standards is C?
    >>

    >
    > Because even if they have since years one of the best
    > implementations, they do not care enough to fix the
    > very small problems their implementation has.
    >
    > I just do not understand that they do 95% of the work and then fail
    > during *years* to improve anything. Their C99 pges has stayed
    > the same for years.

    [...]

    *You* complain about this?

    When is your own lcc-win going to be fully C99 compliant? So far, you
    seem to be spending most of your time inventing and implementing
    extensions rather than finishing work on the implementation of the
    core language. (That's not to minimize your apparently considerable
    efforts in implementing as much of C99 as you have.)

    --
    Keith Thompson (The_Other_Keith) <>
    Nokia
    "We must do something. This is something. Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
    Keith Thompson, Mar 21, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Robert Seacord

    CERT C Programming Language Secure Coding Standard

    Robert Seacord, Aug 31, 2006, in forum: C Programming
    Replies:
    7
    Views:
    338
    Bill Pursell
    Sep 18, 2006
  2. Robert Seacord

    CERT C Programming Language Secure Coding Standard

    Robert Seacord, Jul 31, 2007, in forum: C Programming
    Replies:
    16
    Views:
    539
    Eric Sosman
    Aug 3, 2007
  3. rCs
    Replies:
    0
    Views:
    309
  4. rCs
    Replies:
    12
    Views:
    1,278
    Abu Yahya
    Jun 8, 2011
  5. David Chan via .NET 247
    Replies:
    1
    Views:
    333
    Dominick Baier [DevelopMentor]
    Jun 2, 2005
Loading...

Share This Page