24 ms·

C for All

• Dinux 9y ago
  This has been tried many times before, and eventually all these attempts die a lonely death. Why use extensions anyway? If one desired the luxury of modern scripting languages, switch to C++, Rust, Go or one of the other alternatives the article mentions.
  • pjmlp 9y ago
    Because regardless how some of us might dislike C and its security related issues, the truth is that no one is ever going to rewrite UNIX systems in other language, nor the embedded systems where even C++ has issues gaining market share. So if one finally manages to get a safer C variant that finally wins the hearts of UNIX kernels and embedded devs, it is a win for all, even those that don't care about C on their daily work. Until it happens, that lower layer all IoT devices and cloud machines will be kept in C, and not all of them will be getting security updates.
    • Dinux 9y ago
      I do not question the usefulness of C, I use it in my daily work. What I am saying is that most C developers that use the language day-in-day-out know quite well what they are doing, and don't need yet another non-standard way of writing the code. Safety is a good point, but the initiative doesn't even mention the word, and there is no reason to assume the C-for-All extension targets safety at all
      • s73v3r_ 9y ago
        "What I am saying is that most C developers that use the language day-in-day-out know quite well what they are doing" I'm going to strongly disagree with that statement.
        • saagarjha 9y ago
          I might have agreed with you if this was C++. C is a small enough language that most programmers can understand most of it.
          • s73v3r_ 9y ago
            Toyota was full of programmers that apparently "understood what they were doing."
            • saagarjha 9y ago
              Bad practices can carry over to any language. They’re clearly incompetent at using C, but that doesn’t mean that they won’t be incompetent in another language.
            • ori_b 9y ago
              Fair point, but changing the language won't change the amount of global state. and the associated complexity, nor will it make subsystem supervision work correctly. Changing the language will not prevent unbounded recursion or the associated stack overflows and subsystem failures. Changing the language will not fix mis-analysis of task switching overhead. And changing the language will not fix manufacturing issues with the PCBs. As far as I'm aware, one of the very few toolchains that even try to improve on this over C are Ada/SPARK.
              • vvanders 9y ago
                > but changing the language won't change the amount of global state Global mutable state is marked as Unsafe in Rust. > nor will it make subsystem supervision work correctly Erlang is built specifically around this concept. Perfect is the enemy of good here, throwing out a whole language due to one case doesn't help anyone.
                • ori_b 9y ago
                  > Global mutable state is marked as Unsafe in Rust. It's also the simplest way to avoid dynamic allocation and the associated OOM issues. So, short of doing static analysis to bound heap usage at compile time, that makes things worse. And Toyota already got the static analysis wrong for their stack usage. At least globals will fail to compile if they won't fit.
      • pjmlp 9y ago
        Even ANSI/ISO C working group acknowledges that “thrust the programmer” doesn’t quite work.
        • gmueckl 9y ago
          This is because trusting the programmer is fundamentally wrong, no matter the programming language. In any good development process the actual coding is the least amount of work - for a reason.
          • pjmlp 9y ago
            This was the statement I was referring to. <quote> Spirit of C: a. Trust the programmer. b. Do not prevent the programmer from doing what needs to be done. c. Keep the language small and simple. d. Provide only one way to do an operation. e. Make it fast, even if it is not guaranteed to be portable. The C programming language serves a variety of markets including safety-critical systems and secure systems. While advantageous for system level programming, facets (a) and (b) can be problematic for safety and security. Consequently, the C11 revision added a new facet: => f. Make support for safety and security demonstrable. </quote> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2139.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2139.pdf
            • gmueckl 9y ago
              Okay, this makes me rethink my previous statement. There are two kinds of trust here: A low level programming language should not impose restrictions on the code that prevent the programmer from doing what needs to be done, even if it looks wrong. This is how I read the 'Spirit of C" that you quoted. And certain applications would be impossible to write without it. But you need a development process to make sure that your system does exactly the right thing. So the quote should read "trust the process" rather than "trust the programmer".
    • kerkeslager 9y ago
      What makes you think that a safer C variant would win the hearts of UNIX kernels and embedded devs any more than C++ (which started as just a C variant).
      • BoorishBears 9y ago
        Simplicity, no STL or templating, no OOP connotations I don’t necessarily think it would, but if it did, those would all be reasons
        • BruceIV 9y ago
          [actually on the Cforall team] This is basically our pitch -- the last 30 years of language design features applied to a language that is not only source-compatible with C (like C++), but actually maintains the procedural paradigm of C (unlike C++) -- idiomatic C code should require minimal to no change to make it idiomatic Cforall code, and skilled C programmers should be able to learn the extension features orthogonally, rather than needing to figure out complex interactions between, say, templates and class inheritance. We are working in the same space as C++, and do draw inspiration from C++ where useful, but with the benefit of decades of watching C++ try things to see where the important features are. There's also some really neat language-level concurrency support; work is ongoing on new features and a shorter summary, but you can see one of our Master's student theses for details: https://uwspace.uwaterloo.ca/handle/10012/12888 https://uwspace.uwaterloo.ca/handle/10012/12888
          • aidenn0 9y ago
            the existence of exceptions seems to bely the idea of minimal changes to make idiomatic C code idiomatic Cforall code. While C does have longjmp and friends, usage of them is hardly idiomatic, so most C code assumes no non-local tranfer of control happens when calling functions. Coding with non-local transfer of control and without require very different idioms.
      • wolfgke 9y ago
        It would probably be much smaller than the gigantic C++ standard.
    • zombieprocesses 9y ago
      > So if one finally manages to get a safer C variant that finally wins the hearts of UNIX kernels and embedded devs A safer variant wouldn't be C. What makes C great for OS development is that it is just a step above assembly and you as a developer are given tremendous amount of power to do good and evil. C#/Java are programming languages with training wheels and it's great for application development. But for low level coding required for OS, network stacks, databases, etc, you really have to take the training wheels off. I suppose you can try and make the C type system more stringent, but then it wouldn't be C. And considering they are aiming for backwards compatibility with existing C and its immense code infrastructure, they will have to keep the "flaws" in c for all. Time would be better spent making the libraries/kernel/etc sturdier but if they can pull it off and win the hearts and minds of OS developers, then so be it. Also, people have been trying to sideline C for decades. Each attempt has only reinforced C's standing and reminded us why C is so essential for OS development. Anyone remember the ill-fated attempt by Sun with their JVM centered JavaOS?
      • golergka 9y ago
        A full time C#, can confirm. It's an awesome business logic langauge, but the hot path eventually gets rewritten in a very C-like style, with all Linq, exceptions and allocations thrown out.
        • pjmlp 9y ago
          The new 7.x features are going to make it easier.
          • golergka 9y ago
            Some of us are still stuck in 3.5
            • Thiez 9y ago
              Can you explain why? I assume those c# programs are used for backend stuff on servers, surely it isn't hard to get a 4.6+ runtime installed?
    • dralley 9y ago
      counterexample: RedoxOS Although it's more along the lines of Plan9 - a unix-like system that ignores the bits of POSIX that really suck.
      • pjmlp 9y ago
        If it doesn’t support 100% POSIX it isn’t UNIX. Also how would you make memcpy() safe in a POSIX implementation on Redox?
        • aidenn0 9y ago
          Then most linux distributions aren't UNIX, as they do tend to deviate from POSIX in places.
          • nine_k 9y ago
            It's GNU/Linux, and GNU = GNU is Not Unix. So it says Not Unix right on th tin.
        • boomlinde 9y ago
          To be perfectly fair, if it isn't UNIX it isn't UNIX.
        • IAmLiterallyAB 9y ago
          Almost nothing is 100% POSIX. Most Linux distros aren't. Who cares as long as the important bits are there.
        • Gibbon1 9y ago
          > Also how would you make memcpy() safe Easy, don't have memcpy().
    • zzzcpan 9y ago
      Which means that minimal requirements to win kernel and embedded devs is to integrate well with the rest of the C ecosystem, including myriad of C compilers and to be really well suited for low level work. This excludes pretty much all ideas, but meta languages that produce C code. Might even be necessary to promote the language itself not as a new language, but as a meta preprocessor for C to avoid alienating developers. But realistically this is not feasible nor necessary. There are much more feasible ideas to improve safety, than forcing half of the world to learn a lot of new things and change.
      • pjmlp 9y ago
        Unfortunately not all systems are Solaris running on SPARC, with memory protection enabled. Something akin to Intel MPX.
    • pjc50 9y ago
      The trouble with a "safer C variant" is that it must remove features, or at least more heavily constrain programs to a safer subset of the language. This makes it not backwards-compatible. I think the only successful "subset of C" is MISRA.
      • pjmlp 9y ago
        Maybe Frama-C as well.
      • fao_ 9y ago
        I remember reading a paper from around 2007 that asserted that most of MISRA did not catch or significantly prevent major bugs in code, indeed it asserted that much of the standard was useless. I am failing to find it now, as I cannot remember what terms I used, and I am not at a library computer and therefore I cannot search behind paywalls beyond abstracts.
        • zzzcpan 9y ago
          Cannot say that this is unexpected, but I was interested to find some papers, presumably these two: Assessing the Value of Coding Standards: An Empirical Study [1], Language subsetting in an industrial context: A comparison of misra c 1998 and misra c 2004 [2] [1] http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.559.7854&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.559... [2] http://leshatton.org/Documents/MISRA_comp_1105.pdf http://leshatton.org/Documents/MISRA_comp_1105.pdf
          • pjmlp 9y ago
            Interesting, thanks for the papers.
      • duneroadrunner 9y ago
        SaferCPlusPlus[1], for example, is a safe subset of C++ that has compatible safe substitutes for C++'s (and therefore C's) unsafe elements. So migrating existing C/C++ code generally just requires replacing variable declarations, not restructuring the code. For C programs, one strategy is to provide a set of macros to be used as replacements for unsafe types in variable declarations. These macros will allow you, with a compile-time directive, to switch between using the original unsafe C elements, or the compatible safe substitutes (which are C++ and require a C++ compiler). The replacement of unsafe C types with the compatible substitute macros can be largely automated, and there is actually a nascent auto-translator[2] in the works. (Well, it's being a bit neglected at the moment :) Custom conventions using macros to improve code quality are not that uncommon in organized C projects. Right? But this one can (optionally, theoretically) deliver complete memory safety. So you might imagine, for example, a linux distribution providing two build versions, where one is a little slower but memory safe. [1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus https://github.com/duneroadrunner/SaferCPlusPlus [2] https://github.com/duneroadrunner/SaferCPlusPlus-AutoTranslation https://github.com/duneroadrunner/SaferCPlusPlus-AutoTransla...
    • s73v3r_ 9y ago
      They're not going to rewrite any of them in this dialect, either.
    • snarfy 9y ago
      You can use c++14 on embedded devices just fine, and people do.
      • saagarjha 9y ago
        You can, as long as you stay away from templates and lambdas and STL containers; in short, most of the reasons you’d use C++.
        • aurelian15 9y ago
          STL, RTTI and Exceptions should be avoided on embedded platforms (talking about 8 bit µCs here). I've extensively used both templates and lambdas on 8 bit AVRs (both the Tiny and Mega series); actually, writing templated code for µCs is a great way to avoid overhead stemming from function pointers etc. while still having well maintainable code.
    • michaelcampbell 9y ago
      > Because regardless how some of us might dislike C and its security related issues, the truth is that no one is ever going to rewrite UNIX systems in other language Now will they in this.
• thanatos_dem 9y ago
  Site is down... that doesn’t exactly bode well for an article seemingly about programming.
  • mbel 9y ago
    For convenience of other readers, here is a version cached by Google: https://webcache.googleusercontent.com/search?q=cache:wEWECJ0f2q8J:https://plg.uwaterloo.ca/~cforall/+&cd=1&hl=pl&ct=clnk&gl=pl https://webcache.googleusercontent.com/search?q=cache:wEWECJ...
    • wolfgke 9y ago
      Or here by archive.org: https://web.archive.org/web/20180323124625/https://plg.uwaterloo.ca/~cforall/ https://web.archive.org/web/20180323124625/https://plg.uwate...
  • CO-VAX 9y ago
    "Powered by Huawei" -- ironic, isn't it?
    • BruceIV 9y ago
      [actually on the Cforall team] Huawei has funded the project for the past couple years, the web server is just our university research group's web host, which we didn't expect to get this much traffic on (it wasn't one of us who put this page on HN). We've been running fairly low-profile for the moment, but should make a beta release later this summer.
      • AndyKelley 9y ago
        How did you get funding? I'd like to get some funding for my project (ziglang.org)
        • BruceIV 9y ago
          IIRC [not the team lead] they approached us when they were looking for modernization options for their existing C codebases. From there it went through the usual university-corporate research partnership process. Zig looks neat, BTW.
• castratikron 9y ago
  GNU C is probably my favorite extension of C. There's a lot of good stuff in there. The vector extensions make it really easy to write platform agnostic SIMD code. https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html https://gcc.gnu.org/onlinedocs/gcc/C-Extensions.html
  • blattimwind 9y ago
    I've used nested functions more often than I'd like to admit, because dealing with insane callback-heavy APIs is made a lot easier with them.
    • s73v3r_ 9y ago
      I've never really thought to use nested functions for that. I guess I've never really thought of what nested functions were for.
      • gmueckl 9y ago
        Welcome to the lambda party ;). Passing nested functions as pointers is how lambdas often work behind the scene.
      • Roboprog 9y ago
        Those of us who had nested functions/procedures and “procedural types” in Pascal (or Algol, but that’s beyond my experience) back in the day have :-) Then K&R came, and took our nice toys away. Fortunately, the GNU Pascal compiler needed nested subroutines, so they exposed the feature in their C compiler, as well.
        • pjmlp 9y ago
          And now even C# has them. :) On C++ we can fake them with lambdas.
    • Gibbon1 9y ago
      I love using nested functions when I have to write state machine code. It's a hella a lot better than the old school way using macros to do the same thing.
