Re: Designing a successor to C

Discussion in 'C Programming' started by Paul Hsieh, Jun 24, 2003.

  1. Paul Hsieh

    Paul Hsieh Guest

    Clint Olsen <> wrote:
    > I did a Google search on this and got quite a few hits - esp. a rather
    > large thread in '95. Having said that, has anyone even tried to rethink
    > 'portable assembly' and come up with another implementation? Does such an
    > idea even have merit?


    You mean like the Java Byte code or something?

    > Someone has already taken a stab at 'D', but I'm not sure that's the
    > direction I would take with a systems programming language. For example,
    > they chose to incorporate Han's Boehm's garbage collection system and made
    > it part of the language. While I'm not against garbage collection, I don't
    > know if I'd make it a requirement of the language.


    Lots of languages have garbage collection in them. In fact all the
    new ones certainly do. So there is presedence for this. Even if I
    agree with you, its kind of hard to argue against the mobs of
    programmers who don't want to or know how or when to call free()
    correctly.

    My counter proposal is to use region/context specific memory
    allocation. The purpose being to add a function like
    freeAll(regionHandle) to perform a mass free in one shot. I have used
    this technique and it can actually lead to both a performance
    improvement and obviously this can make your programmers much safer in
    many cases.

    > I don't necessarily want to rehash wish lists again, but I would like to
    > discuss design considerations that would contribute to a successor actually
    > being successful like the ability to interoperate with existing code (be
    > able to exploit the existing libc) etc.


    Well, perhaps you should start from a more basic point of view and ask
    some questions about C.

    1. What compelling features do other languages have that C doesn't?
    2. Where has C failed as a language?
    3. What features of languages should be there that aren't?
    4. What about the language *cannot* be changed?

    If you don't know how to answer the above, then listen to the
    following:

    http://stanford-online.stanford.edu/courses/ee380/020424-ee380-100.asx

    Here are some comments off the top of my head that have specifically
    to do with C:

    - One of the most striking differences between C and pretty much every
    other language out there is the ridiculous lack of safety. Security
    attacks based on flawed technology has been dominated by exploiting
    failures that can only exist in C or assembly language environments.

    - C contains no end of "surprised gotchas" in it. Half of the library
    has undefined behavior on parameters that are ordinarily legal by
    themselves but not legal in the context of calling that function. I
    just found out a few days ago that the va_list arguments to vsprintf,
    vprintf etc are not const -- and this is important(!) because
    compilers are free to and *do* modify the va_list argument as a result
    of calling these functions. Then there's that disgusting hack with
    the char arr[4]="abcd" thing that was just posted here. To actually
    use C properly you have to know a lot more of the standard than you
    would think. What you think should intuitively work often just
    doesn't.

    - C is actually quite slow! The distance between the results in C and
    a skilled assembly language programmer can still be quite large.
    Delluded C programmers may not believe this, but that's usually just
    an indication that such programmers are not skilled assembly language
    programmers. Fortran is still the language of choice for numerical
    programmers, and a lot of it is just the raw performance.

    - C is missing a rather *lot* of functionality that actually makes it
    technically inferior to other languages. Socket programming,
    threading, and even things like graphics and sound are standard
    functionality in other languages as part of their standard (and even
    portable while including such features!). But more concretely, C is
    missing stupid things like signed right shift, a rotate operator, any
    low-level lock primitives, bit counting/bit searching functions,
    double wide multiply instructions, carry capturing adds/subtracts,
    endian switching, addressable program labels etc. At least map to
    what is commonly available in the assembly languages for modern CPUs!

    - C's macro system doesn't integrate with the language at all. The
    language, first of, should have some kind of compile time type
    assertion mechanism that allows C macros to enforce type checking. In
    addition code blocks (not functions!) with return values would allow C
    macros be a useful mechanism for performing programmer enforced
    inlining that is more maintainable.

    - C's preprocessor is just extremely weak. Its weaker than other
    preprocessing systems like MASM's preprocessor, or m4. Why not add a
    simple interpretive programming model into the C pre-processor? It
    would make automatic code generation a lot simpler and portable. Why
    is this relevant or important? Think about the printf class of
    functions -- they are one of the classic security things to attack,
    and 99% of all format strings are inline constant strings. So why not
    just implement printf as just a sophisticated compile time macro? In
    conjunction with other safety features, it would become a completely
    safe way to implement things like s(n)printf.

    - C's libraries are too tied to their narrowly focussed to the rather
    specific and barebones functionality that they describe. For example,
    there is POSIX file management, and ANSI stream based FILE I/O. Why
    not just stick to the more low level file I/O mechanism (i.e., the
    POSIX one) and abstract the stream I/O as an abstract which maps to
    the posix like functions more *explicitely*.
    The file streaming functions are useful, but are tied solely to the
    concept of files. See how I did this for bsStream in
    http://bstring.sourceforge.net/

    And following a lot of the comments from Todd Proebsting above, I'll
    echo some of the things he has said for things not having specifically
    to do with C:

    - We need language specific support for debugging assistance. Saving
    entire state (as Todd suggests) is probably a bit much, but how about
    a well defined way of crawling up the stack? I mean why not? At
    least it would be a feature that you could point to and say "that's
    realistically impossible to do in assembly language". While Visual
    Debuggers are nice for developers, it doesn't help them deal with bugs
    that end users encounter in the field that the programmer cannot
    capture enough information about to reproduce the scenario in-house
    for herself. Why not have an error handler that can simply crawl the
    whole stack and save it in an error report file of some kind then fed
    back from the end user to the developer?

    - Why do languages not have libraries for specification driven context
    free language parsing mechanisms in run time? Flex/Yacc/Bison is
    nice, but they are strictly compile time code generators. Regex
    libraries exist, but 1) they are necessarily (theoretically and
    practically) weaker than CFLs, 2) they are not standardized -- there
    is the original Henry C. Specer thing, various grep/sed/awk
    implementations, the perl implementation with its extensions and one
    that I wrote myself :), 3) the whole parenthesis reference hack thingy
    is just sad.

    - Languages from this point forward *have* to have built-in
    multi-threading. I think that there is just no question on this
    issue.

    So what's good about C? Well, the syntax seems mostly fine. const
    and restrict are good ideas. Compile time inline declarations is a
    good idea. The widely deployed compilers available for all platforms
    is a good idea too -- you need some creativity in having this property
    in a way that isn't prohibitively expensive (by outputing either Java
    byte code or in fact C source, as the actual object code, for
    example.) The multi-module linking idea also pretty important.

    Well that's all for now. Dunno if this is destined to be off topic or
    not, but if people get annoyed, why not cross post it to
    comp.programming and let it continue there?

    --
    Paul Hsieh
    http://bstring.sourceforge.net/
    http://www.pobox.com/~qed/
     
    Paul Hsieh, Jun 24, 2003
    #1
    1. Advertising

  2. Paul Hsieh

    Kevin Easton Guest

    Paul Hsieh <> wrote:
    [...]
    > Here are some comments off the top of my head that have specifically
    > to do with C:
    >
    > - One of the most striking differences between C and pretty much every
    > other language out there is the ridiculous lack of safety. Security
    > attacks based on flawed technology has been dominated by exploiting
    > failures that can only exist in C or assembly language environments.


    This is actually a property of common C implementations, rather than of
    the language itself - which means it is in fact market-driven. The C
    standard doesn't say "if you access beyond the bounds of an array, it
    shall overwrite the function return address and cause arbitary code
    execution". It says "undefined behaviour", which allows plenty of room
    for a run-time exception just like in Java or Ada or whatever else.
    There are C implementations that do this - they're just not very
    popular, in which there is a lesson to be learned.

    - Kevin.
     
    Kevin Easton, Jun 25, 2003
    #2
    1. Advertising

  3. Paul Hsieh

    Randy Howard Guest

    In article <>,
    says...
    > Well, perhaps you should start from a more basic point of view and ask
    > some questions about C.
    >
    > 1. What compelling features do other languages have that C doesn't?
    > 2. Where has C failed as a language?
    > 3. What features of languages should be there that aren't?
    > 4. What about the language *cannot* be changed?
    >
    > If you don't know how to answer the above, then listen to the
    > following:
    >
    > http://stanford-online.stanford.edu/courses/ee380/020424-ee380-100.asx


    I want to thank you for posting this link. It was quite lengthy, so
    people might not make it all the way, and it's certainly not
    "favorable" towards C, but I found it to be extremely interesting.

    It definitely makes you think, and not everything you realize
    afterward is complimentary to those choosing to work predominantly
    in C.

    From a "Microsoft" aspect, it certainly was no surprise to see
    "The Innovator's Dilemma" quoted in a talk by an MS employee.
    I've even heard that employees carry a copy of this book into
    meetings to quote from it if need be. They're completely
    focused on "disruptive technology" from a cultural standpoint,
    and perhaps not always for the good.

    Nevertheless, the idea of a programming language that is more
    productive rather than focusing on "it's harder, but it's faster"
    as the reason to support C seems like it holds water at the
    application development level, although things like OS's and
    drivers may not go that route.

    If nothing else, I'm going to play with "Icon" a bit to see what
    the attraction is there. :)


    --
    Randy Howard
    remove the obvious bits from my address to reply.
     
    Randy Howard, Jun 25, 2003
    #3
  4. Paul Hsieh

    Chris Torek Guest

    (I have been meaning to write a more detailed response but have not
    had time; I will inject this point here now though, and maybe one
    more elsethread.)

    >> Paul Hsieh <> wrote:
    >>>- One of the most striking differences between C and pretty much every
    >>>other language out there is the ridiculous lack of safety. Security
    >>>attacks based on flawed technology has been dominated by exploiting
    >>>failures that can only exist in C or assembly language environments.


    Actually, these same kinds of "failings" exist in Fortran. (In
    fact, when I was in high school many years ago, we used this in
    the same way people use it now in C -- by loading assembly code
    into one array, and using out-of-bounds subscripts in a second
    array, we turned a harmless Fortran instruction [of the form "x =
    asm(1)"] into a call into our assembly code. While the IBM system
    on which this ran had an assembler, we were not given access to
    it, hence the subterfuge.) I believe they are in Fortran for much
    the same reasons as in C, the top two being "it is easier that way"
    and "the code runs faster if we do not bother to check".

    >Kevin Easton <> wrote:
    >>This is actually a property of common C implementations, rather than of
    >>the language itself - which means it is in fact market-driven. The C
    >>standard doesn't say "if you access beyond the bounds of an array, it
    >>shall overwrite the function return address and cause arbitary code
    >>execution". It says "undefined behaviour", which allows plenty of room
    >>for a run-time exception just like in Java or Ada or whatever else.


    In article <>
    Paul Hsieh <> writes:
    >But that completely misses the point!


    No, it is precisely the point.

    >First of all, in Java it *HAS* to throw a run-time exception,
    >otherwise its not Java (same with Ada.)


    Yes... and Java and Ada are not being used in so many places where
    C *is* being used. Why is it C that being used instead? (I know
    lots of possible answers, but not necessarily "the" answer -- or
    "the answers" if there is more than one. So this is not merely a
    rhetorical question, although it works as one. :) )

    >Secondly, just because there are hazards in the C language, doesn't
    >mean its there for performance reasons (gets comes to mind.)


    "Performance" can also refer to "rapid coding" (it takes a fraction
    of a minute longer to write an fgets-and-smash-newline routine, or
    suck one in from one's private library, and oh no! then you might
    be a millisecond late to market! -- which, it seems, sometimes
    really *is* fatal).

    >>There are C implementations that do this - they're just not very
    >>popular, in which there is a lesson to be learned.


    >The reason is obvious, C has sold itself as being a *fast* language,
    >and competition forces every vendors to pursue speed. ...


    Which is what Kevin Easton said. The sad fact is, it is much more
    important to get the wrong answer fast than it is to get the right
    answer slightly more slowly. (Of course, sometimes -- perhaps even
    usually -- we get the right answer fast, too.)

    In my opinion, this is not the way things *should* be, and as C
    creeps into more and more embedded software that runs on common
    devices (and sometimes even safety-critical devices), I believe it
    *will* change. As I see it, there are two ways in which it *can*
    change: either the industry as a whole cleans up its act and starts
    getting the right answer (at whatever speed) instead of the wrong
    answer "real fast"; or the lawyers step in and sue everyone into
    oblivion. I suspect the second is what will actually happen. "When"
    is not something I can answer, though.

    >Vendors try to achieve this by making absolutely no useful provisions
    >for all these undefined scenarios. As someone who has looked seriously at
    >performance for more than a decade now, many of these undefinednesses
    >don't help performance one iota.


    Some may indeed not help, but many kinds of definedness *would*
    actually *hurt*. In my part-time-life as a "compiler guy" I have
    seen some of what it takes to optimize array bounds checking, for
    instance. There are easy cases and hard cases -- and the hard
    cases are the ones that get you.

    >I.e., it is my belief that one can make slight modifications to the
    >language, and change the library to substantially reduce the minefield
    >of programming hazards that is inherent in the C language without
    >sacrificing any performance.


    If you believe it, implement it. Assuming it all works, will the
    market flock to you? That is Kevin Easton's question (or point,
    rather: that the market has not, yet, despite others' efforts).
    --
    In-Real-Life: Chris Torek, Wind River Systems (BSD engineering)
    Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
    email: forget about it http://67.40.109.61/torek/index.html (for the moment)
    Reading email is like searching for food in the garbage, thanks to spammers.
     
    Chris Torek, Jun 25, 2003
    #4
  5. Paul Hsieh

    Randy Howard Guest

    In article <>,
    says...
    > The common mantra I hear is that because of the nature of C, there is
    > no way to really make it both a safe and fast language anyway. I
    > think that's hogwash. The library in particular can make extra
    > efforts to implement safety features that insulate a substantial
    > amount of the most common problems.


    This lack of safety that is loved by some is being used as the
    primary reason to force migration to other languages in shops
    concerned about security and the whole class of smash the
    stack/buffer overflow attacks so common against C programs. It's
    so prevalent that even the pointy-haired managers know about
    the issue, which is unprecedented.

    Another example is the heated debates recently on the implementation
    (or lack thereof) of safety features in libclc. The end result
    (IMHO) being that it is optimized and structured for 20-30 people
    that hang out here, rather than being designed to be a useful,
    productive addition that a lot of people might feel safe with and
    derive value from. Yes, I exaggerate to make a point, but newbs
    could benefit greatly from am implementation of libclc that held
    your hand a little bit instead of the libc implementations where you
    get to run 200mph with your pants down while hoping no barbed wire
    fences are in your path.

    I admit my opinion is biased (who's isn't?), but once it became
    apparent that "do it the old, comfortable way", I.e. "crash
    because it's supposed to crash if you're stupid" or "it'll run
    too slow otherwise" opinions were going to be the rule, I lost
    interest in the concept of libclc being a general library for
    large scale distribution that would help a broader group of
    people out. Nothing against the very hard work of Bjørn,
    Hallvard, Jan and numerous others have done to contribute to
    it. If nothing else, there is a tremendous body of code
    growing that is well written. The work to take that and
    roll it into something with a bit more hand-holding for those
    that want it that way isn't a big deal anyway, but again
    defies common use once the code is forked.

    Short version: Library code designed for benchmarks and/or
    historical continuity is going to be useful to a much smaller
    group than code designed to be contributive to rapid, large-scale
    program development.

    > Programming languages like Java, et al, are getting a free lunch
    > because C is dramatically less safe than it needs to be.


    Not only that, but it's very time consuming to build a *large*
    application in pure ANSI C. It's great for "close to the metal"
    programming, especially when augmented with asm when needed.
    That's essentially the only place where it is still holding its
    own.

    It's not particularly good for writing any serious real world
    application code that needs to talk to a GUI, or the web, or ...
    It's in these areas that C is disappearing quickly. It'll
    probably always be around until all those that cut their teeth
    on C get buried, but it sure isn't the "one size fits all"
    language it was once purported to be.

    --
    Randy Howard
    remove the obvious bits from my address to reply.
     
    Randy Howard, Jun 26, 2003
    #5
  6. Paul Hsieh

    Ian Woods Guest

    Ian Woods <> wrote in
    news:Xns93A65D5B9F7Enewspubwuggyorg@217.32.252.50:

    > Even if the lawyers step in, they'll wind up haggling with the
    > lawyers. <Insert Ford Pento example here>.


    Actually, the lawyers haggling is a given. These lawyers would also be
    haggling with the accountants I mentioned early.

    <Insert "I am a chartered accountant" sketch here>

    Ian Woods
     
    Ian Woods, Jun 26, 2003
    #6
  7. Paul Hsieh

    Clint Olsen Guest

    In article <>,
    Arthur J. O'Dwyer wrote:
    >
    > True. I now see your point. However, since most of your other examples
    > of "things C doesn't have" looked very much like hardware to me (locks
    > and arithmetic shifts and so on), so I assumed you were talking about
    > bit-level shifting. If you want the effect of shifting all the value
    > bits to the [logical] right, then all you have to do is divide by 2 (for
    > positive 2's-complement numbers; I don't have the inclination to work out
    > the other 5 possibilities.)
    >
    > C's bitwise operators work on the bits of the object, not only on its
    > value bits (AIUI). If you want to do normal maths with integers, then
    > you don't use bitwise ops because they'll mess everything up.


    No, you do not have access to the padding bits in an integral type. That's
    precisely why you check ULONG_MAX.

    > Suppose ULONG_MAX is 2**32-1, represented internally as
    >
    > 0000-0000 0000-0000 0000-0000 0000-0001
    > ^^ ^
    > |bit 1 ... bit 31/sign bit
    > bit 0
    >
    > Then ULONG_MAX>>1 == 0. Maybe this is what you expected, but from your
    > terse description I don't think so.


    ULONG_MAX is required to be an "all 1's" representation. Also, we're
    talking unsigned types here, so I don't know why you're referring to a sign
    bit.

    > That will always give the correct number of bits. It won't care about
    > "value bits" or "padding bits" (or the "sign bit"), but that's okay, since
    > how would you define, e.g., "rotate left by 1" for the sign bit?


    Again, there is no sign bit in an unsigned type. Rotate left by 1 means
    the MSB now becomes the LSB.

    > If you know what sorts of objects you're going to have inside the block,
    > you can use the "union" trick when malloc'ing space for the block:
    >
    > typedef union {
    > void *vp;
    > long double llf;
    > void (*fp)();
    > } Everything;
    >
    >
    > I don't follow you here, sorry.


    The problem with the union technique is that you have to know ahead of time
    the potentially strictest types are for alignment, and this is never
    assured. However, you can use this:

    #define ALIGN(t) offsetof(struct { char _; t x; }, x)

    It requires you to specify a type as an argument since there isn't a
    'typeof' in ANSI C, but this isn't all that much different than using STL
    containers in C++.

    >> >> extern void move(float coord[2]);
    >> >
    >> > Does C99 change the semantics of [] in function parameters?
    >> > Is this prototype any different from void move(float *) ?

    >
    > It's legal C89, but pointless. That's why I wondered.


    Not exactly useless. That information could be used by the compiler to do
    bounds checking in this case where as the pointer version could not.

    >> > What is sizeof ((char[2]){'a','b'}) ?
    >> > What is sizeof ((int[2]){'a','b'}) ?
    >> > What would be sizeof ({'a','b'}) ?

    >>
    >> C already has type promotion in expressions anyway, so I don't see how this
    >> is such a stretch. 'a' and 'b' can be promoted as required.

    >
    > How is "required" in the third example? Unless you're proposing a
    > radically different type system, in which arrays don't decay to pointers
    > in value contexts, or something, I think I can give similar examples till
    > the cows come home.


    Ahh, I see what you mean. I'm saying that in the cases where it's used as
    an argument to a function or an assignment, it's clear what the { 'a', 'b' }
    argument means. So in your examples, only the third is ambiguous.

    -Clint
     
    Clint Olsen, Jun 26, 2003
    #7
  8. Paul Hsieh

    Morris Dovey Guest

    Paul Hsieh wrote:

    <snip>

    > Its this whole "undefined behavior" thing that's the problem.
    > Secondly, just because there are hazards in the C language, doesn't
    > mean its there for performance reasons (gets comes to mind.)


    I'm inclined to agree - let's not forget that there are a lot of
    people of the type who would make cutting tools safer by removing
    all sharp edges.

    C remains a /useful/ language. The challenge is to improve the
    standard (define the undefined) without sacrificing /any/ of the
    utility; and without kow-towing to hardware/software/compiler
    vendors. It's not only the retention of the current form of
    gets(), its also "lesser" issues like a standard representation
    for time and the ability to perform reliable file seeks.

    There's nothing to stop you from making "small modifications to
    the C library" on your own so long as those modifications are in
    strict conformance with the standard - or were you really saying
    that small changes to the standard are needed?

    As a practical matter, I don't think that a really useful systems
    programming language /can/ be safe in the hands of an unsafe
    programmer.

    --
    Morris Dovey
    West Des Moines, Iowa USA
    C links at http://www.iedu.com/c
     
    Morris Dovey, Jun 26, 2003
    #8
  9. On Thu, 26 Jun 2003, Clint Olsen wrote:
    >
    > Arthur J. O'Dwyer wrote:
    > >
    > > True. I now see your point. However, since most of your other examples
    > > of "things C doesn't have" looked very much like hardware to me (locks
    > > and arithmetic shifts and so on), so I assumed you were talking about
    > > bit-level shifting. If you want the effect of shifting all the value
    > > bits to the [logical] right, then all you have to do is divide by 2 (for
    > > positive 2's-complement numbers; I don't have the inclination to work out
    > > the other 5 possibilities.)
    > >
    > > C's bitwise operators work on the bits of the object, not only on its
    > > value bits (AIUI). If you want to do normal maths with integers, then
    > > you don't use bitwise ops because they'll mess everything up.


    Ah. I see from N869 that the << and >> operators are defined to work as
    E1 << E2 == E1 * 2**E2 and E1 >> E2 = E1 / 2**E2 for all types where this
    makes sense. I had never found that passage before. Oops.

    My point still stands with regard to the bitwise & | ^ operators, AFAICT,
    but that's irrelevant. Sorry.


    > > Suppose ULONG_MAX is 2**32-1, represented internally as
    > >
    > > 0000-0000 0000-0000 0000-0000 0000-0001
    > >
    > > Then ULONG_MAX>>1 == 0.

    >
    > ULONG_MAX is required to be an "all 1's" representation

    [except for possible padding bits].

    Sorry, you're right. The physical layout of bits doesn't matter to
    the shift operators. In a case where the bits were stored LSB..MSB,
    E1 >> 1 would have to shift bits to the "left" in hardware. (!)

    [snip]
    > Rotate left by 1 means the MSB now becomes the LSB.


    In which case, the #define you posted earlier seems to cover it.
    Unless it used the usual sizeof()*CHAR_BIT thing, in which case
    how about

    [untested code]
    #define ROL(x) ((x)<<1) | ( ((x) & ~(ULONG_MAX>>1))? 1: 0 )
    etc.,
    which isn't exactly a hardware op but will evaluate quite a bit at compile
    time anyway.

    > > If you know what sorts of objects you're going to have inside the block,
    > > you can use the "union" trick when malloc'ing space for the block:
    > >
    > > typedef union {
    > > void *vp;
    > > long double llf;
    > > void (*fp)();
    > > } Everything;

    [[snip]]
    > > I don't follow you here, sorry.

    >
    > The problem with the union technique is that you have to know ahead of time
    > the potentially strictest types are for alignment, and this is never
    > assured. However, you can use this:
    >
    > #define ALIGN(t) offsetof(struct { char _; t x; }, x)
    >
    > It requires you to specify a type as an argument since there isn't a
    > 'typeof' in ANSI C, but this isn't all that much different than using STL
    > containers in C++.


    Or varargs in C. Yes, that also appears to work.
    And it *also* requires that you know ahead-of-time
    with what types you will be dealing, so it doesn't
    gain you anything over the union approach except
    possibly some readability.


    > >> > What is sizeof ((char[2]){'a','b'}) ?
    > >> > What is sizeof ((int[2]){'a','b'}) ?
    > >> > What would be sizeof ({'a','b'}) ?
    > >>
    > >> C already has type promotion in expressions anyway, so I don't see how
    > >> this is such a stretch. 'a' and 'b' can be promoted as required.

    > >
    > > How is "required" in the third example? Unless you're proposing a
    > > radically different type system, in which arrays don't decay to pointers
    > > in value contexts, or something, I think I can give similar examples till
    > > the cows come home.

    >
    > Ahh, I see what you mean. I'm saying that in the cases where it's used as
    > an argument to a function or an assignment, it's clear what the { 'a', 'b' }
    > argument means. So in your examples, only the third is ambiguous.


    Only the third is non-standard C99 syntax. :)
    I had considered giving an example in which {'a','b'} could be either
    an unsigned char array, decaying to (unsigned char *), or an int array,
    decaying to (int *) and then being implicitly converted to
    (unsigned char *) when passed to the function

    void foo (unsigned char *arg);

    foo({'a','b'}); // unsigned chars or ints?

    but realized that I wasn't certain of the semantics of array literals in
    C99 anyway, and decided not to go out on that limb until I had to.

    -Arthur
     
    Arthur J. O'Dwyer, Jun 26, 2003
    #9
  10. Paul Hsieh

    Mark Gordon Guest

    On 25 Jun 2003 16:18:05 -0600
    Chris Torek <> wrote:

    <snip>

    > In article <>
    > Paul Hsieh <> writes:


    <snip>

    > >>There are C implementations that do this - they're just not very
    > >>popular, in which there is a lesson to be learned.

    >
    > >The reason is obvious, C has sold itself as being a *fast* language,
    > >and competition forces every vendors to pursue speed. ...

    >
    > Which is what Kevin Easton said. The sad fact is, it is much more
    > important to get the wrong answer fast than it is to get the right
    > answer slightly more slowly. (Of course, sometimes -- perhaps even
    > usually -- we get the right answer fast, too.)
    >
    > In my opinion, this is not the way things *should* be, and as C
    > creeps into more and more embedded software that runs on common
    > devices (and sometimes even safety-critical devices), I believe it
    > *will* change.


    If you are doing safety-critical work then you have to jump through a
    lot of hoops on reviewing everything including the code, I know this
    having rejected requirements documentation for a safety-critical
    project as not being up to scratch. So on safety critical the holes in
    the language are IMO less important because the review process should
    prevent any code that exhibits UB from getting in to a delivered
    product. Anything the reviewers are not confident about should be
    rejected at review, so you should not get anything through just because
    it is too difficult to see the errors.

    > As I see it, there are two ways in which it *can*
    > change: either the industry as a whole cleans up its act and starts
    > getting the right answer (at whatever speed) instead of the wrong
    > answer "real fast"; or the lawyers step in and sue everyone into
    > oblivion. I suspect the second is what will actually happen. "When"
    > is not something I can answer, though.


    With the software I have now started maintaining the customers would
    far rather have critical enhancements and bug fixes now than wait until
    I have gone through the code hunting down all the obvious bugs, let
    alone the had to find bugs. They definitely would not wait for it to be
    even translated to ISO C (it's currently pre-ISO but slowly moving
    forward) let alone a "safer" language.

    > >Vendors try to achieve this by making absolutely no useful provisions
    > >for all these undefined scenarios. As someone who has looked
    > >seriously at performance for more than a decade now, many of these
    > >undefinednesses don't help performance one iota.

    >
    > Some may indeed not help, but many kinds of definedness *would*
    > actually *hurt*. In my part-time-life as a "compiler guy" I have
    > seen some of what it takes to optimize array bounds checking, for
    > instance. There are easy cases and hard cases -- and the hard
    > cases are the ones that get you.


    Anyway, what do you do if the target is an embedded system? You can
    hardly get the autopilot on a plane to display "Array index out of
    bounds" and then expect the pilot to power it down and back up again.
    Apart from anything else the writers of the C implementation don't know
    how to access a display and some systems don't even HAVE displays.

    > >I.e., it is my belief that one can make slight modifications to the
    > >language, and change the library to substantially reduce the
    > >minefield of programming hazards that is inherent in the C language
    > >without sacrificing any performance.

    >
    > If you believe it, implement it. Assuming it all works, will the
    > market flock to you? That is Kevin Easton's question (or point,
    > rather: that the market has not, yet, despite others' efforts).


    For safety critical work you would also have to get your implementation
    validated before anyone would trust it. At least, I would not trust an
    implementation of a new language, or even a new implementation of an
    existing language, for safety critical work without some serious
    validation.

    Anyway, you can make C code as safe (short of 100% guarantee) as you
    like by performing sufficiently rigorous reviews, analysis (both static
    and dynamic) and good old fashioned testing. So the person advocating a
    new language has to prove that it provides a better trade off between
    ease of use, performance, cost, availability of trained staff,
    availability of staff with experience in the language etc.
    --
    Mark Gordon
    Paid to be a Geek & a Senior Software Developer
    Although my email address says spamtrap, it is real and I read it.
     
    Mark Gordon, Jun 26, 2003
    #10
  11. Paul Hsieh

    Clint Olsen Guest

    In article <>, Randy Howard
    wrote:
    >
    > Another example is the heated debates recently on the implementation (or
    > lack thereof) of safety features in libclc. The end result (IMHO) being
    > that it is optimized and structured for 20-30 people that hang out here,
    > rather than being designed to be a useful, productive addition that a lot
    > of people might feel safe with and derive value from. Yes, I exaggerate
    > to make a point, but newbs could benefit greatly from am implementation
    > of libclc that held your hand a little bit instead of the libc
    > implementations where you get to run 200mph with your pants down while
    > hoping no barbed wire fences are in your path.


    I'm curious in your mind what constitutes safety? Is it that the program
    continues to run but doesn't invoke UB or that it at least prints out a
    reasonable diagnostic before, "assert(0); have a nice day!"

    I'm curious from another users' POV what is acceptable? Is it ok that the
    library would have to be compiled with certain preprocessor flags to behave
    this way so that it can be defeated?

    I'm writing some of my own ADT libraries as a hobby, so I am curious.
    Conditional compilation can do a lot toward adding extra checks to thwart
    the obvious (NULL pointer access, other violated assumptions, etc.).

    Thanks,

    -Clint
     
    Clint Olsen, Jun 26, 2003
    #11
  12. Paul Hsieh

    CBFalconer Guest

    Clint Olsen wrote:
    >

    .... snip ...
    >
    > I'm curious in your mind what constitutes safety? Is it that the
    > program continues to run but doesn't invoke UB or that it at least
    > prints out a reasonable diagnostic before, "assert(0); have a nice
    > day!"


    By the time the run-time detects an error it is too late. This
    can only serve to alert the programmer to the fact that his
    thinking is fouled somewhere. The place to build in safety is as
    early as possible in the compile/link/run cycle, i.e. during
    compilation. Here the fundamental structure of C, with its 'trust
    the programmer' philosophy, is simply not conducive to clean
    programs (although it does not prevent them). The worst failures
    are in the cavalier use of pointers and the lack of real user
    defined types with specific validity ranges.

    There is no way of specifying 'this variable holds a count of
    oranges' and that putting its value into a variable that holds 'a
    count of apples' is a mistake.

    So my advice is similar to advice to new brides: Don't try to
    reform and remold your husband - accept him (and C) for what it
    is, complete with warts and failings.

    Unlike marriages though, you can always use an appropriate
    language for the job without giving up C. Ada and Pascal come to
    immediate mind. Your C compiler will probably not be offended.
    Monogamy is not a prerequisite for programming.

    --
    Chuck F () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
     
    CBFalconer, Jun 26, 2003
    #12
  13. Paul Hsieh

    Paul Hsieh Guest

    In article <bdd72t$koe$>, says...
    > >First of all, in Java it *HAS* to throw a run-time exception,
    > >otherwise its not Java (same with Ada.)

    >
    > Yes... and Java and Ada are not being used in so many places where
    > C *is* being used.


    First of all, Java has totally encroached into the generic software application
    space. The only reason its not doing better is because of things like Visual
    Basic and Perl. Java is being used more and more, and will only stay away from
    places where it *can* compete with C on a pure functional basis (like for
    drivers or something.) C is being relegated solely to the role as a structured
    assembly language.

    Ada is not being adopted because its too complicated, people don't like the
    syntax and there has not been a sufficient effort in the tools arena and the
    people who Ada could appeal to have been taken over by Java, Python, Lisp, or
    something of that nature.

    And people are not avoiding Java because it has run-time exceptions to cover
    all unexpected/unintended run-time scenarios. You do not make a credible
    argument.

    > [...] Why is it C that being used instead? (I know
    > lots of possible answers, but not necessarily "the" answer -- or
    > "the answers" if there is more than one. So this is not merely a
    > rhetorical question, although it works as one. :) )


    The notion that C is even holding steady, much less actually *attracting*
    programmers away from Java or other programming communities is dellusional
    beyond belief. At best you could say you are getting converts from the last
    remaining hold outs in Fortran, but that's a finite pool, and I imagine those
    people will be motivated to try Java just as much as C.

    > >Secondly, just because there are hazards in the C language, doesn't
    > >mean its there for performance reasons (gets comes to mind.)

    >
    > "Performance" can also refer to "rapid coding" (it takes a fraction
    > of a minute longer to write an fgets-and-smash-newline routine, or
    > suck one in from one's private library, and oh no! then you might
    > be a millisecond late to market! -- which, it seems, sometimes
    > really *is* fatal).


    The common cry of the anal retentive ANSI C language lawyer. Always leading
    with the blame, and no retrospection about what they are doing. Pray tell me,
    what universal value of "n" are you going to stick into your sub-minute
    solution? What are you going to do about lines that are longer? What if you
    don't get a '\n' at the end? What happens if the user very cleverly finds a
    way to stick a '\0' into the input prior to the line terminator? What does it
    mean if you cannot allocate space for the target buffer? Gonna pass around
    some more blame, or are you actually going to solve the problem?

    You may be able to deal with all this in less than a minute, but it leaves no
    end to the *further blame* you are going to assign to the newbie who can't.
    Programming languages are not just for people who already know them completely.

    > >>There are C implementations that do this - they're just not very
    > >>popular, in which there is a lesson to be learned.

    >
    > >The reason is obvious, C has sold itself as being a *fast* language,
    > >and competition forces every vendors to pursue speed. ...

    >
    > Which is what Kevin Easton said. The sad fact is, it is much more
    > important to get the wrong answer fast than it is to get the right
    > answer slightly more slowly. (Of course, sometimes -- perhaps even
    > usually -- we get the right answer fast, too.)


    So why not use assembly where you can get right answers even faster still? A
    lot of this "speed of C" has a lot a belief more than substance behind it, as
    you are well demonstrating.

    > In my opinion, this is not the way things *should* be, and as C
    > creeps into more and more embedded software that runs on common
    > devices (and sometimes even safety-critical devices), I believe it
    > *will* change.


    Can I get a hit of whatever drug it is that you are on? People are figuring
    out how to put Java on embedded devices, because people are not willing to
    waste time dealing with the pitfalls of the C language (Java evnironments are
    also somewhat easier to simulate 100% correctly.) Any upsurgence you may
    currently be seeeing in the embedded world for C is fast being overtaken by C++
    (compromising the lack of safety for the hope of higher productivity), and Java
    is starting to take a foothold.

    So long as the language itself specifies so much undefinedness, C hasn't got a
    chance. I agree with you that this will change, but it will do so by
    abandoning C, not trying to make it safer within the ANSI Spec.

    > [...] As I see it, there are two ways in which it *can*
    > change: either the industry as a whole cleans up its act and starts
    > getting the right answer (at whatever speed)


    This already exists in other languages, specifically Java. And with
    "undefined" all over the ANSI C standard, "the right answer" has no
    real world meaning.

    > [...] instead of the wrong
    > answer "real fast"; or the lawyers step in and sue everyone into
    > oblivion. I suspect the second is what will actually happen. "When"
    > is not something I can answer, though.


    Well, the lawyers may sue some old-school NASA engineers who decide its ok to
    keep killing its astronauts, or throwing away billions on spaceships that can't
    seem master the concept of landing on Mars, because they can't figure out how
    to make safe/good software. But some parts of the industry have already woken
    up and smelled the coffee and are voting with their feet.

    > >Vendors try to achieve this by making absolutely no useful provisions
    > >for all these undefined scenarios. As someone who has looked seriously at
    > >performance for more than a decade now, many of these undefinednesses
    > >don't help performance one iota.

    >
    > Some may indeed not help, but many kinds of definedness *would*
    > actually *hurt*. In my part-time-life as a "compiler guy" I have
    > seen some of what it takes to optimize array bounds checking, for
    > instance. There are easy cases and hard cases -- and the hard
    > cases are the ones that get you.


    And so you think this half digital diarrhea and half "it has to be there"
    situation is acceptable?

    This thread is about the possible ideas for a successor to C, and my
    suggestions are meant to address the potential for such a successor which deals
    with some of the failings of C. Your nonsensical stalwart defense of C with oh
    so typical "blame the user for not understanding" or "the Spec says it doesn't
    have to be like this" is not helpful.

    > >I.e., it is my belief that one can make slight modifications to the
    > >language, and change the library to substantially reduce the minefield
    > >of programming hazards that is inherent in the C language without
    > >sacrificing any performance.

    >
    > If you believe it, implement it. Assuming it all works, will the
    > market flock to you?


    The standard response. Look, I am not a language designer or implementor. But
    others are, and have already done so. The most famous example being Java. And
    yes, the market has been flocking to Java, despite the mouth frothing claims to
    the contrary.

    That said, I have created a simple language library just to solve the one
    narrow problem of string manipulation in the C language (you know the bstring
    thing I keep harping on about; see my sig.) I wouldn't say its been a market
    success, but it is a technical one as far as I can determine (nobody has yet
    demonstrated it to have any kind of fatal flaw.) Its dramatically safer than
    using ordinary char buffers, its easy to use, its more functional than the C
    library, and its actually *FASTER* than C in many cases.

    > [...] That is Kevin Easton's question (or point, rather: that the market has
    > not, yet, despite others' efforts).


    Then you are both sadly mistaken. In the mid 90s, at the height of C/C++'s
    popularity, *ALL* applications were written in either C (maybe 70%) or C++
    (maybe 25%). The only competitor being raw assembly language a distance third.
    Right now the market looks something like 30% C (and quickly declining) 30%
    C++, 15% Java, 25% other (these numbers are from sourceforge.net). That's not
    bad for a language a young as Java.

    --
    Paul Hsieh
    http://www.pobox.com/~qed/
    http://bstring.sourceforge.net/
     
    Paul Hsieh, Jun 26, 2003
    #13
  14. Paul Hsieh

    Paul Hsieh Guest

    In article <>, says...
    > Paul Hsieh wrote:
    > > Its this whole "undefined behavior" thing that's the problem.
    > > Secondly, just because there are hazards in the C language, doesn't
    > > mean its there for performance reasons (gets comes to mind.)

    >
    > I'm inclined to agree - let's not forget that there are a lot of
    > people of the type who would make cutting tools safer by removing
    > all sharp edges.
    >
    > C remains a /useful/ language.


    Oh absolutely. On balance, C is far superior to Pascal, Fortran, and many that
    came before it, while being reasonable to implement. Its speed superiority
    over other languages is nothing to sneer at either.

    > [...] The challenge is to improve the
    > standard (define the undefined) without sacrificing /any/ of the
    > utility; and without kow-towing to hardware/software/compiler
    > vendors. It's not only the retention of the current form of
    > gets(), its also "lesser" issues like a standard representation
    > for time and the ability to perform reliable file seeks.


    Even more issues. This is the kind of useful discussion worth having.

    > There's nothing to stop you from making "small modifications to
    > the C library" on your own so long as those modifications are in
    > strict conformance with the standard - or were you really saying
    > that small changes to the standard are needed?


    Well, I believe both are needed, however, you can always start with just one of
    these at a time. I mean the language Spec things that both me are things like
    ambivlantely defined right shift on signed integers, obvious missing operators,
    and allowing for things like 1[a++] -= (a++)[*(--a)] syntactically while
    disavowing any claims to their actual specific ordering of operations. While
    the library things that bother me are things like isAcii() dying on characters
    > 128, the existence of gets() and so on.


    If one keeps to the idea of a successor to C being still C, then modifications
    both the core language and library can be seen as essentially orthogonal.
    Otherwise we might as well be talking about the creation of a new language.

    > As a practical matter, I don't think that a really useful systems
    > programming language /can/ be safe in the hands of an unsafe
    > programmer.


    Well, for programmers of very weak skill level, there's only so much you can
    do. But what about the medium and high skill level programmers out there? I
    am talking about those above average programmers who are pressured to deliver a
    product faster than it takes them to think through the design and
    implementations. C just degrades to disaster, while other languages just
    degrade to run-time errors or non-functionality.

    Also, using a language also dictates the way you think about programming in
    that language. To that end, if the APIs are written in such a way that the
    programmer is not thinking about programming as hacking on low level byte
    accesses to memory, they might be less inclined to shoot themselves in the foot
    as a result.

    --
    Paul Hsieh
    http://www.pobox.com/~qed/
    http://bstring.sourceforge.net/
     
    Paul Hsieh, Jun 26, 2003
    #14
  15. Paul Hsieh

    Chris Torek Guest

    In article <>
    Paul Hsieh <> writes [in reply to me]:

    [everything I wrote, and most of what Paul Hsieh wrote, snipped]

    >... Your nonsensical stalwart defense of C with oh so typical "blame
    >the user for not understanding" or "the Spec says it doesn't
    >have to be like this" is not helpful.


    If you think I am attempting to "defend" C, then either I am not
    writing well, or you are not reading well (or perhaps both).

    What I am trying to say is that I think C is being used inappropriately
    in places where it matters, and it is beginning to hurt everyone.
    I fear that this is going to continue until the legal system steps
    in and swings the pendulum so far into the "safety" aspect that it
    severely damages parts of the computing industry. Furthermore, I
    suspect that making small changes to an otherwise C-like language
    will not succeed in averting this particular pending catastrophe.

    >Right now the market looks something like 30% C (and quickly declining) 30%
    >C++, 15% Java, 25% other (these numbers are from sourceforge.net). That's not
    >bad for a language a young as Java.


    I also contend that this has nothing to do with C's definedness or
    undefinedness of particular items, but rather with time-to-market
    numbers for Java, in those applications where Java makes sense.
    It is wonderful that Java throws an exception for out of bounds
    arrays, instead of scribbling over RAM, but this is not *why* Java
    is gaining ground.
    --
    In-Real-Life: Chris Torek, Wind River Systems (BSD engineering)
    Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
    email: forget about it http://67.40.109.61/torek/index.html (for the moment)
    Reading email is like searching for food in the garbage, thanks to spammers.
     
    Chris Torek, Jun 27, 2003
    #15
  16. Paul Hsieh <> wrote:
    > My counter proposal is to use region/context specific memory
    > allocation. The purpose being to add a function like
    > freeAll(regionHandle) to perform a mass free in one shot. I have used
    > this technique and it can actually lead to both a performance
    > improvement and obviously this can make your programmers much safer in
    > many cases.


    i've only been using C for about two years, and it only took me a month or
    so to begin to [re]invent pool allocators. what's the difference between a
    generic pool allocator and "region memory"? how many _types_ of data
    structures, typically, in your average program really need to come from the
    heap? in my short experience it seems usually to be only a few.

    - Bill
     
    William Ahern, Jun 27, 2003
    #16
  17. Paul Hsieh

    Kevin Easton Guest

    In comp.lang.c Arthur J. O'Dwyer <> wrote:
    [...]
    > Sorry, you're right. The physical layout of bits doesn't matter to
    > the shift operators. In a case where the bits were stored LSB..MSB,
    > E1 >> 1 would have to shift bits to the "left" in hardware. (!)


    No worries... just ask the user to turn their computer around 180
    degrees and everything will be OK.

    - Kevin.
     
    Kevin Easton, Jun 27, 2003
    #17
  18. Paul Hsieh

    Paul Hsieh Guest

    william@wilbur.25thandClement.com says...
    > Paul Hsieh <> wrote:
    > > My counter proposal is to use region/context specific memory
    > > allocation. The purpose being to add a function like
    > > freeAll(regionHandle) to perform a mass free in one shot. I have used
    > > this technique and it can actually lead to both a performance
    > > improvement and obviously this can make your programmers much safer in
    > > many cases.

    >
    > i've only been using C for about two years, and it only took me a month or
    > so to begin to [re]invent pool allocators. what's the difference between a
    > generic pool allocator and "region memory"? how many _types_ of data
    > structures, typically, in your average program really need to come from the
    > heap? in my short experience it seems usually to be only a few.


    Well, "region" memory allocators as I (and likely I alone, since people rarely
    adopt sensible notations that ever make any sense to me) like to call them are
    just memory allocated from seperate selectable heaps.

    To see where something like this can be useful, think of the something like a
    symbolic math package, with a rule based formula simplification mechanism. You
    can represent formulas as tree-like structures, with non-homogenous nodes. As
    you apply each simplification rule to your formulas it makes sense to copy
    parts of your tree by reference (i.e., just point to them) while generating new
    nodes of various configuration and link them up in arbitrary ways to implement
    each simplification run. What this leaves you with is a mess of nodes, not all
    linked up and many (if not most) of which are no longer pointed to by anything
    (and not really usable.) Dilligently tracking what needs to be freed and doing
    so on an as needed basis doesn't really work if you have operations other than
    simplification which can increase references to sub-expressions (trees.) One
    would have to go to a reference counting mechanism, and essentially implement
    manual garbage collection. Of course, there is the alternative of actually
    using garbage collection.

    However, for this application region based memory allocation works really well.
    What you do is at the start of any new high level operation, you create a new
    heap, and perform all your scratch work in this new heap. Then once you are
    done, you copy the results into some other higher level heap, then destroy the
    entire new heap in one shot. This is even superior to garbage collection,
    because all the extraneous memory is *immediately* recovered after operation is
    done (rather than lingering around while some garbage collection thread kicks
    in), and done so in a way that is far faster than freeing each allocation one
    by one.

    Another curious application is for storing high performance, highly compacted
    english language dictionaries in memory for the purposes of solving boggle, or
    anagram puzzles. What you do is store all the words into an n-ary sorted tree
    where each level of the tree represents a successive letter position, and each
    node corresponds to the next letter in a group of legal words. The trick for
    conserving memory is realizing that there are word suffix groups that are very
    common in the english language. So what you do is as you are building your
    tree, you detect when an end group is the same as one you have already inserted
    into your tree and simply link to it rather than rebuilding those suffic
    groups. This can make your dictionary structure compact (which is good from a
    memory pressure point of view) but now leaves us with the interesting problem
    of how can you free this structure once you are done with it? You cannot
    simply traverse the tree and free the nodes as encountered, because a node may
    be referenced by other nodes in the tree an arbitrary number of times. Once
    again, the concept of a region-based memory allocator comes to the rescue. If
    the tree dictionary is allocated in its own heap, then to free it, you just
    throw away the whole heap that it was in.

    Region based memory heaps such as I have described have the additional
    advantage over garbage collection that they are easy to implement, don't
    require any kind of threading support, and don't make any kind of structural
    imposition on the representation of pointers in your heap or data segments.

    --
    Paul Hsieh
    http://www.pobox.com/~qed/
    http://bstring.sourceforge.net/
     
    Paul Hsieh, Jun 27, 2003
    #18
  19. Paul Hsieh

    Kevin Easton Guest

    Paul Hsieh <> wrote:
    > In article <newscache$3de2hh$pz4$>, kevin@-nospam-
    > pcug.org.au says...
    >> Paul Hsieh <> wrote:
    >> > But that completely misses the point! First of all, in Java it *HAS*
    >> > to throw a run-time exception, otherwise its not Java (same with Ada.)
    >> > Its this whole "undefined behavior" thing that's the problem.
    >> > Secondly, just because there are hazards in the C language, doesn't
    >> > mean its there for performance reasons (gets comes to mind.)

    >>
    >> No, YOU have missed the point. C allows both the "safe" and "unsafe"
    >> implementation - yet the "unsafe" implementations are far more popular.
    >> Why would there by ANY reason to think that a new version of C that did
    >> nothing more than mandate the "safe" implementation would be any more
    >> popular than current "safe" C implementations?

    >
    > And who exactly is suggesting that a new version of C should *ONLY* mandate
    > more safety? My original post in this thread has *MANY* points in it -- not
    > that you care to address them obviously.


    No, I was only commenting about this one point. What's wrong with that?
    In fact, I think I either agreed or was neutral on most if not all of
    your other points.

    My point is simply this: the security problems etc. caused by the
    particular manifestations of undefined behaviour are *not* a problem
    with the C standard - they're a problem with the common C
    implementations that exhibit this behaviour. There's *nothing* wrong
    with the C standard allowing both "bad" and "good" implementations, and
    leaving it up to the market to sort it out. Choice is good.

    The fact that the market has in the past largely made the wrong decision
    when confronted with this choice is neither here nor there.

    - Kevin.
     
    Kevin Easton, Jun 27, 2003
    #19
  20. Paul Hsieh

    Paul Hsieh Guest

    In article <newscache$3jo4hh$bmm$>, kevin@-nospam-
    pcug.org.au says...
    > Paul Hsieh <> wrote:
    > > In article <newscache$3de2hh$pz4$>, kevin@-nospam-
    > > pcug.org.au says...
    > >> Paul Hsieh <> wrote:
    > >> > But that completely misses the point! First of all, in Java it *HAS*
    > >> > to throw a run-time exception, otherwise its not Java (same with Ada.)
    > >> > Its this whole "undefined behavior" thing that's the problem.
    > >> > Secondly, just because there are hazards in the C language, doesn't
    > >> > mean its there for performance reasons (gets comes to mind.)
    > >>
    > >> No, YOU have missed the point. C allows both the "safe" and "unsafe"
    > >> implementation - yet the "unsafe" implementations are far more popular.
    > >> Why would there by ANY reason to think that a new version of C that did
    > >> nothing more than mandate the "safe" implementation would be any more
    > >> popular than current "safe" C implementations?

    > >
    > > And who exactly is suggesting that a new version of C should *ONLY* mandate
    > > more safety? My original post in this thread has *MANY* points in it -- not
    > > that you care to address them obviously.

    >
    > No, I was only commenting about this one point. What's wrong with that?


    I never made a point that suggested that a C language successor should *only*
    include safety features. I never even implied it. Nobody did. And yet you
    have no problem with attributing that line of reasoning to me. If you want to
    address my points individually then do so, but this is just false attribution.

    > In fact, I think I either agreed or was neutral on most if not all of
    > your other points.


    Well, given that you have just made up a point that you think I made, I'm not
    sure what to think.

    > My point is simply this: the security problems etc. caused by the
    > particular manifestations of undefined behaviour are *not* a problem
    > with the C standard - they're a problem with the common C
    > implementations that exhibit this behaviour. There's *nothing* wrong
    > with the C standard allowing both "bad" and "good" implementations, and
    > leaving it up to the market to sort it out. Choice is good.


    You are not in touch with reality. Give a man enough rope and he'll hang
    himself. The reason bad implementations of C exist is because the standard
    endorses it.

    > The fact that the market has in the past largely made the wrong decision
    > when confronted with this choice is neither here nor there.


    Without guidance, the market will not do anything but find itself in some
    monopolies. The market has in fact spoken -- the market says lee way for bad
    implementations in the standard is a guarantee that these bad implementation
    will dominate. This has pretty much been true of *all* languages.

    --
    Paul Hsieh
    http://www.pobox.com/~qed/
    http://bstring.sourceforge.net/
     
    Paul Hsieh, Jun 27, 2003
    #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. George W. Cherry

    Successor to Java?

    George W. Cherry, Sep 13, 2004, in forum: Java
    Replies:
    13
    Views:
    2,747
    George W. Cherry
    Sep 14, 2004
  2. Dan Pop

    Re: Designing a successor to C

    Dan Pop, Jun 24, 2003, in forum: C Programming
    Replies:
    0
    Views:
    1,140
    Dan Pop
    Jun 24, 2003
  3. Chris

    Re: Designing a successor to C

    Chris, Jun 24, 2003, in forum: C Programming
    Replies:
    0
    Views:
    1,270
    Chris
    Jun 24, 2003
  4. Chris Torek

    Re: Designing a successor to C

    Chris Torek, Jun 27, 2003, in forum: C Programming
    Replies:
    1
    Views:
    832
    Mark Gordon
    Jul 10, 2003
  5. Bruno Desthuilliers

    Re: Designing a successor to C

    Bruno Desthuilliers, Jul 1, 2003, in forum: C Programming
    Replies:
    0
    Views:
    854
    Bruno Desthuilliers
    Jul 1, 2003
Loading...

Share This Page