Stories
Slash Boxes
Comments

SoylentNews is people

SoylentNews is powered by your submissions, so send in your scoop. Only 9 submissions in the queue.
posted by janrinok on Tuesday November 19, @07:25PM   Printer-friendly

It's memory-safe, with a few caveats:

Developers looking to continue working in the C and C++ programming languages amid the global push to promote memory-safe programming now have another option that doesn't involve learning Rust.

Filip Pizlo, senior director of language engineering at Epic Games, has created his own memory-safe flavor of C and – because why not? – named it after himself.

Pizlo got in touch after seeing our report on TrapC – a memory-safe C-fork due for release next year.

"I wanted to alert you to the existence of Fil-C, a personal project of mine, which exists today, does just about everything TrapC claims to do (including being totally memory-safe), and is freely available," Pizlo explained. "It aims for 100 percent compatibility with C and C++ – just compile your stuff with my compiler and you get memory safety."

The US government and other interested parties are rather keen to encourage memory safety – something not available out of the box for C and C++ code. C and C++ require manual memory management, which has been shown to be inadequate for preventing memory safety bugs like out of bounds reads and writes.

Since the majority of serious vulnerabilities in large codebases can be attributed to memory safety failings, the common refrain over the past few years has been to develop in a programming language like Rust that (optionally) produces memory-safe code. And more recently there have been efforts to rewrite legacy code in critical libraries and applications using Rust.

There are many other memory-safe languages – such as C#, Java, Python, Swift, Go, and JavaScript. But Rust, for better or worse, has become the most commonly cited option in memory safety evangelism because it's fast, suited for low-level code, and does a lot of things well (safe concurrency and a well-conceived package management system). What's more, the non-profit Rust Foundation has been run well enough to attract funding and support from the tech firms likely to be interested in Rust's qualities.

Also, Rust came out of Mozilla, which isn't seen by the major tech platforms – several of which have their own home-grown programming languages – as a competitor. Consider that Rust debuted in late 2013 and Apple's Swift arrived a year later – during that period, Rust has attracted a broad constituency, while Swift is mainly used by Apple-aligned developers.

But the thing about Rust is that it's not all that easy to learn. So calls to rewrite everything in Rust have elicited pushback from those with significant C or C++ experience – like Linux kernel maintainers, who would prefer to continue working in languages they've mastered.

Like the forthcoming TrapC fork and the Safe C++ project, Fil-C aims to support memory safety without requiring reeducation in another programming language.

[...] Fil-C has some limitations. Presently, it only works on Linux/x86_64. Also, it's slow – about 1.5x-5x slower than legacy C. That's in part because of its implementation of a pointer encoding method for tracking bounds and types called MonoCaps, and also overhead from calling conventions and dynamic linking that differ from standard C.

"The plan to make Fil-C fast is to fix these issues," explains Pizlo. "I believe that fixing these issues can get Fil-C to be only 1.5x slower than C in the worst cases, with lots of programs being only 1.2x slower. But it'll take some focused compiler/runtime/GC hacking to get there."

[...] Pizlo observes in his presentation that while there have been substantially successful attempts to make C code memory-safe – such as CheckedC and -fbounds-safety – many of these fall short in one way or another, particularly for certain edge cases.

His goal, he says, is to support garbage in, and memory safety out.

"Part of the reason why I'm doing this is I want to obviate the need for Rust," declares Pizlo. "I'm not there yet performance-wise, but I will get there."


Original Submission