• LaneRendell 9y ago
  Hallelujah.
• hsivonen 9y ago
  Considering how hard it is to write truly exception-safe C++ and considering how major C++ code bases don't allow exceptions, adding exceptions to C does not seem like a good idea.
  • codemac 9y ago
    I've always liked the idea of djb's boringcc[0], except with different definitions of undefined based on what users were using C currently with. This would allow people to "upgrade" into boringcc with their current code bases. So with a single invocation of a compiler, you couldn't use more than one set of defined undefined behaviors. [0]: https://groups.google.com/forum/m/#!msg/boring-crypto/48qa1kWignU/o8GGp2K1DAAJ https://groups.google.com/forum/m/#!msg/boring-crypto/48qa1k...
    • platinumrad 9y ago
      I would love a gcc optimization level, like -Og which only applies optimizations that don't interfere with debugging information, where all undefined behavior is specified. Does anyone know if undefined behavior is specified in CompCert? Or does CompCert simply not allow you to write programs with undefined behavior?
  • golergka 9y ago
    Whether exceptions are good or bad depends on what error handling strategy your product needs. For some software, it's better to try and recover no matter what. For others, complete failure is preferrable to operating with invalid state. Exceptions can be a blessing or a curse depending on what you need. Having them in your toolbox is certainly an advantage over having no choice.
    • xamuel 9y ago
      >Having them in your toolbox is certainly an advantage over having no choice I disagree. Dependencies, or coworkers, will use them despite your decision not to use them. When a dependency does use them, chances are the documentation is poor or non-existent. "Recover no matter what" doesn't require exceptions. A common C idiom is to call a function like f(input, *err), where err points to memory where f can write error diagnostic info. Clunky, but I like how it makes the "exceptions" somewhat self-documented in the function signature.
