Can TrapC Fix C and C++ Memory Safety Issues? (infoworld.com) 99
"TrapC, a fork of the C language, is being developed as a potential solution for memory safety issues that have hindered the C and C++ languages," reports InfoWorld.
But also being developed is a compiler named trapc "intended to be implemented as a cybersecurity compiler for C and C++ code, said developer Robin Rowe..." Due by the end of this year, trapc will be a free, open source compiler similar to Clang... Rowe said.
TrapC has pointers that are memory-safe, addressing the memory safety issue with the two languages. With TrapC, developers write in C or C++ and compile in TrapC, for memory safety...
Rowe presented TrapC at an ISO C meeting this week. Developers can download a TrapC whitepaper and offer Rowe feedback. According to the whitepaper, TrapC's memory management is automatic and cannot leak memory. Pointers are lifetime-managed, not garbage-collected. Also, TrapC reuses a few code safety features from C++, notably member functions, constructors, destructors, and the new keyword.
"TrapC Memory Safe Pointers will not buffer overrun and will not segfault," Rowe told the ISO C Committee standards body meeting, according to the Register. "When C code is compiled using a TrapC compiler, all pointers become Memory Safe Pointers and are checked."
In short, TrapC "is a programming language forked from C, with changes to make it LangSec and Memory Safe," according to that white paper. "To accomplish that, TrapC seeks to eliminate all Undefined Behavior in the C programming language..."
"The startup TRASEC and the non-profit Fountain Abode have a TrapC compiler in development, called trapc," the whitepaper adds, and their mission is "to enable recompiling legacy C code into executables that are safe by design and secure by default, without needing much code refactoring... The TRASEC trapc cybersecurity compiler with AI code reasoning is expected to release as free open source software sometime in 2025."
In November the Register offered some background on the origins of TrapC...
But also being developed is a compiler named trapc "intended to be implemented as a cybersecurity compiler for C and C++ code, said developer Robin Rowe..." Due by the end of this year, trapc will be a free, open source compiler similar to Clang... Rowe said.
TrapC has pointers that are memory-safe, addressing the memory safety issue with the two languages. With TrapC, developers write in C or C++ and compile in TrapC, for memory safety...
Rowe presented TrapC at an ISO C meeting this week. Developers can download a TrapC whitepaper and offer Rowe feedback. According to the whitepaper, TrapC's memory management is automatic and cannot leak memory. Pointers are lifetime-managed, not garbage-collected. Also, TrapC reuses a few code safety features from C++, notably member functions, constructors, destructors, and the new keyword.
"TrapC Memory Safe Pointers will not buffer overrun and will not segfault," Rowe told the ISO C Committee standards body meeting, according to the Register. "When C code is compiled using a TrapC compiler, all pointers become Memory Safe Pointers and are checked."
In short, TrapC "is a programming language forked from C, with changes to make it LangSec and Memory Safe," according to that white paper. "To accomplish that, TrapC seeks to eliminate all Undefined Behavior in the C programming language..."
"The startup TRASEC and the non-profit Fountain Abode have a TrapC compiler in development, called trapc," the whitepaper adds, and their mission is "to enable recompiling legacy C code into executables that are safe by design and secure by default, without needing much code refactoring... The TRASEC trapc cybersecurity compiler with AI code reasoning is expected to release as free open source software sometime in 2025."
In November the Register offered some background on the origins of TrapC...
Re:What problem does this solve? (Score:5, Interesting)
Erm, C has memory safety issues coming out of the wazoo. Double frees, null pointers, buffer overflows are all endemic to C (and C++) programs. You can confirm this by looking at the CVE database. Even the Linux kernel. If projects like kernel, openssl suffers from these issues then guaranteed every other project does. There are some mitigations to issues like using static analysis tools but everything is unsafe by default and that will never change.
Re: (Score:2)
What is the point of adding memory safety to C though? It's a language for low level system programming, where the overhead of all that stuff becomes an issue. You don't want to break the close coupling of the language and the resulting assembly code, which is one reason why C++ isn't very popular for that kind of thing.
If you want that stuff there is Rust or languages like C#. What is the benefit of adding it to C? Retrofitting older apps perhaps?
Re: (Score:3)
Personally I don't believe there is a point, at least not unless you have existing, isolated, specific piece of C code where the benefit of TrapC (pointer hygiene) outweighs the downside (additional runtime overhead). In which case maybe there is a case for wanting to recompile it.
I certainly see no reason to use C or C++ for any new code without a compelling reason. Rust has safety baked into it and also the conveniences of a modern language. It certainly has a learning curve especially for people with ing
Re: (Score:2)
"Rust has safety baked into it and also the conveniences of a modern language"
A modern language with a half arsed low power OO paradigm that looks suspiciously similar to python's. When its got the functionality of modern C++ in that respect get back to me.
Re: (Score:2)
Many of the issues of C++ are caused by it's "OO paradigm". Do you know the rule of 3? The rule of 5? The side effects associated with constructors like type coercion? Or the difference & dangers of destructors vs virtual destructors? Or why C++ has bullshit an explicitly delete declaration of a constructor? Or fragile base classes? Or the dangers of polymorphism?
Rust does have traits and encapsulation. It doesn't have inheritance or polymorphism. Probably after seeing the issues these caused in C++ wit
Re: (Score:2)
Yes to all of the above. Did you think real OO is meant to be simple? And you don't have to use all the features of C++ all the time.
"Or why C++ has bullshit an explicitly delete declaration of a constructor?"
Are you for real? Do you have a clue or did you borrow it from someone for the day?
"It doesn't have inheritance or polymorphism"
Which is half the useful features of OO out the window and if you claim they're unimportant I'll claim you have no real idea about OO.
"But for now Rust favours composition ove
Re: (Score:2)
And you don't have to use all the features of C++ all the time.
You can't pick and choose features if you're working on code you didn't write.
Re: (Score:3)
Irrelevant. You couldn't use Rust or some other "safe" language if the project is already written in C++ anyway.
Re: (Score:2)
Are you for real? Do you have a clue or did you borrow it from someone for the day?
Yes. I've suffered this crap FOR REAL for a long time. All of the things I asked above are clearly traps set in the language and a source of bugs and since you don't recognize that, it is YOU have no clue.
The rationale for delete on a constructor is to disable the default constructor. Ah but did you remember to delete the assignment operator too? What about your rule of 3 / 5? What about the inheritance? And what do all these
Re: (Score:2)
"Yes. I've suffered this crap FOR REAL for a long time."
Says someone who's clearly a 3rd rate programmer.
" it is YOU have no clue"
Sure sonny, whatever you say. I've been doing OO for 35 years including Smalltalk and a number of other languages that you won't even have heard of and while C++ has its issues its class based inheritence OO model is fare superior to the spaghetti code and object type explosion that composition OO gives rise to. But I wouldn't expect you to understand that.
"And what do all these
Re: (Score:2)
I get it. You're Super Programmer and an arrogant entitled dick. A person with more humility, sense and experience of these issues would recognize them and acknowledge attempts to fix those issues. But not you, because you're Super Programmer. And an arrogant entitled dick.
Re:What problem does this solve? (Score:5, Interesting)
cheri or bust (Score:2)
without hardware support
your done
https://en.wikipedia.org/wiki/Capability_Hardware_Enhanced_RISC_Instructions
Re: (Score:3)
This is true, but it was also the default language for a generation of programmers so there's a lot of legacy code which isn't low-level system programming.
Re: (Score:2)
More modern languages are a better solution to that problem. C is enduring because it offers compelling features for a lot of ongoing programming tasks, C is NOT Cobol, that "generation of programmers" is not the concern.
This solution may offer an easy transition to compile the C source to object, but it drops a great big shit on linking the object to generate a target. It's a huge burden to those "ongoing programming tasks".
Re: (Score:1)
If it has some of the benefits of valgrind (or similar) runtime checking, but quick enough to use in production, and can be mixed with (trusted) unsafe C/C++ for the performance critical portions (hot loops). Undermines the value of Rust, at least a bit.
Re: (Score:2)
You don't want to break the close coupling of the language and the resulting assembly code, which is one reason why C++ isn't very popular for that kind of thing.
C++ produces assembly code as predictable as C. You can compile it for ATTiny if you like and it runs perfectly well. The mapping from C++ to C is simple (with some exceptions hehehehe, though the complexity there is due to the Itanium ABI making an extremely biased optimization in favour of the non throwing path at the expense of the throwing path
Re: (Score:2)
It actually sounds like they've done a nice job and put in some features into "trapc" to entice regular C programmers to consider a switch. But yes, it's an incompatible fork, by necessity.
But that said I don't agree with most of your criticisms. This is still a systems programming language, just not one that you might use to write the low level part of a process scheduler. But should you write a process scheduler in C in the first place? Half the part of the language you'll end up having to use is "undefin
Re: (Score:2)
It is likely, by the deployment numbers, the most popular compiler there is for it, in fact, as all android kernels are compiled with it.
How do you ensure you can poke at memory if the compiler's going to take one look at it and silently discard what you wrote like Google trying to search for something it doesn't know much about.
Because you knew what you were doing and used the volatile keyword.
Re: What problem does this solve? (Score:2)
What is the point of adding memory safety to C though? It's a language for low level system programming, where the overhead of all that stuff becomes an issue.
Rust does all of this without carrying any overhead at all. This is exactly why it's permitted in the kernel, and part of why C++ is not (its smart pointers are not zero cost.)
Re:What problem does this solve? (Score:5, Interesting)
"Double frees, null pointers, buffer overflows are all endemic to C (and C++) programs."
Technically, buffer overflows and null pointers are inherent to "direct memory manipulation" so you haven't responded to the OP's comment there, and "double frees" are associated with a library, not with C itself. C does not have malloc/free, its standard library does. I've done projects that don't use libc, no "double frees" in that code by definition.
Having problems that are endemic to "programs" is not the same as having problems endemic to the language. The OP questions the value of modifying the language. Memory safety is a programmer quality problem, not a language problem, so it is valid to question building in crutches in a language that is valued specifically because it enables techniques those crutches work against. Memory safety features makes sense for some languages, but not all.
I doubt double frees are endemic to the linux kernel. The problem here is that you talk about a topic for which you are familiar but not sufficiently experienced.
"TrapC reuses a few code safety features from C++, notably member functions, constructors, destructors, and the new keyword."
Sounds terrible. If constructors and destructructors added to base types in C, that impacts the runtime in negative ways. Embedding C++ is more complex than C, in this regard it is the worst of both worlds. What they're saying is they're integrating classes into C. No thanks.
Re: (Score:2)
I doubt double frees are endemic to the linux kernel. The problem here is that you talk about a topic for which you are familiar but not sufficiently experienced.
Ah yes the Linux kernel has never [mitre.org] suffered a double free. Lol. Dozens of these issues in the last year made it to production code and merited a CVE.
And these issues ARE caused by the language. Even the best programmers working on code receiving the highest level of scrutiny still see these issues enter production code. But maybe you are Super Progr
Re: (Score:2)
Double frees [rustsec.org] are apparently endemic to Rust as well
Dude, why the fuck are you cheerleading when you're so fucking ignorant on the topic?
Like 25% of Rust's std:: namespace is unsafe.
Re: (Score:2)
If you're going to be pedantic, then pregnant right...
Double frees are associated with C, you need to manage memory by hand. And technically malloc and free are part of C as described in the standard, specifically hosted C. You are referring to freestanding implementations which are valid but non freestanding systems still exist.
Constructors and destructors in C++ do not impact runtime. C types often have then and it is always an error to not call them by hand. If you always need to call it then doing so a
Re: (Score:2)
Re: (Score:2)
Part of the issue is treating C and C++ as the same language (or basically the same). Writing memory-safe C++ is trivial with a modern compiler.
Memory-safe C++ is dramatically easier to write than memory-safe C, but it's still far from easy -- and certainly not "trivial". At minimum, it requires applying the discipline to write in a Modern C++ style, eschewing the use of raw pointers, etc., but that's not the whole story. With exceptions enabled, the challenge mostly shifts to writing exception-safe code, where there are a lot of very subtle pitfalls. If you need to disable exceptions (as much real-world C++ code does), then you have even harder
Re: What problem does this solve? (Score:2)
Memory-safe C++ is dramatically easier to write than memory-safe C, but it's still far from easy -- and certainly not "trivial".
It's also not memory safe, and the C++ idea of memory safety is not zero cost.
Re: (Score:2)
Yes. And PHP has tons of really bad vulnerabilities despite being memory-safe.
This is a skill issue, not a language or tool issue. Too many low-skill coders are programming C, when they should be staying far away from it. (The same is true for PHP.) Tools will _not_ solve this. Please stop barking up the wrong tree.
Re: (Score:2)
Too many low-skill coders are programming C
While this is undoubtedly true, it implies that there exist high-skill coders who can/should use C, but these programmers seem not to work on any real, non-trivial C-language project, since every non-trivial C-language project is plagued with memory errors, many of which are exploitable security vulnerabilities.
Re: (Score:3)
I've worked on multiple project written in C (some ~250kloc) which did not have memory errors because we had a coding standard which dictated how and when memory allocation could be used. This is more of an issue for the hobbyist coder than the professional who must submit their work to a panel of reviewers.
It's really not that difficult to avoid memory errors if you're just a little bit disciplined. It starts with good design, using scanning tools, and performing code reviews.
Re: (Score:2)
I've worked on multiple project written in C (some ~250kloc) which did not have memory errors because we had a coding standard which dictated how and when memory allocation could be used. This is more of an issue for the hobbyist coder than the professional who must submit their work to a panel of reviewers.
And how do you know that you didn't have memory errors, even in those small (250 kloc is small, especially in C) projects with heavyweight review processes?
The evidence against C is overwhelming, just look at the CVE database -- and many of those are from highly skilled groups of programmers. The Linux kernel is an excellent example. (And, no, the kernel devs are not "hobbyists".)
To be clear, my natural bias is in favor of C. I started writing C in 1989 and C and C++ (I don't view them as the same lang
Re: What problem does this solve? (Score:2)
C projects are more carefully audited that is why they occasionally get CVEs, most are of very low severity.
I mean all web projects are written in "memory safe" languages, but they are all constantly in a state of swiss cheese of having thousands of severe security flaws on all levels of implementation and in design.
No one even cares to attack them anymore as it is just way too easy.
Memory safety actually untrains the brains in dealing with finite resources. Causing those same issues to pop up elsewhere in
Re: (Score:2)
Indeed. Especially this:
Memory safety actually untrains the brains in dealing with finite resources. Causing those same issues to pop up elsewhere instead.
Incompetent coders will make dumb mistakes. Competent coders will make few mistakes and will have redundancies in place.
That said, Lisp has its place. But it is not the same as the place of C.
Re: (Score:2)
There is just no reason to accept the risks of using inferior tools when better ones are available.
A poor workman blames his tools.
The problem isn't the tool, but the bad habit of mind that comes with the promise of "freely available memory that never runs out..." If you approach memory from the perspective of a loan rather than a gift, memory management becomes a part of the design phase. You wouldn't take out a loan without a plan to pay it back, and you shouldn't design a program without a robus
Re: (Score:2)
Exactly. Thank you.
Re: (Score:2)
Erm, C has memory safety issues coming out of the wazoo. Double frees, null pointers, buffer overflows are all endemic to C (and C++) programs
These are programmers issues, not C issues.
Re: (Score:2)
Erm, C has memory safety issues coming out of the wazoo. Double frees, null pointers, buffer overflows are all endemic to C (and C++) programs
These are programmers issues, not C issues.
How does a human maintainer go about programmatically verifying that another human programmer didn't make one of these mistakes?
Re:What problem does this solve? (Score:4, Insightful)
Obviously the solution is after a programmer makes a mistake, you declare that they're a bad programmer, pause the world, go back in time and rollback all the work they've ever done, and then get somebody else to write it, go forward into the future, and then unpause the world again. Simple! /s
Re: (Score:2)
No, they're problems for the end user. Neither the self-important "I never make mistakes" programmer who chose C to begin with, not the idiots that destroyed C, nor the fact C doesn't have the core checks built into every other language, will be the people who suffer because of a buffer overflow.
That's the person you should be expressing concern for, but instead you're assigning blame while playing some pathetic one-upmanship game with other programmers, which is why the issue never gets resolved and why we
Re: (Score:2)
Double frees, null pointers, buffer overflows
Is similar to saying x86_64 also endemically suffers these issues- in that it doesn't, because:
free(3) is a stdlib problem, not a C problem.
In C, there is nothing wrong with a null pointer. That's entirely dependent on your memory mapping
. Even overflowing a buffer is a much higher level concept than C deals with.
"Overflow a buffer? What intrinsic are you using to overfill said buffer?"
Who are you to say what I do with my definitional structure of memory?
I think perhaps the argume
Re: (Score:2)
They are issues of a language that can't implement RAII, and even if it could (like C++) it wouldn't care if you implemented it properly. And unless your C contains no allocations or pointer arithmetic whatsoever (e.g. some Arduino sketch), then you are never free of these issues. And if you object to C being blamed for stdlib malloc/free, then replace it with kmalloc/kfree or any other pair of functions that allocation memory from heaps, slabs or whatever.
The CVE database is filled with software written in
Re: (Score:2)
They are issues of a language that can't implement RAII
No.
Does your hardware "implement RAII?"
Does x86_64 assembly "implement RAII?"
and even if it could (like C++) it wouldn't care if you implemented it properly.
You are imposing arbitrary demands upon the language because, as explained previously, you don't understand what the purpose of the language is.
And unless your C contains no allocations or pointer arithmetic whatsoever (e.g. some Arduino sketch), then you are never free of these issues.
Even an Arduino sketch comes with a pretty fleshed out runtime and standard AVR library.
You are still conflating BSPs with the language.
And if you object to C being blamed for stdlib malloc/free, then replace it with kmalloc/kfree or any other pair of functions that allocation memory from heaps, slabs or whatever.
What?
I think you might actually be an idiot.
malloc/free, kmalloc/kfree are functions implemented in C. They are not C.
I object to you calling functi
Re: (Score:2)
As I've pointed out, the language they're written in isn't the problem. You just can't understand that. You are a precise example of why Computer Science education is important.
It absolutely is. And the rest of your diatribe is emblematic of the sheer arrogance of certain people - "I'm Super Programmer and I never mistakes and you all need to git gud at C you'll me like me!". And the really dumb part is you doing this on a thread which about TrapC which describes the problem to you. And in the face of thous
Re: (Score:2)
It absolutely is.
Wrong.
And the rest of your diatribe is emblematic of the sheer arrogance of certain people
No, it's emblematic of the difference between someone with a Computer Science education and someone who doesn't have one trying to argue points without the knowledge to comprehend the nuance.
And the really dumb part is you doing this on a thread which about TrapC which describes the problem to you. And in the face of thousands of CVEs directly caused by the C language.
You keep saying that, but you're wrong.
Those CVEs are not caused by the C language. They were written in C, for sure. But they are not caused by the language, any more than the MOV instruction is responsible for all bugs that ever happened.
Rust is a systems language and has the potential to do anything that C can.
Of course it does. As long as you disable its memory safety.
Have you ever
Re: (Score:2)
I never claimed I was awesome at writing safe code. Rather, I'm going to argue right now, that in the areas where the only code that can run is unsafe, you want me doing it, and not some dumbshit like you.
Uhuh, sure thing Super Programmer. You're just an arrogant dickhead defending a shitty language and too incurious and arrogant to understand why it might be an issue.
Re: (Score:2)
Re: (Score:2)
You can hand in your geek card on the way out through the basement and don't let the door hit you in the ass.
Re: (Score:2)
Re: (Score:2)
There is no static code analysis that can find all potential overrun bugs short of actually running the program. If you think otherwise write a white paper and collect your nobel prize in computer science.
Re: (Score:2)
There is no static code analysis that can find all potential overrun bugs
That's not what you want Lint to do. You don't want it to say "This is proven unsafe," but "This can't be proven safe".
If the code isn't clearly safe, then it should be rewritten so it is.
If you think otherwise write a white paper and collect your nobel prize in computer science.
There is no Nobel Prize in computer science, but you would get a Turing Award, which would likely be renamed in your honor since you proved Turing wrong.
Re: (Score:2)
Try making some valid points instead of idiotic babble next time.
Re: (Score:2)
There is no static code analysis that can find all potential overrun bugs short of actually running the program. If you think otherwise write a white paper and collect your nobel prize in computer science.
Personally I think the static analysis route is ultimately the best solution. It doesn't need to be able to cover everything. Just have lack of coverage itself be an error and programmer responds by tweaking the way their software works to enable full coverage.
The advantage is freedom/productivity improves as the analyzer does and it provides a path for moving beyond a myopic focus on memory safety which is only one of many failure modes.
Re: (Score:2)
Re: (Score:2)
> C has issues, but memory safety is not one of them.
Ahem. Yes I know you wrote the follow on sentence, but you need to do more than handwave and suggest that it's not an issue because it's also necessary we have direct memory manipulation somewhere. It's a little like claiming lead has issues, but poisoning causing brain damage isn't one of them, because pipes that don't rust is the whole point of getting water to people's homes.
> Direct memory manipulation is the whole point of low level programming
Re: (Score:2)
C has issues, but memory safety is not one of them. Direct memory manipulation is the whole point of low level programming.
We do both. Some times we want to slam values into memory addresses. And other times we want to be able to reason about a complex program, and certain kinds of guarantees makes this a whole lot easier. This really comes into play when integrating many complex components together. You want the sum of the parts to be robust, not increasingly fragile.
Unfortunately I think projects like TrapC are a decade late. We can already use Rust. And with a little encouragement you can use AI to take old C code and transl
Re: (Score:2)
Unfortunately I think projects like TrapC are a decade late. We can already use Rust.
True. But switching to Rust forces a rewrite of everything. Which might clean up all the unsafe code. But also introduce changes in the behaviors of some components that downstream users have come to depend on.
If the existing C will compile under TrapC, odds are pretty good that these default behaviors will remain unchanged.
Re: (Score:2)
But switching to Rust forces a rewrite of everything.
We have been using Rust without rewriting everything (Linux kernel and some device drivers and some firmware). I think the language is overly complex, but my industry is going forward with it. Most of our code translation is machine assisted too.
I remember the promise of transitioning projects from C to C++, but in the end people would go out of their way to come up with an excuse to rewrite code to be "modern C++". So I'm a bit skeptical of the value of full language compatibility at the high level.
As long
Re: (Score:1)
It's a trap! (Score:2)
https://www.youtube.com/watch?... [youtube.com]
XrO (Score:3)
Re:XrO (Score:5, Insightful)
Re: (Score:2)
My guess is big egos that want to take over.
leave it already (Score:2)
C and C++ are not safe, that's how it is, leave it FFS. If you want safety as a major feature then use a language where you can't read or write where you shouldn't, there's plenty of them.
Re: (Score:3)
This fixes (or at least claims to fix) one set of problems with C in a manner that is largely transparent. (Most existing C programs would be compiled without changes.) I find this approach a lot more attractive than rust. But the standard library needs to be extended to include hash tables and RB trees, and there needs to be a better handling of unicode (preferably "everything is utf8") with libraries to deal with it.
Will not overrun or segfault? (Score:3)
""TrapC Memory Safe Pointers will not buffer overrun and will not segfault,"
So what will they do then, just assert with an error? Not much difference really though possibly slightly more helpful to the person running it. Or worse will the program continue running somehow which sounds like a nightmare waiting to happen?
Or if Mr Rowe thinks his compiler will catch all potential out of bounds at compile time then he's discovered one of the holy grails of CS.
Re: (Score:2)
We are to believe it will automagically unfuck bad code. It is not to be taken seriously.
A language is not merely a compiler anyway, Apparently these people think it is.
Re: (Score:2)
We are to believe it will automagically unfuck bad code. It is not to be taken seriously.
This is the correct answer. Having read most of the white paper, I'm left wondering whether this is an April Fool's joke released too soon. Some of my favourites:
TrapC is compatible with most C code
followed shortly afterwards by
TrapC compatibility when compiling C code is limited in a small way by the removal of ‘goto’ and ‘union’.
So that'll rule out probably 98% of real life C programs then!
also
how TrapC translation is implemented is a compiler implementation detail. Translations might be from a local dictionary, be captured ad hoc from user-provided input or be AI-generated across the Internet.
The paper claims that the standard unmodified C "Hello, world" program, if compiled with TrapC and run with LANG=fr_FR, will output "Bonjour le monde". With translation automatically provided by AI. I can see literally no way how that could end badly!
It teminates with a "useful error message" (Score:3)
From the white paper link there is a simple example:-
void gets_input()
{
char buffer[24];
printf("Please enter your name and press \n");
gets(buffer);// TrapC will terminate on overrun!
printf("%s",buffer);
}
If the user inputs more data than the 24-byte buffer can hold, that is a typical C buffer overrun
error. In C/C++, such an error is not implicitly caught, may crash or enable a hacker exploit. The
action TrapC takes on overrun, or any other unanticipat
Re: (Score:2)
Legacy system maintainers who like ‘goto’ and ‘union’ may prefer to keep such code in C.
A lot of C code that I have read uses the keyword "goto" to jump to code to that deallocates resources allocated by the function. This somewhat corresponds to the keyword "finally" of Python and Java. What's the common practice in programs written in C without the keyword "goto" to write resource deallocation code only once rather than duplicating it, likely with errors, at each place that a function returns?
Re: (Score:2)
Deeply nested "if" blocks. But I think TrapC allows you to have C++-like automatic unwind to make the cleanup happen automatically on return.
Re: (Score:2)
So what will they do then, just assert with an error?
They will fail to compile.
Re: (Score:2)
If you don't trap the errors, it will terminate with a reasonable message. If you do trap the errors, you can handle the problem and continue. (I really hate the obscure segfault messages.)
I'm not sure I'd use it, as I use lots of containers, and libraries to handle them aren't standard in C, but it's a lot nicer than rust.
Done To Death (Score:5, Informative)
Hardly a new concept. Been tried before. The problem has never been "can we do it", the problem was always "how badly does it affect performance". You can't do bounds-checking for free, and that hasn't changed.
A fork of what compiler? (Score:2)
"TrapC, a fork of the C language,"
There's a lot more to a C(++) compiler and its surrounding ecosystem than just the paradigm of "memory safety".
Re: (Score:2)
Yes, but the claim seems to be that this could be tit into the existing ecosystem without many changes except replacing C. (As someone else commented, though, the kicker may be "How much execution time does it add?".)
No (Score:3, Insightful)
And seriously,
1. C is not "hindered" at all. That is just a lie by misdirection.
2. Lack of memory safety in C is a feature, not a bug. It gives you control that you otherwise do not have. Of course, with great control comes great responsibility.
3. C is not a language for low-skill coders. Please stay away unless you are competent.
Re: (Score:3)
with great control comes great responsibility
We can't have that. The burden of responsibility should be on the computer. That's what they're made for. It's like saying parents should be responsible for their children.
Sarcasm aside, I am in favour of tools and a compiler which can optionally provide the extra security of memory checks and other known risky behaviour, but I say once again, optionally.
And no removing features just because of hype. There are logical cases for manipulating memory access and using goto and unions after all.
Re: (Score:2)
Sarcasm aside, I am in favour of tools and a compiler which can optionally provide the extra security of memory checks and other known risky behaviour, but I say once again, optionally.
I completely agree to that. Warnings are entirely find. Still takes somebody that actually understand the warnings.
And no removing features just because of hype. There are logical cases for manipulating memory access and using goto and unions after all.
Indeed. These are decidedly "experts only", but they are there for really good reasons.
Re: (Score:2)
Long gone are the days in which saying something like "I'm a skilled programmer, I don't make mistakes, I wouldn't benefit from better safety features" wouldn't get you laughed out of the building (at least in any environment I would consider reputable). And it's embarrassing that anybody who would consider themselves a professional programmer doesn't know that most languages which do have better safety posture support unsafe "control" when you explicitly choose to use it. Including TrapC - by being abi com
Re: (Score:2)
Why does this absolutely stupid argument gets made time and again? We are not talking about "I do not make mistakes", we are talking about "I make absolutely stupid beginners mistakes and are not competent to put in even the most elementary redundancies that prevent them from being exploitable". Have you looked at the utterly incompetent mistakes people make when lack of memory safety does lead to exploits? It is like they insist on using a hammer to hammer in nails, but do not even know which part of the h
Re: (Score:2)
Because everyone in a position of actual power wrt the future of programmer agrees with me, and not you. Look, if you're in a 2 person shop writing whatever, go for it. But nobody directing the bodies that produce software at scale for the most widely used systems and platforms in the world takes the "its a people problem" argument seriously anymore. Mostly because it's a bullshit false dichotomy. In 25+ years of embedded C/C++ I've seen utterly incompetent mistakes done by every range of expertise and comp
Re: (Score:2)
3. C is not a language for low-skill coders. Please stay away unless you are competent.
I agree. And given that we have CVEs related to memory safety all the way up to and including places such as the Linux kernel I can only conclude that there's no coder in the world with a high enough skill.
That said I would frame it differently rather than implying all programmers are idiots, which is something that has to be concluded based on your post and statistics of memory safety problems.
Re: (Score:2)
3. C is not a language for low-skill coders. Please stay away unless you are competent.
That statement screams of arrogance: "I am a god programmer who will never make a mistake." The list of CVEs in Linux due to C programming issues says everyone makes mistakes.
Re: (Score:2)
3. C is not a language for low-skill coders. Please stay away unless you are competent.
That statement screams of arrogance: "I am a god programmer who will never make a mistake." The list of CVEs in Linux due to C programming issues says everyone makes mistakes.
This is not about not making mistakes. This is about not making really dumb mistakes and then having no redundancies in place.
Re: (Score:2)
This is not about not making mistakes. This is about not making really dumb mistakes and then having no redundancies in place.
What you missed is you called people who have ever coded a CVE that went into Linux "a low-skill coder". I am pretty sure they are far more skilled at C than you.
Re: (Score:2)
Well, you invalid (and, incidentally untrue) AhHominem shows you have nothing, as does your "Appeal to Authority". Moron.
Done already (Score:1)
Random thoughts (Score:2)
At least there does not seem to be a rust style unsafe keyword.
I'm not a fan of banning goto and there is no mention of switch in the whitepaper. I'm not sure if they are trying to make it easier to enforce some constraint or this is some kind of misguided editorial decision. At the very least they should allow some kind of constrained version of goto.
"Returning a pointer to a local variable is not an error" ... and this notion of auto resetting garbage for example if you increment a pointer beyond whatev
Fixing the wrong problem (Score:2)
Torvalds pushed back against C++ for decades, using pure C in building objects, event handling and memory management. Clear guidelines and many eyes on the code worked better than the numerous attempts to use C++
Re: (Score:2)
Perhaps in aviation where low piloting experience is 'fixed' by more and more features of flight controlling computers.
This might be one of the dumbest things I've ever read on slashdot, and that's saying something
Re: (Score:2)
low piloting experience is 'fixed' by more and more features of flight controlling computers.
That was accomplished by the replacement of the first officer with a dog. The captain's job is to feed and play with the dog. The dog's job is to bite the captain should he attempt to touch the flight controls.
Robin Rowe (Score:3)
So in summary, Really talented individual, but previously failed to get a community to take his ideas to the next level. So I'm a bit skeptical for that reason in addition to all the other ones people have brought up. If there is some long standing commercial entity funding him in this work, then maybe it has a bit of a chance.
To quote Admiral Ackbar (Score:2)
It's a trap!
Re: (Score:2)
Yet not an exception!
JoshK.