This discussion was created by janrinok (52) for logged-in users only, but now has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
  • (Score: 1, Interesting) by DadaDoofy on Tuesday November 19, @08:18PM (16 children)

    by DadaDoofy (23827) on Tuesday November 19, @08:18PM (#1382507)

    If you can't do it with C#, Swift or Java, it probably doesn't need doing. The rest are just needless distractions that fragment the pool of developers and make code more expensive to maintain.

    • (Score: 5, Insightful) by JoeMerchant on Tuesday November 19, @08:29PM

      by JoeMerchant (3937) on Tuesday November 19, @08:29PM (#1382508)

      All depends on your scope...

      We've got battery powered devices running ESP32 micros, they're not a great C#/Swift/Java target - I mean, I bet you _can_ run those languages there, but if you value performance, not just speed but also battery life, you'll probably get a significant bump in any project by switching to the existing C libraries.

      I looked into migrating out of Qt/C++ to Qt/Python - it went pretty well, only lost about 2% speed throughout the UX development, but then I got to a tight loop computation that is nothing in C or C++, but runs 1000x slower in Python. Yeah, so that part needs to be written in C++ and imported as a dependency-hell library object. So, I'm still writing C++, in addition to Python, adding a whole extra layer of complexity to the overall build and project management, and I have gained what? Maybe I can turn over the Python part of the code base to somebody who is afraid of C++?

      When the toolset around Rust matures to the level that C/C++ toolsets have (like when hell freezes over x6), then it should be an easy switch.

      --
      🌻🌻 [google.com]
    • (Score: 3, Funny) by gawdonblue on Tuesday November 19, @08:35PM (4 children)

      by gawdonblue (412) on Tuesday November 19, @08:35PM (#1382510)

      If you can't do it with Fortran or COBOL, it's not worth doing.

      Kids these days.

      • (Score: 2) by turgid on Tuesday November 19, @09:37PM (3 children)

        by turgid (4318) Subscriber Badge on Tuesday November 19, @09:37PM (#1382523) Journal

        Real men program in FORTRAN and assembler (IBM360).

        • (Score: 3, Interesting) by JoeMerchant on Tuesday November 19, @11:37PM (2 children)

          by JoeMerchant (3937) on Tuesday November 19, @11:37PM (#1382542)

          I had several jobs translating Fortran and Matlab code into "modern user facing" Qt/C++. Probably drew $500k in salary over the years on those kinds of jobs.

          --
          🌻🌻 [google.com]
          • (Score: 0) by Anonymous Coward on Tuesday November 19, @11:49PM (1 child)

            by Anonymous Coward on Tuesday November 19, @11:49PM (#1382543)

            > Probably drew $500k in salary over the years on those kinds of jobs.

            Just curious, was it closer to $100K/year for 5 years? or closer to $500K in one year??

            • (Score: 0) by Anonymous Coward on Wednesday November 20, @09:04PM

              by Anonymous Coward on Wednesday November 20, @09:04PM (#1382626)

              I knew a COBOL programmer who was getting $300 an hour back in 1998-9, and had more customers than he could handle.
              I think that period pretty much set him up to retire whenever he felt like it.

    • (Score: 3, Touché) by Snotnose on Tuesday November 19, @11:03PM (5 children)

      by Snotnose (1623) on Tuesday November 19, @11:03PM (#1382539)

      I have a register at 0xf0001342 and I need to set bit 4. Show me how to do that in Java.

      --
      Is anyone surprised ChatGPT got replaced by an A.I.?
      • (Score: 3, Funny) by Anonymous Coward on Tuesday November 19, @11:52PM

        by Anonymous Coward on Tuesday November 19, @11:52PM (#1382544)

        > Show me how to do that in Java.

        Lots of AI answers out there, they are, of course, looking forward to serving you!

      • (Score: 1, Redundant) by DannyB on Wednesday November 20, @06:02PM

        by DannyB (5839) Subscriber Badge on Wednesday November 20, @06:02PM (#1382609) Journal

        If your problem domain involves thinking about bits in registers, then Java, C# and many other languages do not fit your problem domain.

        If your problem domain is, say, designing a payroll system that must comply with Federal and man State regulations, forms, requirements, submission formats, and handle all sorts of payroll problems for different types of people and how they are paid, then a low level bit-manipulation language is not a good fit for that problem domain. In this case, a language which makes it IMPOSSIBLE to make a memory management or pointer error is a much better fit.

        If there were one perfect programming language for all porpoises, we would all already be using it.

        If a language is popular and widely used (like C, or like Java), then it MUST BE DOING SOMETHING RIGHT or so many people wouldn't be using it. It must be solving someone's real world problems in a beneficial way. Does that even make sense?

        --
        Satin worshipers are obsessed with high thread counts because they have so many daemons.
      • (Score: 0) by Anonymous Coward on Wednesday November 20, @09:10PM (2 children)

        by Anonymous Coward on Wednesday November 20, @09:10PM (#1382627)

        10 A=PEEK(0xf0001342)
        20 A=A+8
        30 POKE (0xf0001342,A)

        • (Score: 2) by Snotnose on Wednesday November 20, @10:28PM (1 child)

          by Snotnose (1623) on Wednesday November 20, @10:28PM (#1382644)

          Nice try but no cigar. If the bit was already set then adding 8 not only clears the bit, but sets the next higher bit.

          My question was rhetorical If you're bit banging you're probably in the embedded space. If you're in the embedded space Java's garbage collection is going to be a much bigger headache.

          --
          Is anyone surprised ChatGPT got replaced by an A.I.?
          • (Score: 0) by Anonymous Coward on Thursday November 21, @08:57PM

            by Anonymous Coward on Thursday November 21, @08:57PM (#1382759)

            :( I was trying for funny.

    • (Score: 0) by Anonymous Coward on Tuesday November 19, @11:56PM (2 children)

      by Anonymous Coward on Tuesday November 19, @11:56PM (#1382545)

      WTF? I can write real-time anything in those shit languages.

      • (Score: 0) by Anonymous Coward on Tuesday November 19, @11:59PM (1 child)

        by Anonymous Coward on Tuesday November 19, @11:59PM (#1382546)

        GD non-editable comments. I mean, "can't."

        • (Score: 2) by DadaDoofy on Wednesday November 20, @01:43AM

          by DadaDoofy (23827) on Wednesday November 20, @01:43AM (#1382559)

          You seem to be implying real time solutions can't be written in languages that are memory safe. If that is the case, it's only a matter of time until new hardware makes that not the case.

          For instance, United Audio had a whole line of hardware products that ran their audio plugins in order to surpass the internal processing capabilities of PCs at that time. Later, Apple's M processors obsoleted all that by matching, and then with later generations of their M processors, vastly exceeding that performance making that purpose-built hardware completely obsolete.

    • (Score: 2) by Freeman on Wednesday November 20, @02:55PM

      by Freeman (732) on Wednesday November 20, @02:55PM (#1382592) Journal

      Swift is below a heap of other languages. https://spectrum.ieee.org/top-programming-languages-2024 [ieee.org]

      Ah, found the reason I'd barely even heard of it: https://en.wikipedia.org/wiki/Swift_(programming_language) [wikipedia.org]

      Swift was introduced at Apple's 2014 Worldwide Developers Conference (WWDC).

      I've yet to be suckered into that particular walled garden, besides having been given an iphone or two. Free is free.

      --
      Joshua 1:9 "Be strong and of a good courage; be not afraid, neither be thou dismayed: for the Lord thy God is with thee"
  • (Score: 5, Touché) by Thexalon on Tuesday November 19, @08:31PM (4 children)

    by Thexalon (636) on Tuesday November 19, @08:31PM (#1382509)

    This would be similar to the classic anti-spam idea checklist [craphound.com]:


    Your article advocates a new
        (X) language variant ( ) library ( ) compiler ( ) testing approach
    to prevent problems with bad memory access in C. Your idea will not work. Here is why it won't work.
    ( ) You need to offer the low-level control of C in order to replace C
    ( ) Code analyzers not understanding edge cases
    (X) The importance and impact of inline assembler blocks
    (X) Taking the time to rewrite working code will never get management approval
    Specifically, your plan fails to account for
    (X) Sometimes you really do need to do pointer math
    (X) Software performance expectations
    (X) Huge existing software investment in C
    ( ) Technically illiterate management
    ( ) Additional compile time leading to programmer inefficiency
    and the following philosophical objections may also apply:
    (X) Ideas similar to yours are easy to come up with, yet none have ever
    been shown practical
    ( ) C++ sucks
    ( ) interpreters suck
    Furthermore, this is what I think about you:
    (X) Sorry dude, but I don't think it would work.
    ( ) This is a stupid idea, and you're a stupid person for suggesting it.
    ( ) Nice try, assh0le! I'm going to find out where you live and burn your
    house down!

    I'm sure that checklist is incomplete, but it seems like a start.

    --
    "Think of how stupid the average person is. Then realize half of 'em are stupider than that." - George Carlin
    • (Score: 4, Funny) by AnonTechie on Tuesday November 19, @08:37PM (1 child)

      by AnonTechie (2275) on Tuesday November 19, @08:37PM (#1382511) Journal

      Maybe they could start a MCGA (Make C Great Again) campaign ... Just a thought

      --
      Albert Einstein - "Only two things are infinite, the universe and human stupidity, and I'm not sure about the former."
      • (Score: 0) by Anonymous Coward on Tuesday November 19, @08:53PM

        by Anonymous Coward on Tuesday November 19, @08:53PM (#1382512)

        > Maybe they could start a MCGA (Make C Great Again) campaign ...

        First step, fill out the questionnaire for "make", adding a category for build automation tools...

    • (Score: 0) by Anonymous Coward on Wednesday November 20, @12:21AM (1 child)

      by Anonymous Coward on Wednesday November 20, @12:21AM (#1382551)

      Also, a name that doesn't sound awfully close to "filthy" would help...

      • (Score: 2) by driverless on Wednesday November 20, @02:39AM

        by driverless (4770) on Wednesday November 20, @02:39AM (#1382561)

        Zat iss only because you have zer filc mind!

  • (Score: 5, Funny) by VLM on Tuesday November 19, @08:53PM (1 child)

    by VLM (445) on Tuesday November 19, @08:53PM (#1382513)

    Also, Rust came out of Mozilla

    Isn't Go's marketing pretty much that its the Rust for the non-trans people?

    • (Score: 0) by Anonymous Coward on Wednesday November 20, @07:41PM

      by Anonymous Coward on Wednesday November 20, @07:41PM (#1382617)

      Go atleast looks like a normal language.

  • (Score: 4, Touché) by ikanreed on Tuesday November 19, @09:02PM (1 child)

    by ikanreed (3164) Subscriber Badge on Tuesday November 19, @09:02PM (#1382514) Journal

    Gonna stop you there. When I'm writing C code, I'm usually not writing for some general architecture, I'm usually targeting some super-specific piece of hardware, with its own caveats and whose manufacturer publishes a C compiler that covers the big headaches of their platform.

    So it's wonderful you managed to get your x86 compiler running, but you've done jack and shit to take over all the things people need C for.

    • (Score: 3, Insightful) by Anonymous Coward on Tuesday November 19, @10:14PM

      by Anonymous Coward on Tuesday November 19, @10:14PM (#1382530)

      So it's wonderful you managed to get your x86 compiler running, but you've done jack and shit to take over all the things people need C for.

      Without actually checking if this compiler actually works as claimed I think this is not actually a problem.

      Reading between the lines of Manifesto.md the compiler appears to be a mostly-normal C compiler based on fat pointers with garbage collection, so this should means we can build our standard C programs on (as yet unimplemented) FIL-OS with FIL-C running on whatever hardware, while we can still (maybe) build those same programs on our vintage Unisys systems with their 40-bit sign+magnitude integers.

      The real practical problem is that (on any system!) most normal people don't want to eat a 5× performance penalty compared to a normal compiler, but some users might find that acceptable.

  • (Score: 4, Insightful) by turgid on Tuesday November 19, @09:35PM (7 children)

    by turgid (4318) Subscriber Badge on Tuesday November 19, @09:35PM (#1382522) Journal

    So calls to rewrite everything in Rust have elicited pushback from those with significant C or C++ experience – like Linux kernel maintainers, who would prefer to continue working in languages they've mastered.

    It has been well known for many decades now (two at least, maybe three even) that rewriting all your code in a different language isn't the answer to all your problems.

    There was a famous case well documented where Borland IIRC dropped the ball on its office productivity software (yes, they had a spreadsheet and word processor) proudly announcing the next version would be "all new code." It was late and didn't work and Microsoft Word and Excel cornered the market.

    What really matters is understanding software engineering. That means understanding how to design, implement, test and optimise programs in any language. Yes, some languages buy you advantages, but throwing away all your code, unless it is truly dreadful, and starting again is not a good idea.

    If you understand the issues, and if you understand your product, and if you have the institutional knowledge and good test harnesses, process and infrastructure, you are 90% of the way there.

    I wish I had more time to play with Rust but I keep getting dragged back into the C++ world. I crossed that event horizon and I'm condemned to orbit. I did not rewrite all my C code in C++. I investigated some years ago and concluded it was the wrong way to go. C compilers kept getting better. C++ kept diverging and getting more complicated.

    Choose good tools for the language you need to use. Use a good C compiler. Use a good C++ compiler. Yes, use Rust if it suits your purpose. Don't throw away your old working code because of the new fad. You should be able to get code written in different languages to speak to each other. If you can't that's an infrastructure problem.

    I don't write shell scripts in C and I don't write C in shell scripts.

    • (Score: 2) by driverless on Wednesday November 20, @02:45AM (2 children)

      by driverless (4770) on Wednesday November 20, @02:45AM (#1382563)

      It was late and didn't work and Microsoft Word and Excel cornered the market.

      Microsoft did it too with their attempted Word rewrite (Project Pyramid).

      And that's not even getting into the near-infinite number of projects based on "let's rewrite all this old crap in the currently trendy language/methodology/whatever", which invariably fail after burning through tens or hundreds of millions of dollars (did Taligent break the billion-dollar mark?).

      • (Score: 2) by turgid on Wednesday November 20, @09:21AM (1 child)

        by turgid (4318) Subscriber Badge on Wednesday November 20, @09:21AM (#1382573) Journal

        Remember the project in 1997 to rewrite Linux in C++ "because reasons?"

        • (Score: 3, Insightful) by driverless on Wednesday November 20, @09:37AM

          by driverless (4770) on Wednesday November 20, @09:37AM (#1382576)

          And then just when they'd finished they'd have had to rewrite it all again in C++'98. And then as they were completing that C++'03 came along. And just as they were sitting back it was C++ '11. And then another rewrite for C++'14. And then again for C++'17. And they'd probably still be working on the C++'20 update right now.

          Thing is, C++ isn't a goal but a moving target. Which is another argument for C, it's actually pretty stable.

    • (Score: 2) by bzipitidoo on Wednesday November 20, @05:46AM (3 children)

      by bzipitidoo (4388) on Wednesday November 20, @05:46AM (#1382570) Journal

      > but throwing away all your code, unless it is truly dreadful, and starting again is not a good idea.

      The developers of Doom disagree with that sentiment. They very much advocate making multiple fresh starts.

      • (Score: 2) by turgid on Wednesday November 20, @08:02AM (2 children)

        by turgid (4318) Subscriber Badge on Wednesday November 20, @08:02AM (#1382572) Journal

        So by definition, their code got into a dreadful state, where it was unmaintainable. It became so complex it could no longer be enhanced.

        • (Score: 3, Touché) by janrinok on Wednesday November 20, @09:40AM (1 child)

          by janrinok (52) Subscriber Badge on Wednesday November 20, @09:40AM (#1382577) Journal

          Or it was written in a language that too few people are willing to support nowadays e.g. Perl?

          --
          I am not interested in knowing who people are or where they live. My interest starts and stops at our servers.
          • (Score: 0) by Anonymous Coward on Sunday November 24, @02:39AM

            by Anonymous Coward on Sunday November 24, @02:39AM (#1383116)
            Perl is still supported. Python 2, vbscript, various old versions of Java and .Net not so much. Similar vs the various popular "frameworks" which have a shelf life of months.
  • (Score: 2) by bart9h on Tuesday November 19, @10:52PM (2 children)

    by bart9h (767) on Tuesday November 19, @10:52PM (#1382536)

    Correction: C++ allows manual memory management, but do not require it.

  • (Score: 3, Funny) by Anonymous Coward on Wednesday November 20, @12:02AM (5 children)

    by Anonymous Coward on Wednesday November 20, @12:02AM (#1382547)

    C and C++ are already great. Those other toy languages are for janitors that want to be programmers but real languages are too hard.

    • (Score: 3, Insightful) by HiThere on Wednesday November 20, @12:16AM (4 children)

      by HiThere (866) on Wednesday November 20, @12:16AM (#1382550) Journal

      Neither C nor C++ handle unicode well. (When I need to write custom routines to parse characters, it's not well done.) Java is also inferior because of it's commitment to 16-bit unicode. Unicode code should be either utf8 or utf32. This is handled well by D, Python, and perhaps Vala that I know of, so it's possible.

      --
      Javascript is what you use to allow unknown third parties to run software you have no idea about on your computer.
      • (Score: 2, Informative) by Anonymous Coward on Wednesday November 20, @04:57AM (1 child)

        by Anonymous Coward on Wednesday November 20, @04:57AM (#1382566)

        Unicode code should be either utf8 or utf32

        Nonsense. Using UTF-32 for anything is pure crazy talk. Code points outside the BMP (code points above U+FFFF) are exceptionally rare in basically all text, so choosing to use UTF-32 as an internal representation over UTF-16 makes basically all your text take twice as much memory and you gain virtually nothing in return for that. Effectively, you are just throwing away half of your processor cache by choosing this representation.

        UTF-8 is an quite reasonable choice if you expect to handle primarily ASCII characters (code points below U+0080), which is only really appropriate for English text and computer programs. But for basically any other languages/scripts it is the same or worse, with many scripts (like basically all Asian scripts) taking 1.5× as much memory. In those cases, you are effectively throwing away a third of your processor cache by choosing this representation.

        • (Score: 3, Funny) by dwilson on Wednesday November 20, @05:12AM

          by dwilson (2599) Subscriber Badge on Wednesday November 20, @05:12AM (#1382567) Journal

          Well, jeeze. If you're going to be Like That, I'll use UTF-64, just out of spite.

          ...

          well, maybe not.

          --
          - D
      • (Score: 2) by Freeman on Wednesday November 20, @03:01PM

        by Freeman (732) on Wednesday November 20, @03:01PM (#1382593) Journal

        Sweet, I knew Python was good for something! Kidding aside, I use python, because it's reasonably simple, free/open-source, and is very popular. Most of the same reasons why RaspberryPi is the tinkerer's choice of Single Board Computers. Yes, you could get a BananaPi, but when something breaks/goes wrong. What resource are you going to turn to for help? Whereas with RaspberryPi there's a wealth of information out there. Including the RaspberryPi Forums, Magazine, and actual books.

        --
        Joshua 1:9 "Be strong and of a good courage; be not afraid, neither be thou dismayed: for the Lord thy God is with thee"
      • (Score: 2) by turgid on Wednesday November 20, @10:11PM

        by turgid (4318) Subscriber Badge on Wednesday November 20, @10:11PM (#1382639) Journal

        Neither C nor C++ handle unicode well.

        C was designed in the olden days when there was ASCII and EBCDIC and all sorts of random standards. It's funny getting old. When I first started out programming computers, the idea was that you'd get a compiler and interpreter for whatever language, and it would come with enough to get you going and then you would need to write your own library routines to perform whatever it was that you needed.

        I am somewhat perplexed these days, with the Internet and FOSS, that we are still scratching around in the dirt for libraries to implement common things. There are all sorts of frameworks and toolkits and standards and stuff but what do any of them actually do?

  • (Score: 4, Insightful) by shrewdsheep on Wednesday November 20, @09:26AM (2 children)

    by shrewdsheep (5215) on Wednesday November 20, @09:26AM (#1382575)

    This project takes a dynamic approach to memory safety. As far as I can see, this goal can nevertheless not be achieved under realistic scenarios. Use after free cannot be prevented when memory is re-used, at least not in general. A dangling pointer might later point to a newly created object.

    I was disappointed as I was hoping for (minimal) syntax extensions to allow static ownership checking (like in Rust). This might become a tool to catch memory problems during fuzzing and general testing. It does not meaningfully compare to Rust. A "nice try, but try again" situation, IMHO.

    • (Score: 1, Interesting) by Anonymous Coward on Wednesday November 20, @10:13PM

      by Anonymous Coward on Wednesday November 20, @10:13PM (#1382641)

      Yes, if I were going to take some ideas from Rust and incorporate them in to C, it would be via warnings and/or new type qualifiers.

      I know there are some aggressive static checkers out there for C. I wonder how close they come to enforcing rules comparable with Rust. I've seen my share of C code that spits out way too many warnings when compiled with -Wall. It's a code smell when I add that and get too much. Before people re-write all their C in Rust, maybe they should start there. Way too many people don't even use the tools available. Compile with -Wall on day 1, and 10 years later when it's 100k lines, you'll be glad you did.

    • (Score: 3, Insightful) by Rich on Thursday November 21, @04:58PM

      by Rich (945) on Thursday November 21, @04:58PM (#1382722) Journal

      This might become a tool to catch memory problems during fuzzing and general testing

      Indeed. I think the USP for it is "zero cost for using". I looked around whether it's possible to still use "free", but in a way that just marks a block until the collector sweeps it up, and until then, it would trip any inappropriate use. This would allow running your development on FilC and revert to standard when shipping source. Relying on the collector would make it one-way.

      The guy has his head full of garbage collection knowledge, and the collector that comes with FilC seems to be peak state of the art. Where C matters most these days, in kernel drivers, and embedded, such a collector would usually be too heavy to be brought in, both from memory and threading requirements. But for a desktop C++ application, it seems to be a really good thing. Definitely worth keeping an eye on, especially where Valgrind is not an option (e.g. recent macOS).

      I've had my own thoughts on how to deal with these C shortcomings, and it would be possible to offer a debug mode that keeps every pointer as unique ID, plus offset. The ID points into a hash table, if it isn't there, it's use-after-free. If it's there, it gets the base address and does a range check. That'd be slower than his approach (and therefore not really low-level production grade), but it'd be way faster than Valgrind, and probably even faster than anything Python.

      We've got to accept that all this comes from his GC experience, and is centered around it, and for free, both in investment and development overhead, it's not a bad offering at all.

      My own approach would work up from eliminating all "undefined behavior" situations (which is a larger scope than his memory safety) and require worse changes that break source compatibility to some extent, making it much less appealing to a wider audience. For memory safety, I'd use atomic ref counting (tiny constant-time overhead suitable for real-time) and handwave away the "it won't catch cycles" objection with the argument that the halting problem for execution cycles can't be solved, so why should we solve it for memory. I'd just offer a cycle catcher as debug tool. I guess that'd end up halfway between C and Vala (which I think is a very good language, just without the marketing support of whining academic pussies from the US).

(1)