• antirez 9y ago
  So the mailing list and the other stuff are "internal only"? How is possible for external individuals to take part?
  • BruceIV 9y ago
    I'm actually on the Cforall team -- we've been running fairly low-profile for the moment (it wasn't one of us that posted the homepage to HN), but plan on making a beta release of the compiler and stdlib sometime this summer. If you're interested in working on the project though, more hands are always welcome; I'd suggest contacting our team lead, Peter Buhr, his email is pabuhr AT the university domain Cforall is hosted on.
    • antirez 9y ago
      Thank you, I'm not able to provide a lot of help but I would like to follow the discussion, perhaps the sensible thing to do at this point is to wait for the first beta, then probably the mailing list will be open to everybody. Thank you for replying.
    • kodablah 9y ago
      Out of curiosity, why not do the development in public? Or is there a repo I missed?
      • BruceIV 9y ago
        Most programming languages do an initial period of internal development before a public release. When I started on the project ~3 years ago, it took me about 2 weeks to work around the (then current) set of compiler bugs to make a 100-line benchmark program -- naturally a public release at that point would not have been fruitful. Today our compiler generally works, and we're looking forward to making a public release once we get a couple more features stabilized.
        • kodablah 9y ago
          I think there is a difference between working on something in public and a public release. I'm always skeptical of the claims that things can't be done transparently because it's not open to input yet. Those things are orthogonal. You don't have to work in secret just to avoid some of the issues with publicity. Granted I know it happens often, I just don't think it needs to be that way.
• emilfihlman 9y ago
  If there's one thing I would do to C it is to replace the normal datatypes with u8, u16, u32, u64 (ad infinitum) and their signed brethren s8, s16, s32, s64, ... And don't start with the stupid (u)intXX_t.
  • kurtisc 9y ago
    You could just use macros or typedefs for the the (u)intXX_t types.
    • breadbox 9y ago
      And therein lies the issue. Everyone does just that, causing needless clashes. If you're writing a library, you can either switch back to the standard type names in your external header file, or you include the typedefs/macros there as well. The former choice ruins some of the point of having these types, and might even mask cross-platform issues. The latter runs the risk of clashing with the user's owns typedefs, or with another library writer's typedefs. (And god help you if exactly one library writer chose to do it via macros.)
  • Nursie 9y ago
    They aren't stupid, and they are both standard and available on nearly every system going. People absolutely should use stdint. h I wish more would.
    • Ace17 9y ago
      > People absolutely should use stdint.h Definitely. However, you have to admit the names (uint32_t) could be made less verbose, like "u32".
      • emilfihlman 9y ago
        Exactly. We are talking about the smallest possible datatypes that build up everything here. They don't have to be named variable_typeFactory_type_signed_t.
    • 9y ago
• andrewmcwatters 9y ago
  I think C developers are harder to convince than developers who more regularly consume modern languages. I see no reason to use this over ANSI C.
  • kurtisc 9y ago
    C especially is used by EEs who are less likely to care for newer features.
    • platinumrad 9y ago
      EEs are why C89/C90 will be with us forever.
      • Gibbon1 9y ago
        Personally I don't think actual EE's doing firmware care very much for C89/C90. But I've seen CS people totally spaz when confronted by code with variable length arrays. And try to 'fix' code by removing <stdint.h>
        • platinumrad 9y ago
          It's not meant as a slight against EEs. It's just my experience that people with EE backgrounds tend to be more invested in becoming very skilled with "ANSI" C (plus whatever extensions help them get things done) while people with CS backgrounds are more likely to be interested in chasing new and "better" ways of doing things like C99 VLAs or C11 generic selection or a new language. It seems like your experience has been the opposite of mine so maybe it's wrong for me to generalize.
• naasking 9y ago
  Looks pretty ambitious. My take from skimming: * switch, if, choose and case extensions look good. * I can see the justification for labelled break/continue, but looks pretty hairy. Might discourage rethinking and refactoring to something simpler. * I'm wary of exceptions. * I don't like the 'with' clauses. * Weird to add syntax just for mutexes, but they integrate concurrency/coroutines later, so maybe it make sense. * Tuples are generally useful, but C11's unnamed structs are generally good enough, ie. instead of [int, char] you can return "struct { int x0; char x1 }" or something. * New declaration syntax is welcome, but the old syntax probably isn't going away, so I'm not sure it's a good idea. * Constructors/destructors are good. Syntax looks weird though. * Overloading is very welcome. * Not sure about operators, but they have their uses. * Polymorphism is welcome, though it looks a bit cumbersome, and it should come with a monomorphisation guarantee for C. * Traits seem like too much for a C-like language. I can see the uses, and the compiler can optimize this well, but they're probably too powerful. * Coroutines are cool. * Streams look interesting, but the overloading of | will probably be confusing.
  • DSMan195276 9y ago
    I'm more or less in agreement, but I just though it was worth adding that the tuple's could actually have a lot of merit, I think I'd like to see them (Though I'm not sure the syntax is perfect parsing wise. It might be smart to prefix them, like `tuple [int, char]` or something.). It seems like anonymous struct's fill the void, but a big problem with anonymous struct's is their types are never equal to any other, even if all the members are the exact same. So that means that if you declare the function as returning `struct { int x0; char x1; }` directly, it's actually mostly unusable because it's impossible to actually declare a variable with the same type as the return type. Obviously, the fix is to forward declare the `struct` ahead of time in a header file somewhere and then just use that type name, but that gets annoying really fast when you end-up with a lot of them. The tuples would allow you to achieve the same thing, but with a less verbose syntax and would allow them to be considered the same type even without forward declaring them.
    • naasking 9y ago
      > So that means that if you declare the function as returning `struct { int x0; char x1; }` directly, it's actually mostly unusable because it's impossible to actually declare a variable with the same type as the return type. Are you sure about that? I remember playing with this last year and structural equality seemed to work when returning structures from functions. I was using clang, so it could conceivably have been an extension... (edit: some online C compilers do indeed return an error in this case) If that's the case, then just make anonymous structs employ structural type equality and you have better tuples.
