Draft Secure C

Discussion in 'C Programming' started by Jack, Jan 12, 2007.

  1. Jack

    Jack Guest

    Jack, Jan 12, 2007
    #1
    1. Advertising

  2. Robert Gamble, Jan 12, 2007
    #2
    1. Advertising

  3. 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*?

    --
    Richard Heathfield
    "Usenet is a strange place" - dmr 29/7/1999
    http://www.cpax.org.uk
    email: rjh at the above domain, - www.
     
    Richard Heathfield, Jan 12, 2007
    #3
  4. 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. 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. TR 24731 qualifies for at least
    "special interest" and bloat.

    Robert Gamble
     
    Robert Gamble, Jan 13, 2007
    #4
  5. Jack

    CBFalconer Guest

    CBFalconer, Jan 13, 2007
    #5
  6. Jack

    jacob navia Guest

    Jack a écrit :
    > 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?
    > Is this useful? Will it make it to the next standard?
    >
    >
    >


    The lcc-win32 compiler system implements more than
    50% of that proposal. Only the wide character stuff
    remains to be implemented.

    Even it is not a solution to the bugs in the language,
    it is a big step forward. I have discussed several
    of the questions concerned in that proposal and in other
    related ones in this group (where it was received by
    the usual remarks of the "regulars" group) and in comp.std.c

    Specifically the proposal is weak concerning the solution
    for the zero terminated strings problems. It gives some extra
    security without eliminating the problem at the root.

    The problem is a bad data structure, and that is the
    error that should be corrected.

    jacob

    ---
    lcc-win32: a compiler system for windows
    www.cs.virginia.edu/~lcc-win32
     
    jacob navia, Jan 13, 2007
    #6
  7. Jack

    Guest

    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/
     
    , Jan 13, 2007
    #7
  8. Jack

    jacob navia Guest

    a écrit :
    > 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.
    >


    Can you specify?
     
    jacob navia, Jan 13, 2007
    #8
  9. jacob navia <> writes:
    [...]
    > Specifically the proposal is weak concerning the solution
    > for the zero terminated strings problems. It gives some extra
    > security without eliminating the problem at the root.
    >
    > The problem is a bad data structure, and that is the
    > error that should be corrected.


    Zero-terminated strings are not themselves a problem. They have both
    advantages and disadvantages. And it's not possible to eliminate them
    entirely from the C language, at least not without breaking existing
    code. (Requiring *any* source-level modification to make a program
    work under a new standard constitutes "breaking" existing code.)

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Jan 13, 2007
    #9
  10. Jack

    jacob navia Guest

    Keith Thompson a écrit :
    > jacob navia <> writes:
    > [...]
    >
    >>Specifically the proposal is weak concerning the solution
    >>for the zero terminated strings problems. It gives some extra
    >>security without eliminating the problem at the root.
    >>
    >>The problem is a bad data structure, and that is the
    >>error that should be corrected.

    >
    >
    > Zero-terminated strings are not themselves a problem. They have both
    > advantages and disadvantages. And it's not possible to eliminate them
    > entirely from the C language, at least not without breaking existing
    > code. (Requiring *any* source-level modification to make a program
    > work under a new standard constitutes "breaking" existing code.)
    >

    Nobody wants to eliminate them in one
    sweep. But an alternative could exist, that makes
    their usage obsolete. Then, after 10-20 years
    they are phased out.

    That's all
     
    jacob navia, Jan 13, 2007
    #10
  11. jacob navia <> writes:
    > Keith Thompson a écrit :
    >> jacob navia <> writes:
    >> [...]
    >>
    >>>Specifically the proposal is weak concerning the solution
    >>>for the zero terminated strings problems. It gives some extra
    >>>security without eliminating the problem at the root.
    >>>
    >>>The problem is a bad data structure, and that is the
    >>>error that should be corrected.

    >> Zero-terminated strings are not themselves a problem. They have both
    >> advantages and disadvantages. And it's not possible to eliminate them
    >> entirely from the C language, at least not without breaking existing
    >> code. (Requiring *any* source-level modification to make a program
    >> work under a new standard constitutes "breaking" existing code.)
    >>

    > Nobody wants to eliminate them in one
    > sweep. But an alternative could exist, that makes
    > their usage obsolete. Then, after 10-20 years
    > they are phased out.
    >
    > That's all


    And we lose any *advantages* that zero-terminated strings might have
    over counted strings.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Jan 13, 2007
    #11
  12. Jack

    Guest

    jacob navia wrote:
    > a écrit :
    > > 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.

    >
    > Can you specify?


    1) A better mapping to functionality commonly available in hardware.
    I.e., high-word or widening multiply. Bit scan operations (i.e., fast
    lg2, and scan for lowest.). Bit count. Endian swap. etc. Just look
    through the instruction sets of the popular CPUs and see which useful
    instructions are practically accessible through translation of C source
    and what is not. Then add library functions that perform those and
    allow the compiler vendor to support them however they wish. In this
    way the most optimal paths for a given piece of hardware will be
    available without resorting to non-portable inline assembly code. (And
    for those platforms that do not support each function, each function
    can be still be emulated which is equivalent to how such functionality
    is portably delivered today.)

    Just look through GMP or any similar multi-precision library. Yes it
    has a portable pure C back-end, but it is utter nonsense and is only
    invoked on compilers people have never heard of. But on those
    compilers it is *AT LEAST* 4 times slower than the likely potential for
    that hardware precisely because the language has no access to the
    fastest, most functional instructions that are commonly available on
    most hardware.

    2) Better control flow functionality: Coroutines and alloca(). The
    variable length array nonsense in C99 probably seemed like a good
    cleaner substitute for alloca() at the time, but gcc has clearly shown
    that its actually *harded* to implement that portably in at least their
    compiler.

    The whole setjmp, longjmp nonsense is precisely that. Personally I
    have never gotten it to work correctly, and I have a hard time
    approaching debugging of it -- I have always just found a way around
    using them instead. However, it turns out that coroutines are fairly
    straight forward to implement in assembly. And they incurr very little
    overhead. It requires some method of allocating a new "call stack".
    Although this sounds grossly exposing of platform details, if it is
    abstracted correctly, it actually is a big benefit. Currently a
    program itself within its source code cannot assert a requirement for
    minimum of stack availability. So programs that use deep recursion can
    crash easily. Besides that, coroutines represent truly new
    functionality in the language that is just absolutely not duplicatable
    by other means that can be considered scalable.

    3) Better heap functionality. The only access we have to the heap is
    through malloc/realloc/calloc/free. Its just not enough at all. The
    thing is, even the best implementations of those functions put a best
    amortized cost of a scalable implementation at around 50+ clocks per
    allocation. That means memory allocation is something that you
    necessarily try to push out of your inner loops. That means that
    throwing in more functionality and more overhead into those calls will
    not affect real world performance of applications that care about
    performance, since such call will not be sitting in inner loops at all.

    Now you can see from here in CLC itself, that there is a great need for
    heaps with built-in debugging help. Simple functions that tell you the
    total amount of allocated heap, or the size of a given allocation. C
    is not a language that can implement garbage collection easily, but it
    is very often the case that you can implement very close stand-ins that
    achieve the same level of leak safety. In particular you can implement
    seperate heaps, and include a "freeall()" function that will tear down
    an entire heap at once rather than performing individual frees -- which
    is often a lot of meaningless expense.

    Another useful thing to have is an isFromAllocatedMemory() function.
    The idea would be that the function would be well defined for certain
    void * pointers that were from static memory, auto-memory, a pointer
    allocated from heap memory and NULL. In this way you could determine
    whether or not a pointer came from the heap. In practice, this would
    be used primarily for debugging, but it could be used for functions
    that perform "automatic freeing" of structures passed to it when they
    are done with it, but *NOT* perform a free() if the structure passed to
    it came from static memory.

    4) A better preprocessor. Basically you want to be able to directly
    compete with LISP's lambda functionality, and just make automatic code
    generation more plausible in C. To be fully general, I would recommend
    modelling it after the language LUA (since its such a small language,
    but fully general) in terms of functionality. This kind of thing would
    greatly assist things like generic programming, but also provide ways
    for programmers to perform certain optimization techniques like
    "constant propogation" with relative ease.

    5) A universal 64bit time standard. Dave Tribble has posted his idea
    and library that explains what he after. The point is to create a
    universal time standard that is guaranteed to not barf in 2038 and that
    lets you correctly calculate time differences in a universal way,
    without being tied to the current local time (without daylight savings
    messing you up). I have not looked too deeply, but obviously such a
    standard would need also to include accurrate "sub-second" real-time
    timer functionality which is currently not available (clock() delivers
    processor tick time on UNIX systems, which is a different kind of
    animal.)

    The real point behind this list of features, is that they represent
    true enhancements to the C language. They are enhancements that really
    put the question to other languages like Java, Python, etc. Combined,
    this set of features would enhance the performance, and rewiden the gap
    between C and Java (or C#) for example, in ways that those two
    languages could not easily catch up. These features would push the
    frontiers of C precisely where other languages do not dare tread, or
    else already have another approach they are locked into.

    Today I can simply say to you, that if I want to use coroutines, I
    cannot use the C language and am better off going to another language.
    If I want multiprecision mathematics, I know that Python will deliver
    it to me, and that I cannot really get a good C implementation unless
    it is GMP (which is not thread-safe, BTW) or non-portable hand coded
    assembly language. If I want better heap control, then I roll my own
    non-portable solution, and go ahead and violate ANSI-strictness by
    overriding malloc/free/realloc/calloc. On occasion I do write
    auto-code generators -- but these days, I do it in Python, not the C
    pre-processor or even C. And of course, I still do the occasional
    in-line assembly code where I just don't otherwise have access to
    certain instructions.

    Strings, I don't care as much about, of course, because I have written
    a portable library that anyone can use that completely solves the
    problems using todays C compilers. So enhancements to C's string
    functions at the standards level is actually completely useless to me.
    It just goes to show how misguided that ANSI C committee is that they
    are entertaining nonsense like TR 24731, which is both bad (or at best
    benign), and not really necessary at the standards level.

    --
    Paul Hsieh
    http://www.pobox.com/~qed/
    http://bstring.sf.net/
     
    , Jan 14, 2007
    #12
  13. Jack

    Guest

    Keith Thompson wrote:
    > jacob navia <> writes:
    > > Keith Thompson a écrit :
    > >> jacob navia <> writes:
    > >> [...]
    > >>>Specifically the proposal is weak concerning the solution
    > >>>for the zero terminated strings problems. It gives some extra
    > >>>security without eliminating the problem at the root.
    > >>>
    > >>>The problem is a bad data structure, and that is the
    > >>>error that should be corrected.
    > >> Zero-terminated strings are not themselves a problem. They have both
    > >> advantages and disadvantages. And it's not possible to eliminate them
    > >> entirely from the C language, at least not without breaking existing
    > >> code. (Requiring *any* source-level modification to make a program
    > >> work under a new standard constitutes "breaking" existing code.)
    > >>

    > > Nobody wants to eliminate them in one
    > > sweep. But an alternative could exist, that makes
    > > their usage obsolete. Then, after 10-20 years
    > > they are phased out.
    > >
    > > That's all

    >
    > And we lose any *advantages* that zero-terminated strings might have
    > over counted strings.


    You can, of course, come up with a single example of such an
    "advantage" (that applies to the 10-20 year time frame Jacob was
    talking about)?

    --
    Paul Hsieh
    http://www.pobox.com/~qed/
    http://bstring.sf.net/
     
    , Jan 14, 2007
    #13
  14. In article <>,
    <> wrote:
    >jacob navia wrote:
    >> a =E9crit :
    >> > 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.


    >> Can you specify?

    >
    >1) A better mapping to functionality commonly available in hardware.
    >I=2Ee., high-word or widening multiply. Bit scan operations (i.e., fast
    >lg2, and scan for lowest.). Bit count. Endian swap. etc.


    >2) Better control flow functionality: Coroutines and alloca(). The


    >3) Better heap functionality.


    >The real point behind this list of features, is that they represent
    >true enhancements to the C language.


    In 25 years of C programming, I have rarely needed any of the
    functionality you list. Memory leak analysis sometimes, but only
    one of the several extensions to heap functionality you propose would
    make any difference to me (and that only on the odd occasion.)

    Endian swap I have only needed to the extent provided by Unix's
    ntohl() and htonl() -- i.e., in the context of network programming
    in which such routines would definitely be available as part of the
    network stack; the implementation details have been irrelevant to me.
    I have needed to convert file format byte orders, but such conversions
    are inherently non-portable and do not necessarily represent
    conversions from any actual hardware; the ability to nail down the
    order of bitfields would sometimes be a convenience, but taking the
    appropriate adjustments at runtime has never ever been a factor that
    affected execution time measurably.


    In short, it appears to me that your view of what "the C language is
    crying out for" is very heavily coloured by the -kind- of work that
    you do. There was *nothing* in your list that had me nodding and
    saying, "Me too!". Hence I have strong doubts that the C language is
    actually "crying out for" those features, and I have a definite
    suspicion that implementing the features you suggest would push
    C even more towards the "portable assembler" status -- at a time in
    computing when assembler has, to -most- people, become nearly irrelevant.

    Now, maybe what the embedded programming industry needs is a really
    first rate "portable assembler" so that developers can write code
    usable on anything from GPUs to cell phones to toasters to "hyperthreaded"
    PCs.... but as best I understand, programming history is littered with
    the carcasses of programming languages that attempted to be
    provide portable high-level interfaces to hardware. And I can't say
    I've ever seen -any- demand for ADA outside of the US DoD...

    There is a growing gap between "implementors" (responsible for the
    nitty gritty of providing funcitonality on particular hardware),
    and "programmers" (who don't necessarily care what happens under the
    hood). The programmers are in the growing majority; catering to
    implementors is going to have about the same long-term effect as
    catering to DBase 3 programmers: useful to some, yes, but C would
    pretty much drop out of general consciousness as a general purpose
    language.
    --
    "It is important to remember that when it comes to law, computers
    never make copies, only human beings make copies. Computers are given
    commands, not permission. Only people can be given permission."
    -- Brad Templeton
     
    Walter Roberson, Jan 14, 2007
    #14
  15. Jack

    santosh Guest

    Walter Roberson wrote:
    > In article <>,
    > <> wrote:
    > >jacob navia wrote:
    > >> a =E9crit :
    > >> > 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.

    >
    > >> Can you specify?

    > >
    > >1) A better mapping to functionality commonly available in hardware.
    > >I=2Ee., high-word or widening multiply. Bit scan operations (i.e., fast
    > >lg2, and scan for lowest.). Bit count. Endian swap. etc.

    >
    > >2) Better control flow functionality: Coroutines and alloca(). The

    >
    > >3) Better heap functionality.

    >
    > >The real point behind this list of features, is that they represent
    > >true enhancements to the C language.

    >
    > In 25 years of C programming, I have rarely needed any of the
    > functionality you list. Memory leak analysis sometimes, but only
    > one of the several extensions to heap functionality you propose would
    > make any difference to me (and that only on the odd occasion.)
    >
    > Endian swap I have only needed to the extent provided by Unix's
    > ntohl() and htonl() -- i.e., in the context of network programming
    > in which such routines would definitely be available as part of the
    > network stack; the implementation details have been irrelevant to me.
    > I have needed to convert file format byte orders, but such conversions
    > are inherently non-portable and do not necessarily represent
    > conversions from any actual hardware; the ability to nail down the
    > order of bitfields would sometimes be a convenience, but taking the
    > appropriate adjustments at runtime has never ever been a factor that
    > affected execution time measurably.
    >
    >
    > In short, it appears to me that your view of what "the C language is
    > crying out for" is very heavily coloured by the -kind- of work that
    > you do. There was *nothing* in your list that had me nodding and
    > saying, "Me too!". Hence I have strong doubts that the C language is
    > actually "crying out for" those features, and I have a definite
    > suspicion that implementing the features you suggest would push
    > C even more towards the "portable assembler" status -- at a time in
    > computing when assembler has, to -most- people, become nearly irrelevant.


    Isn't it precisely because of C's rise that assembler was severely
    sidelined? Wouldn't adding more functionality to C take it away from
    assembler rather than towards it?

    > Now, maybe what the embedded programming industry needs is a really
    > first rate "portable assembler" so that developers can write code
    > usable on anything from GPUs to cell phones to toasters to "hyperthreaded"
    > PCs.... but as best I understand, programming history is littered with
    > the carcasses of programming languages that attempted to be
    > provide portable high-level interfaces to hardware. And I can't say
    > I've ever seen -any- demand for ADA outside of the US DoD...


    By the time Ada matured C/C++ had developed enough momentum to ensure
    that the former would not be widely considered. As I see it, Java was
    the first language to break the stranglehold of C and it's brother.

    > There is a growing gap between "implementors" (responsible for the
    > nitty gritty of providing funcitonality on particular hardware),
    > and "programmers" (who don't necessarily care what happens under the
    > hood). The programmers are in the growing majority; catering to
    > implementors is going to have about the same long-term effect as
    > catering to DBase 3 programmers: useful to some, yes, but C would
    > pretty much drop out of general consciousness as a general purpose
    > language.


    IMHO, C has already nearly lost out on the applications development
    front, particularly on PCs. It seems that it's major use now and in the
    future would be in the implementation space. So additions to the
    language that make it more relevant for that area might not be so bad
    an idea.
     
    santosh, Jan 14, 2007
    #15
  16. Jack

    Guest

    Walter Roberson wrote:
    > <> wrote:
    > >jacob navia wrote:
    > >> a =E9crit :
    > >> > 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.

    >
    > >> Can you specify?

    > >
    > >1) A better mapping to functionality commonly available in hardware.
    > >I=2Ee., high-word or widening multiply. Bit scan operations (i.e., fast
    > >lg2, and scan for lowest.). Bit count. Endian swap. etc.

    >
    > >2) Better control flow functionality: Coroutines and alloca(). The

    >
    > >3) Better heap functionality.

    >
    > >The real point behind this list of features, is that they represent
    > >true enhancements to the C language.

    >
    > In 25 years of C programming, I have rarely needed any of the
    > functionality you list.


    I noticed how you didn't say never. So when you *have* needed some of
    that functionality, what did you do about it? I would like to point
    out that most of the entire C library is completely useless to me as
    well. So I don't know what the point of this comment is.

    > [...] Memory leak analysis sometimes, but only
    > one of the several extensions to heap functionality you propose would
    > make any difference to me (and that only on the odd occasion.)


    So your argument then, is that you don't think there should be memory
    leak assistance, because the other proposals I made are not something
    you would be interested in?

    > Endian swap I have only needed to the extent provided by Unix's
    > ntohl() and htonl() -- i.e., in the context of network programming
    > in which such routines would definitely be available as part of the
    > network stack; the implementation details have been irrelevant to me.


    Okay ... So here is another one that you would use, but only if they
    were tied to Unix and named "nothl" and "htonl"? Are you saying these
    are only possibly useful to Unix and therefore must not be available to
    other platforms in a portable way?

    > I have needed to convert file format byte orders, but such conversions
    > are inherently non-portable and do not necessarily represent
    > conversions from any actual hardware; the ability to nail down the
    > order of bitfields would sometimes be a convenience, but taking the
    > appropriate adjustments at runtime has never ever been a factor that
    > affected execution time measurably.
    >
    > In short, it appears to me that your view of what "the C language is
    > crying out for" is very heavily coloured by the -kind- of work that
    > you do.


    Ok, but your idea that these are unimportant to you (even though,
    apparently some are) is clearly coloring your response here. So I
    don't see the value of your argument. BTW, what do you know about the
    kind of work that I do?

    My ideas come from looking at other programming languages, and from
    looking at real world applications:

    Coroutines come from the fact that Lua has them, Python has something
    similar but less general (generators) and they are very useful for
    web-browsers (yeilding on socket blocks to allow a single tasking
    application to efficiently download a web page) and chess engines (just
    the way the jumble of loops for move generation intertwines with the
    alpha-beta algorithm can be drastically simplified with coroutines).

    Alloca(), and better heap management is actually a reaction to garbage
    collection. Garbage collection makes memory management in other
    languages a complete non-issue. Now, C cannot easily implement GC, and
    I don't recommend this. However, C has to justify its strategy as an
    alternative. All the mechanisms I recommend would enhance the
    functionality of C in ways that make its weaknesses versus GC less
    obvious (with leak detection assistance, GC's leak-lessness is less of
    an advantage, of course; with isFromHeap(), double-free becomes less of
    a problem.) C's memory management strategy is better for realtime and
    precise memory handling. Since it can't be exactly the same as GC, is
    has to be something else -- it might as well be the very best possible
    instance of its alternative strategy.

    The better preprocessor clearly is aimed at Lisp's Lambda and just
    generally more powerful macro programming. However, its purpose is
    also as a good stand-in for generics/templates. It can be used to
    automatically unroll a massive number of loops with a single source
    rendering.

    > [...] There was *nothing* in your list that had me nodding and
    > saying, "Me too!". Hence I have strong doubts that the C language is
    > actually "crying out for" those features, and I have a definite
    > suspicion that implementing the features you suggest would push
    > C even more towards the "portable assembler" status -- at a time in
    > computing when assembler has, to -most- people, become nearly irrelevant.


    Ok, so do you think the need for large number arithmetic has become
    irrelevant? The use of crypto is going *up* not down. I don't even
    know what this means. People have run away from assembly because
    people want to engange in sustainable programming and Moore's Law has
    enabled them to ignore performance for many applications (please note
    that crypto is not one of these applications -- you just do inline
    assembly or you can forget it). However, enabling such functionality
    in C, brings back the performance benefit to a language that, in
    theory, is at least partially scalable -- if not, then C++, which is
    more seriously scalable, can at least inherit the features.

    > Now, maybe what the embedded programming industry needs is a really
    > first rate "portable assembler" so that developers can write code
    > usable on anything from GPUs to cell phones to toasters to "hyperthreaded"
    > PCs.... but as best I understand, programming history is littered with
    > the carcasses of programming languages that attempted to be
    > provide portable high-level interfaces to hardware. And I can't say
    > I've ever seen -any- demand for ADA outside of the US DoD...


    What in the holy hell are you talking about? Ada is just a more
    functional variant of Pascal. How is Ada a portable assermbler? The
    features I suggest would also not be of any help to a GPUs or DSPs.

    > There is a growing gap between "implementors" (responsible for the
    > nitty gritty of providing funcitonality on particular hardware),
    > and "programmers" (who don't necessarily care what happens under the
    > hood). The programmers are in the growing majority; catering to
    > implementors is going to have about the same long-term effect as
    > catering to DBase 3 programmers: useful to some, yes, but C would
    > pretty much drop out of general consciousness as a general purpose
    > language.


    You are saying that adding enhancements to C are not a good idea,
    because adding them to C++ would be better?!?! Hint: If you add them
    to C, C++ *will* pick them up. Sorry, but I find your entire response
    completely vacuous.

    --
    Paul Hsieh
    http://www.pobox.com/~qed/
    http://bstring.sf.net/
     
    , Jan 14, 2007
    #16
  17. Jack

    jacob navia Guest

    Walter Roberson a écrit :
    > In article <>,
    > <> wrote:
    >
    >>jacob navia wrote:
    >>
    >>> a =E9crit :
    >>>
    >>>>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.

    >
    >
    >>>Can you specify?

    >>
    >>1) A better mapping to functionality commonly available in hardware.
    >>I=2Ee., high-word or widening multiply. Bit scan operations (i.e., fast
    >>lg2, and scan for lowest.). Bit count. Endian swap. etc.

    >
    >
    >>2) Better control flow functionality: Coroutines and alloca(). The

    >
    >
    >>3) Better heap functionality.

    >
    >
    >>The real point behind this list of features, is that they represent
    >>true enhancements to the C language.

    >
    >
    > In 25 years of C programming, I have rarely needed any of the
    > functionality you list. Memory leak analysis sometimes, but only
    > one of the several extensions to heap functionality you propose would
    > make any difference to me (and that only on the odd occasion.)
    >



    Yes, I have seen that argument a lot of times.

    "I never needed memory leak detectors"
    "Only on odd accasion I did use them"

    Yes. Everybody here is a genius programmers, looking at this
    messages.

    BUGS?

    ERRORS?

    Defensive programming?

    That is for wimps...

    > Endian swap I have only needed to the extent provided by Unix's
    > ntohl() and htonl() -- i.e., in the context of network programming
    > in which such routines would definitely be available as part of the
    > network stack; the implementation details have been irrelevant to me.
    > I have needed to convert file format byte orders, but such conversions
    > are inherently non-portable and do not necessarily represent
    > conversions from any actual hardware; the ability to nail down the
    > order of bitfields would sometimes be a convenience, but taking the
    > appropriate adjustments at runtime has never ever been a factor that
    > affected execution time measurably.
    >
    >
    > In short, it appears to me that your view of what "the C language is
    > crying out for" is very heavily coloured by the -kind- of work that
    > you do. There was *nothing* in your list that had me nodding and
    > saying, "Me too!". Hence I have strong doubts that the C language is
    > actually "crying out for" those features, and I have a definite
    > suspicion that implementing the features you suggest would push
    > C even more towards the "portable assembler" status -- at a time in
    > computing when assembler has, to -most- people, become nearly irrelevant.
    >


    You get that wrong. The situation now forces you to use non portable
    assembler constructs. Incoporating them into the language makes the
    need for including assembly less urgent...

    > Now, maybe what the embedded programming industry needs is a really
    > first rate "portable assembler" so that developers can write code
    > usable on anything from GPUs to cell phones to toasters to "hyperthreaded"
    > PCs.... but as best I understand, programming history is littered with
    > the carcasses of programming languages that attempted to be
    > provide portable high-level interfaces to hardware. And I can't say
    > I've ever seen -any- demand for ADA outside of the US DoD...
    >


    Ada is nothing like a "portable assembler"!!!! You are dreaming.

    > There is a growing gap between "implementors" (responsible for the
    > nitty gritty of providing funcitonality on particular hardware),
    > and "programmers" (who don't necessarily care what happens under the
    > hood). The programmers are in the growing majority; catering to
    > implementors is going to have about the same long-term effect as
    > catering to DBase 3 programmers: useful to some, yes, but C would
    > pretty much drop out of general consciousness as a general purpose
    > language.


    Incredible how much nonsense someone can say in just a few sentences.
    C users are implementors, since they implement algorithms and
    software...

    If you do not want to know what happens "under the hood" just use BASIC
    or VB, or C# for that matter.
     
    jacob navia, Jan 14, 2007
    #17
  18. writes:
    > Keith Thompson wrote:
    >> jacob navia <> writes:

    [...]
    >> > Nobody wants to eliminate them in one
    >> > sweep. But an alternative could exist, that makes
    >> > their usage obsolete. Then, after 10-20 years
    >> > they are phased out.
    >> >
    >> > That's all

    >>
    >> And we lose any *advantages* that zero-terminated strings might have
    >> over counted strings.

    >
    > You can, of course, come up with a single example of such an
    > "advantage" (that applies to the 10-20 year time frame Jacob was
    > talking about)?


    I don't know about a 10-20 year time frame, but consider this. If a
    program is going to scan a string anyway, there's not much benefit in
    storing its length separately. In a recent discussion here, somebody
    posted an example of such a program (a fairly small one). jacob
    claimed that a solution using memcpy() (which requires knowing the
    length in advance) was faster than an equivalent solution using
    strcpy() (which doesn't) -- but he only provided actual numbers for an
    x86 platform. I demonstrated that the strcpy() solution is actually
    faster on some other platforms.

    Now if you're doing a lot of processing that *does* require knowing
    the length in advance, then yes, counted strings are advantageous.
    But if you don't happen need it, then computing and storing it is
    useless overhead. I'm not arguing that C-style zero-terminated
    strings are superior to counted strings, merely that there is a
    tradeoff. I don't know which is better in general. jacob thinks he
    does know, and that zero-termainted strings are inherently a bug in
    the language.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
     
    Keith Thompson, Jan 14, 2007
    #18
  19. jacob navia said:

    > Walter Roberson a écrit :


    <snip>

    >> In 25 years of C programming, I have rarely needed any of the
    >> functionality you list. Memory leak analysis sometimes, but only
    >> one of the several extensions to heap functionality you propose would
    >> make any difference to me (and that only on the odd occasion.)
    >>

    >
    >
    > Yes, I have seen that argument a lot of times.
    >
    > "I never needed memory leak detectors"


    Who has said this?

    > "Only on odd accasion I did use them"


    Well, that may well be true for some people. Personally, I use a leak
    detector I wrote myself, which is why I don't need to use a third-party
    product such as valgrind.

    > Yes. Everybody here is a genius programmers, looking at this
    > messages.


    Nobody here has claimed this. But a memory leak is normally pretty easy to
    track down and fix.

    >
    > BUGS?
    >
    > ERRORS?
    >
    > Defensive programming?
    >
    > That is for wimps...


    No, defensive programming is a sound strategy, but it's not a binary state -
    defensive or not defensive. Rather, it's a matter of degree, and a good
    programmer will be able to decide for himself which parts of his program
    are vulnerable and need to be defended deeply, and which parts can be
    allowed to fly, without let or hindrance from *unnecessary* checking.

    <snip>

    > If you do not want to know what happens "under the hood" just use BASIC
    > or VB, or C# for that matter.


    Or C, where you very often get to choose whether you want, or do not want,
    to know what happens behind the scenes.

    --
    Richard Heathfield
    "Usenet is a strange place" - dmr 29/7/1999
    http://www.cpax.org.uk
    email: rjh at the above domain, - www.
     
    Richard Heathfield, Jan 14, 2007
    #19
  20. In article <45aa928b$0$27403$>,
    jacob navia <> wrote:
    >Walter Roberson a écrit :


    >> In 25 years of C programming, I have rarely needed any of the
    >> functionality you list. Memory leak analysis sometimes, but only
    >> one of the several extensions to heap functionality you propose would
    >> make any difference to me (and that only on the odd occasion.)



    >Yes, I have seen that argument a lot of times.


    >"I never needed memory leak detectors"
    >"Only on odd accasion I did use them"


    >Yes. Everybody here is a genius programmers, looking at this
    >messages.


    According to the RCS logs, the last time I worked on a program
    for which memory leak analysis was a significant factor, was
    11 years ago -- and the actual leak analysis was 12 1/2 years ago.

    I have programmed a far bit in C since that time, but the
    memory usage patterns became less and less relevant: if the program
    didn't run out of physical memory before termination, then
    any leaks didn't matter. And I have the discipline to be consistant
    in my memory usage, making leaks relatively improbable.

    Self-discipline in programming doesn't take a genius programmer,
    merely a stubborn one.
    --
    Prototypes are supertypes of their clones. -- maplesoft
     
    Walter Roberson, Jan 15, 2007
    #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. A.M
    Replies:
    5
    Views:
    5,471
    Teemu Keiski
    Jun 8, 2004
  2. Daniel Malcolm
    Replies:
    0
    Views:
    566
    Daniel Malcolm
    Jan 24, 2005
  3. zdrakec
    Replies:
    1
    Views:
    443
    zdrakec
    Jul 25, 2005
  4. Joe
    Replies:
    5
    Views:
    975
    Steven Cheng[MSFT]
    Dec 13, 2005
  5. Dinis Cruz
    Replies:
    0
    Views:
    222
    Dinis Cruz
    Oct 30, 2003
Loading...

Share This Page