• dimman 9y ago
  "Without continued development of the language, C will be unable to cope with the needs of modern programming problems and programmers; as a result, it will fade into disuse. Considering the large body of existing C code and programmers, there is significant impetus to ensure C is transformed into a modern programming language." Really? Lots of C code written today is written using C89/C90 or C99 std. I think if it's something that history tought us it is that C does _not_ need to be transformed into something else or we would already be happily using this "something else" today.
• js8 9y ago
  Not bad, but not much to call home about either. Personally, I would like to see better support for immutability/purity and more first-class functions (does C still insists on functions to be global in scope?). Also, I think user-defined constructors/destructors are a bad idea. I generally found that any side effects that are done in constructors and destructors are a nasty source of bugs. It's almost always better to use a factory method (function), which makes user-defined constructor/destructor useless as a concept.
  • jcelerier 9y ago
    > It's almost always better to use a factory method (function), which makes user-defined constructor/destructor useless as a concept. well, no. In languages with constructors, you can enforce invariants in your class and ensure that no object that does not respect the invariants exists in your system. If you only have factory methods, you can still construct objects "normally" then nothing prevents anyone from creating another object which does not respect them. Or you can hide your struct definition in an implementation file, but then you loose the ability to construct on the stack and have to dynamically allocate, which kills performance.
    • js8 9y ago
      > In languages with constructors, you can enforce invariants in your class and ensure that no object that does not respect the invariants exists in your system Actually, it's not enough. If you can mutate the class variables (attributes), then you can always create a class that doesn't have these invariants enforced. The only way that could completely prevent invariants in the class being disrespected would be to have a strong, possibly dependent, type system. For example, consider a function (method) that takes two objects of the same class and creates another object of the same class based on the two. During the construction of the returned object, invariants can be broken, and if this function contains an error, it will return an invalid object. This is especially problematic with the RAII pattern. Because resource acquisition can fail, you have to allow for "broken" objects to be returned, which represent the resource not being acquired. In functional programming, this is done with sum types (and in general way with Maybe, for instance). I would say I am against RAII pattern, because it gives people a false sense of security, as you have to deal with the resource not being acquired anyway (either by returning object in incorrect state or by exception). But if you forfeit RAII, you might as well get rid of user constructors and use factory methods (and simple data constructors and sum types) everywhere for simplicity and consistency.
• enriquto 9y ago
  I'm all for the evolution of C, but this list... 1) has some downright idiotic things (exceptions, operator overloading) 2) has a few reasonable, but mostly inconsequential things (declaration inside if, case ranges) 3) is missing a few real improvements (closures, although it is not clear whether the "nested routines" can be returned)
  • bdamm 9y ago
    Agree 100%. Improvements to C would be things like removing "undefined behavior", not adding more syntax sugar. If anything, C's grammar is already too bloated. (I'm looking at you, function pointer type declarations inside anonymized unions inside parameter definition lists.)
    • bhasi 9y ago
      > function pointer type declarations inside anonymized unions inside parameter definition lists Could you please provide a code snippet of this kind? Hard for me to visualize otherwise. Thanks.
      • pjmlp 9y ago
        Sure, lets do it in pieces typedef int (*my_func_ptr_t)(const void*,const void*); typedef union { my_func_ptr_t func_ptr; int* data; } my_union_t; void my_func (my_union_t param); // Now exploiding it void my_func (union { int (*func_ptr)(const void*,const void*); int* data; } param); Of course this is very basic example, but there is hope to make it into an IOCC entry.
    • geezerjay 9y ago
      > Improvements to C would be things like removing "undefined behavior" This nonsense again. I don't get this "undefined behavior" cliche. It seems it became fashionable for some people to parrot it like a mantra as a form of signaling. Undefined behavior just refers to something that is not covered by the international standard, and therefore doesn't exist nor should be used, but an implementation may offer implementation-specific behavior.
• Someone 9y ago
  From https://plg.uwaterloo.ca/~cforall/features https://plg.uwaterloo.ca/~cforall/features: Exponentiation Operator New binary exponentiation operator '\' (backslash) for integral and floating-point types. 2 \ 8u; // integral result (shifting), 256 -4 \ 3u; // integral result (multiplication), -64 I hope that’s a documentation error. Otherwise, it seems designed for the “Obfuscated C for all” contest: int i = f(); int j = i \ 3u; Does what ‘\’ does really depend on the sign of i?
  • Sean1708 9y ago
    The "shifting" vs "multiplication" is just an optimisation since x * 2 == x << 1 for any positive x. As far as I'm aware shifting a negative number is undefined, which will be why they use multiplication for negatives.
• snarfy 9y ago
  C is an evolving ISO standard.[1] We are currently at C11. > The purpose of the project is to engineer modern language features into C in an evolutionary rather than revolutionary way. It's also the purpose of the standards body. Why not propose these changes to the standard? [1] - https://www.iso.org/standard/57853.html https://www.iso.org/standard/57853.html
  • pjmlp 9y ago
    Maybe because one needs to buy a seat at the table, by making a formal proposal, pay the travel expenses on their own and get to win the hearts of others members when voting comes to be.
  • jessaustin 9y ago
    There is still time, right? Lots of standards update efforts have moved in and out of ISO and IETF.
• sagichmal 9y ago
  Exception Handling Oh no :(
• rotrux 9y ago
  looks like the University of Waterloo isn't on the cloud! Anyone else having trouble accessing the site?
• jessaustin 9y ago
  Without continued development of the language, C will be unable to cope with the needs of modern programming problems and programmers; as a result, it will fade into disuse. C11 is pretty nice! C99 is too. One might think that "almost once a decade" is kind of slow for updates, but M$ have enough trouble keeping up with the current schedule. Of course TFA describes a possible direction for C2x, but they could have a more charitable attitude...
  • nine_k 9y ago
    > will fade into disuse. That's one thing I'd like C to do. It was an adequate language in 1970, but in 2018, we have a few better approaches that have a chance to turn into viable alternatives to C. Of course, I don't see C falling into disuse any time soon. The amount of critical code written in C is enormous, without a way in sight to reasonably replace. So keeping C in a good shape is important, whatever shortcomings the language may have.
    • pjmlp 9y ago
      Not even that much in 1970, if you look into old papers about the systems programming languages being used at other research institutes besides AT&T.
      • Roboprog 9y ago
        Indeed. Having started my CS degree work in the early 80s, I got to see “things other than C/C++”. In retrospect, I often jokingly refer to the 80s as “the x86/PC disaster”, an extinction level event for programming languages where the choices were to run either assembler, or C, on the IBM PC to build software of any size due to the limitations of the hardware. Rather than trying to improve curly brace languages, it’s time to bury them. For starters, hiding identifiers after arbitrarily long type expressions, instead of starting a line/block/expression with a name, is an un-fixable PITA. (Sorry, AT&T, Algol had it right) Requiring a “break” in a case statement is a botch, instead of some kind of “or” / “set” / “range” test. C is useful as a portable assembler, I guess. Otherwise I don’t really like any of C’s offspring all that much. I sort of like Javascript in spite of being forced to look like Java/C++, but that’s only because I learned some Lisp (alas, not Scheme) back in the day.
• mar77i 9y ago
  What's with the weird cryptic, trigraphish syntax for something common as constructors and destructors? How are _init(struct obj o) _cleanup(sturct o) not enough? Okay, except those rare cases when you need a _new(struct obj o).
  • BruceIV 9y ago
    [on the Cforall team] It broadly matches our other operator-overloading syntax, where the ?'s show where the arguments go, e.g. ?+? for binary addition, ?++ for postincrement and ++? for preincrement. For something as common as constructors and destructors, a concise syntax is a desirable feature.
    • andrewmcwatters 9y ago
      What I get out of this is that you like to play with languages rather than make actual things with them.
• karlding 9y ago
  Peter Buhr also teaches CS 343: Concurrent and Parallel Programming [0] at the University of Waterloo in a dialect of C++ that he has been working on [1], called uC++ [2]. [0] https://www.student.cs.uwaterloo.ca/~cs343/ https://www.student.cs.uwaterloo.ca/~cs343/ [1] https://github.com/pabuhr/uCPP https://github.com/pabuhr/uCPP [2] https://en.wikipedia.org/wiki/%CE%9CC%2B%2B https://en.wikipedia.org/wiki/%CE%9CC%2B%2B
  • BruceIV 9y ago
    [on the Cforall team] One of our Master's students has incorporated the majority of the uC++ features into Cforall as well, with some neat extensions for multi-monitor locking in a way that doesn't introduce synchronization deadlocks not present in user code.
    • filereaper 9y ago
      As an alumni, I firmly believe there's room for a 4th year course in-addition to CS343. There's quite a lot in advanced control flow which can be covered. I've always found it unfortunate that the university has courses from first year all the way to fourth year in Data Structures and Algorithms (all the way up to CS466/CS666) but Control Flow is treated like a secondary citizen.
      • BruceIV 9y ago
        [also a CS 343 TA] I personally agree with you -- if it were up to me I'd refactor CS 343 into a pair of courses, maybe focusing on high-level concurrency constructs with a follow-up course on building that sort of runtime system.
        • zodiac 9y ago
          I personally really hated the use of uC++ and would have loved to do the whole course in some MIPS dialect. I really liked how through most of second year the only language reference I really needed to look at fit on one piece of paper (https://www.student.cs.uwaterloo.ca/~cs241/mips/mipsref.pdf https://www.student.cs.uwaterloo.ca/~cs241/mips/mipsref.pdf). The uC++ language, on the other hand, is not specified anywhere except in the enormous 600 page textbook, and even then very far from fully specified (e.g. there was a builtin function called rendezvous-something, where that string literally only appeared in the book once, and it was not defined at that place)
• adrianmonk 9y ago
  Wow, they really hate object-oriented programming. It's the one thing they immediately emphasize that their language isn't, and it's the one example they give for "disadvantages of multiple legacy design-choices".
• flohofwoe 9y ago
  IMHO there are better proposals for a "better C" language which fix some of the shortcomings of original C: - http://c2lang.org/site/ http://c2lang.org/site/ - https://ziglang.org/ https://ziglang.org/ - https://nim-lang.org/ https://nim-lang.org/ As long as the language is small and has good tooling, and (most importantly) can easily interoperate with C libraries (have a look at Nim for an really awesome C integration), it doesn't matter whether it is backward compatible with C. C itself should stay what it is. A low level and simple language without surprises which is only very slowly and carefully extended. Languages that are developed "by committee" and add lots of new features quickly are usually also quickly ruined.
  • astrodust 9y ago
    The biggest problem with C is not the language but the fact that the C standard library is so anemic. Where's the "Boost" for C?
  • earenndil 9y ago
    I've written in the past about C2[1]. Nim is aimed at bit of a higher level than a "c replacement" should. I don't really know much about zig, but from what I do know, I like it. 1: https://www.reddit.com/r/programming/comments/7ugm8e/c2_c_with_cleaner_syntax_a_module_system_no/dtlz4k9/ https://www.reddit.com/r/programming/comments/7ugm8e/c2_c_wi...
• TwoBit 9y ago
  We already have this. Just use C++ and stay away from the features you don't want. If you want to enforce specific restrictions then start an effort to provide a formal C++ feature restriction specification.
• chubasco 9y ago
  I think I would prefer the Indiana Jones approach. "Leave it alone! It belongs in a museum!"
  • jokoon 9y ago
    You would be right if OS kernels were not written in C. Linux is pretty much deployed on a lot of hardware, it is still maintained, and it uses C. Granted it is not the best language, but it's simple enough to do kernel development. The same goes for cobol, it's the best paying language out there.
• filereaper 9y ago
  uWaterloo uses an in-house language to teach advanced control flow, in my days it was uC++ built by Peter Buhr in CS343. They might have opted to use C for All now. I've found it quite easy to spin up parallel tasks in uC++ if I needed both C++ and easy-to-use parallelism, the language isn't formally supported but for small student projects its pretty kick ass, also the prof who built it is just quick email away. So all I'm all in favour of C for All as an alumni, hopefully it enriches the existing curriculum.
  • BruceIV 9y ago
    [on the Cforall team -- also a CS 343 TA] We've incorporated the main uC++ feature set into Cforall, but are still using uC++ for 343; maybe in another couple years when Cforall is stabilized a bit we'll give it to the students.
• ndh2 9y ago
  From https://plg.uwaterloo.ca/~pabuhr/ https://plg.uwaterloo.ca/~pabuhr/: > The ability to write generic reusable programs, called polymorphism, is fundamental to advanced software engineering. I am interested in static type-systems providing polymorphism without the use of subtyping. The problem with subtyping is that it imposes significant restrictions on reuse when static type-checking is required. This work has resulted in a new dialect of C language, called Cforall, which adds parametric polymorphism and extensive overloading to provide a more general type-system.
• rwmj 9y ago
  Did they bother to ask any C developers what the pain points are? The kernel, qemu, libvirt, coreutils and gnulib developers really use C and POSIX to breaking point, and have some real problems that might be addressed in the language, but I don't see much evidence of those problems being addressed here. Did they study existing code bases and bugs to find out how applicable these changes are to fixing real problems?
  • vanderZwan 9y ago
    It's a research language: https://plg.uwaterloo.ca/~cforall/people https://plg.uwaterloo.ca/~cforall/people You can check the various Master Theses at the bottom of the page.
• SidiousL 9y ago
  I see they are adding an analog of the C++ iostreams, but I don't see a discussion of how to disambiguate between `sin' as in stream-in and `sin' as in the mathematical function. Really, they should introduce some kind of modules or namespaces. Of course, C++ already has namespaces and will have modules sooner or later...
• zestyping 9y ago
  There are a lot of features thrown into this language that don't seem worth the learning costs they incur. What are the problems you're really trying to fix? Focus on the things that are really important and impactful, and solve them; don't waste time on quirky features that just make the syntax more alien to C programmers. * `if` / `case` / `choose` improvements look fine, though not that important. * Exception handling semantics aren't defined. * `with` is pointless and adds gratuitous complexity to the language. * `fallthrough` / `fallthru` / `break` / `continue` are all just aliases for `goto`. It's not obvious to me that we really need them. * Returnable tuples look very nice. * Alternative declaration syntax looks like a nightmare. If we were redesigning C from the ground up, a different declaration syntax might be better, but mixing two syntaxes is a terrible, terrible idea. * References. Why? They only add confusion. * Can't make head or tail of what `zero_t` and `one_t` are about, or why they would be useful. * Units (call with backquote): gratuitous syntax, unnecessary and confusing. * Exponentiation operator: gratuitous and unnecessary.
  • SolarNet 9y ago
    > Can't make head or tail of what `zero_t` and `one_t` are about, or why they would be useful. I suspect it's the same problem C++ has/had (C++11 fixed it) with bools (see the safe bool idiom [0]). Basically treating a type like an integer (arithmetic object) and boolean (logical object) at the same time is problematic (especially for a "system" type meant for extending implicit system behavior). Because then I can do `if(BoolObject < 70)` when I only meant for `if(BoolObject)` to work (where "BoolObject" is some object evaluating to a bool, and by evaluating I mean coercing/casting). Here it looks like they approached it by making 0/1 (effectively C's false/true) different types and relying on their simpler/more-powerful type system (e.g. because they don't have to worry about C++'s insane object system). Not a terrible idea if they were otherwise actually sticking to their goal of "evolving" C (most of their features are radical departures from the language like exceptions). C++11 solved it by clarifying how implicit explicit casting [sic] of rvalues works in certain keywords (which I strongly doubt anyone can say was the simpler way of solving the problem). [0] https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Safe_bool https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms/Safe_bool
  • kragen 9y ago
• vanderZwan 9y ago
  It looks like most people here are so eager to jump on the "this feature is good, this sucks, overal I'm not impressed"-bandwagon (with the typically unwarranted strong opinions that programmers always have when it comes to this) that they didn't bother to explore the rest of the website in more detail. Go to "people" page and you see that it's a language implemented by professors, PhDs and master students from the Programming Language group at Waterloo[0][1]. Scroll down and you'll see that a number of these features came from the master thesis of a student: Alumni Ph.D. Glen Ditchfield, 1992 Thesis title: Contextual Polymorphism Masters Thierry Delisle, 2018. Thesis title: Concurrency in C∀. Rob Schluntz, 2017. Thesis title: Resource Management and Tuples in C∀. Rodolfo Gabriel Esteves, 2004. Thesis title: Cforall, a Study in Evolutionary Design in Programming Languages. Richard Bilson, 2003 Thesis title: Implementing Overloading and Polymorphism in Cforall David W. Till, 1989 Thesis title: Tuples In Imperative Programming Languages. USRA Andrew Beach, Spring 2017. Line numbering, Exception handling, Virtuals So basically, it's a research language, more-or-less developed one student at a time. [0] https://plg.uwaterloo.ca/~cforall/people https://plg.uwaterloo.ca/~cforall/people [1] https://plg.uwaterloo.ca/ https://plg.uwaterloo.ca/
• sifoo 9y ago
  If we could just sit down and agree to standardize most of the GNU extensions; nested functions, cleanup attributes and computed gotos to name some; that would take us much further than any attempt at reinventing the whole thing. I don't know if they all start misinformed, or if they get caught up in their egos along the way; but none so far has managed to produce anything that even comes close to replacing C.
• edflsafoiewq 9y ago
  Everyone wants to cripple switch by turning it into the structure variously known as cond, when, match, etc. If you can only have one, by all means, take the cond, it will be useful more often, but switch's computed goto is a very useful thing to have in reserve.
• crimsonalucard 9y ago
  >While C++ had similar goals, it has the disadvantages of multiple legacy design-choices (e.g., object-oriented) How many people agree with this statement? OO is a legacy design choice or in other words: a bad design choice. I agree with the statement, so do most modern languages like rust and golang but I wonder what do non language designers think? This statement was given as if it was obvious but many programmers who I work with still think OO is the greatest invention ever.
  • pjmlp 9y ago
    Go and Rust are also OO. There isn't such thing as the only true and single way of doing OOP. Also without OOP, good luck doing GUI programming in C++. Even Motif and GTK+ are OOP based, in C, because immediate UIs suck for anything beyond simple game UIs.
    • BruceIV 9y ago
      [on the Cforall team] FWIW, the Go docs are somewhat ambivalent on the OO nature of Go[1]. Along similar lines, our main objections to object-orientation are that, in "traditional" implementations like C++ or Java, it tightly couples a number of features that we believe would be better served by a more orthogonal design. More specifically, C++-style OO couples (1) in-memory layout of types, (2) behaviour of objects, (3) encapsulation boundaries, and (4) the hierarchical "is-a" relationship. In Cforall, (1) and (3) are handled by the usual C mechanisms of struct types and translation-unit boundaries [we go to great effort to maintain C-style separate compilation, though we will likely build a better namespace/module system at some point], (2) by traits, and (4) by a yet-to-be-implemented system of RTTI for specific "inherited" types [likely when the undergrad RA who started our exceptions implementation comes back as a Master's student this fall]. As you mention, many use-cases (including widgets in GUIs, but also abstract syntax trees in compilers) require some sort of heterogeneous collection type to work properly, and for this OO is the right model. We just don't want to force the entirety of that model on every use case, so we can just take traits when we want to write a polymorphic function over related types or an ADT like "Set" which requires its keys be sortable, or just take RTTI for exception handling, when the set of exception types we're handling is known statically, but we need to determine if the thrown exception inherits from one of the caught types. [1] https://golang.org/doc/faq#Is_Go_an_object-oriented_language https://golang.org/doc/faq#Is_Go_an_object-oriented_language
• deleted 9y ago
  [deleted]
• quelsolaar 9y ago
  This is the wrong way to go about it. The syntax is great, what is needed is updates to reflect modern hardware: -Vector types. (With arbitrary sizes not just up to vec4 for like on GPUs) -New operators like clamp, and other intrinsic. (See GLSL and modern instruction sets) -Min/max: |< >| -Dot: -Cross product: >< -Swizzle: a.3.2.1.0 -Qualifiers for warping behavior. -Standard library with cash management hints. -Define qualifiers for padding of structs to be defined. I would also argue you could change some things in the spec to make it easier for compilers to optimize, like making the calling a switch without a catching case undefined behavior. As for the syntax itself, I could find being able to type multiple break commands in a row to get out of more then one loop useful, but its not a big thing. I would probably drastically restrict the power of the pre-processor too. (If you have too much time on your hands: https://www.youtube.com/watch?v=443UNeGrFoM https://www.youtube.com/watch?v=443UNeGrFoM)
• irundebian 9y ago
  Please smart people, spent your intelligence on clean approaches such as memory-safe system programming languages such as Rust or so instead of wasting time with old broken legacy languages. I want to see secure systems before I die.
• antirez 9y ago
  I studied the documentation, basically 80 percent of what is added is not what is needed for C to become better, in my opinion.
  • kosma 9y ago
    Thousand times this. C for All is "what the language researchers want", not "what the C users need".
• msaltz 9y ago
  In my opinion, what C is lacking isn’t primarily language features - it’s: 1) a common, readable style standard that people can agree on 2) modern agreed-upon idiomatic ways to write readable and safe code. There are certainly common C idioms but many exist for historical reasons and not because they’re necessarily the best things to do, and 3) a standard library that exemplifies the above two things, provides common functionality needed between projects, and fosters a sense of community Efforts like those of the poster don’t really address these things. When I tell people I like C, the response differs depending on experience level. Less experienced people who haven’t spent time in C++ either will say “Gross, pointers”. People used to C++ will say “what about templates and constructors/destructors”, and “are you going to write your own library for vectors and maps every time?” And people who are experienced (more experienced than me) and like C have generally said that the main things they miss from C++ are constructors and destructors (and mostly destructors), and templates (but only for container types), but that they can live without them. C is a small language that can be relatively easy to write (once you pick/write a suitable stl-equivalent), and extremely easy to read (and to the extent that you can look at a line and know exactly what’s going on under the hood). IMO it should stay that way. Take a look at zproject [0] for what I think is a good effort to standardize C style and project structure. Even if you disagree with the particular design choices, the spirit of it is what I think is needed to keep people from just assuming C is for dinosaurs. [0] https://github.com/zeromq/zproject/ https://github.com/zeromq/zproject/
  • sanbor 9y ago
    I have little experience with C but my feeling is that it's a waste of time to have to deal with memory in my program. I don't just have to worry about the problem that I'm trying to solve but also about handling the memory properly. Of course there are scenarios where writing a fast and lightweight app is part of the problem but for many projects that's not the case. I'm fine with pointer arithmetic and all that but I'm not fine with the constant fear that I did some oversight and my app is going to crash and I'll have to spend time debugging what's going on.
    • Retra 9y ago
      Most programming problems are pretty trivial to solve if you're willing to ignore performance. It behooves us to realize that the main difference between mathematics and computer science is that computer scientists have to account for the several orders of magnitude difference between the runtime costs of different operations. If that weren't an obstacle, we'd basically only need one programming language, and it would like pretty much like standard mathematics. So I interpret your comment as something like "I don't want to program, I just want to assemble mathematical statements", which is a fine and perfectly legitimate thing to do, but it also seems a bit lazy, impractical, and probably irrelevant, given the subject.
• gcbw2 9y ago
  Should have fixed the easier problem first. The 'searchability' of the language name.
  • BruceIV 9y ago
    [on the team] It helps if you use the official ASCII spelling, Cforall -- a DuckDuckGo search for "Cforall" in private browsing mode pulled up our homepage first result. (I have no idea who the OP for this thread is, they're no one associated with the team.)
• throwaway45074 9y ago
  The (draft) ISO C11 spec is already nearly 700 pages[1]. How can anyone justify adding something like "choose" (a switch() without fall-throughs) to such a language? Who are these people[2], and what is their mandate? Did they actually consult with the likes of Linus Torvalds, Greg KH, Mike Pall--those who actually use C every single day on mission-critical projects like OS kernels and virtual machines--and ask them what improvements to C they need? 1) http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf 2) https://plg.uwaterloo.ca/~cforall/people https://plg.uwaterloo.ca/~cforall/people
• joshuak 9y ago
  I've had renewed interest in C recently, having been away from it for nearly 10 years. This renewed interest comes from working with golang for the last few years, and has caused me to find this book[0] which discusses ways to implement OOP ideas in pure C. Not to promote Go, or OOP, but rather I wonder if selecting useful idioms form modern languages wouldn't be a better intermediate step to updating C, then language level changes. [0] https://www.cs.rit.edu/~ats/books/ooc.pdf https://www.cs.rit.edu/~ats/books/ooc.pdf
• enriquto 9y ago
  A beautiful, and simple, addition to the C language would be a mechanism to assess the remaining stack size. This is trivial to check in assembler, but practically impossible in portable C. Indeed, thanks to VLA, the stack can be used as a clean notation for raii. You just replace this ugly, but very common, construction void f(int n) { float *x = malloc(n * sizeof*x); // ... free(x); } with this void f(int n) { float x[n]; // ... }
  • BruceIV 9y ago
    [on the Cforall team] we actually take advantage of this same VLA idiom for temporary storage for polymorphic variables. Fun fact from when we switched our implementation to use VLAs: if you call alloca() for stack memory instead, it doesn't work properly inside a loop, because it never releases the memory until the stack frame is exited.
  • pjmlp 9y ago
    VLAs were made optional in C11 as they became yet another security exploit vector, and not all C vendors are keen in supporting it, especially on the embedded space.
• Ericson2314 9y ago
  This is stupid. C accepts too many programs already. Rust mainly improves by accepting fewer. The few compatability-breaking changes this includes don't go far enough to matter.
• coldtea 9y ago
  The biggest evolution for C, to cut down bugs to 1/10 would be to have a proper built-in string type -- one that easily transforms into the relevant C type, and that keeps the size. (And maybe a vector and hashmap).
  • earenndil 9y ago
    sds? https://github.com/antirez/sds https://github.com/antirez/sds
• luckydude 9y ago
  Hmm, we took a different approach, here's my C-like dialect (built on Tcl's byte codes so it co-exists with Tcl code. And yes, I know, but we needed Tk so were stuck with Tcl). http://little-lang.org http://little-lang.org Stuff that I'd like to C in an evolved C: regexp engine as part of the language so you can do while (buf = <>) if (buf =~ /some regexp/) puts(buf); <> and <FD> from perl, just handy. Lists as a built in, with any element type and builtins like push, pop, shift, unshift, etc. Again, more perl goodness without all the @'s and $'s. ${expr} interpolation inside strings. Like shell, and it's handy. At this point I'm just typing in the L language docs, so most of the stuff here: http://www.little-lang.org/little.html http://www.little-lang.org/little.html BTW - the logo for the language is a tip of the hat to the things that inspired it: the Tcl feather logo, the Perl camel logo, and "C" all bunched together. I'm very fond of that logo but not sure that anyone but me gets it.
• halfer53 9y ago
  I'm personally in favour of this proposal, I'm sick of having to write function pointer when implementing objects in C. Looking forward to seeing this in the next C standard