To kill memory safety bugs in C code, try the TrapC fork

Re: Wait and see

I presume the answer to adjusting a passed pointer within a function is to ensure what's passed in always points to something with the same bounds, or transparently passes in what those bounds should be.

If it can be determined at compile time there's likely little overhead and, if it can't, it adds cost, then don't do it that way, accept there will be overhead, or just stick to using C. Ideally Trap-C for the most part, linked to C code when you really do want to play with dragons.

Trap-C looks like a good idea to me and seems like the advantages outweigh any downsides.

Re: Wait and see

The article is fairly clean that run-time checking is NOT part of the scheme. The scheme is

"And I was like, 'Well, since the compiler knows where the end is, what if when it goes off the end, the pointer just went to zero?' And that's much easier to deal with than a wild pointer because you can easily check if the pointer is zero. And so that's the essence of what we're working on with TrapC ..."

How can the compiler know? I can only guess that means every "new" is passed an explicit constant length, and there is no conditional logic in the incrementing loop except for a early exit. Outside of the loop the memory can no longer be incremented. Changing the constant requires re-compiling.

The compiler must not allow pointers to passed to subroutines - unless there is something like "this is an array of 10K" that can be passed as an argument - no passing naked mystery pointers.

It is stated that this is only for safety critical coding, so the lack of freedom (and the compile errors that entails) are acceptable.

Re: It's a TRAAAAAP!

And he's a professor of computer science... says something about Rust then, doesn't it?

Re: Variable Names : Case Sensitivity

Having lots and lots of ways to spell a single variable is worse.

Interesting and relevant article here:

https://devclass.com/2024/11/12/iso-c-chair-herb-sutter-leaves-microsoft-declares-forthcoming-c-26-most-impactful-release-since-c11/

Whilst it is about C++, I wonder whether TrapC is an equivalent for C and thus a candidate for the next edition of ISO C.

Re: I've taken out union and some other things that I rarely use

[I have NO skin in this game, just trying to be fair to all]

I see your point(er) [Pun not intended :) ] but I would say try it and see if it is as bad as you think.

It is a generally good idea that is an alternative to re-written libc that is mem-safe or similar addons to libc.

There is NOT going to be a mem-safe C this side of the heat-death of the universe, so these types of ideas are going to appear.

If they are dismissed out of hand what is the solution ???

Yes, there will be huge amounts of code that will NOT simply compile & go BUT what is a reasonable solution that does not require a TOTAL rewrite ???

RUST is not gaining popularity with the C & C++ devs because it requires some effort to learn and even bigger effort to then translate C code to RUST.

Automagic C to RUST is very very difficult !!!

If ALL these attempts are considered BAD please suggest something positive rather than just shooting down ALL ideas with NO/Negative feedback.

:)

Re: I've taken out union and some other things that I rarely use

I think union is little used, and will continue to be little used. MISRA frowns on it, for one.

In that (rare) 400,000 line project with lots of unions, you'll just have to go through it getting rid of them, one by one. Or stick with C. So what? The developer of this language has experience in embedded systems, where there are indeed some legitimate uses of union. There will surely be some adequate replacement for it.

As for that big chunk of memory you need to zap, if you declare it in a function (I'm guessing here), it will be freed as part of leaving that function. What's the big deal?

It sounds good to me. I think we should wait for the language to become available before anybody condemns it.

Re: I've taken out union and some other things that I rarely use

I am guess it means that memory is auto deleted at end of scope. The talk about C++ destructors implies that may be the case. C++ destructors free memory when the constructed object goes out of scope, and that's a compile time calculation. I used to program in C++ and that was exactly how I avoided memory leaks. However, it also presumes the memory will never be passed out of the scope within which it is created. But passing memory out of its birth scope is exactly the kind of behavior that is safely allowed enabling far more freedom and faster coding in GC languages.

The author did caveat that TrapC is only for meant for safety critical systems. That's just the kind of sedate code where auto-deleting at scope end is suitable. I guess TrapC borrows that one feature from C++ without the other baggage.

Does the compiler disallow making copies of pointer? I guess it must, but that should be stated.

Re: I've taken out union and some other things that I rarely use

I've taken out union and some other things that I rarely use

Spoken like a true nsBDFL.

_{(ns == "not so")}

Re: I've taken out union and some other things that I rarely use

This isn't going to be for "moving all your code".

It would be for writing new code, or for writing limited sections of existing code that are security critical due to running with elevated privileges or futzing around with stuff with security implications like private keys.

Outside of I/O drivers, it is hard to find good cases where union is necessary. Like needless pointer casting, unions are often used as a crutch by poor programmers who don't see the right way to do things.

Re: I've taken out union and some other things that I rarely use

There is a bigger problem. You can absolutely do things like this in C:

return (char*)malloc(42) + 123456;

Or XOR the pointer with something, or whatever.

And then in a galaxy far far away a different piece of code undoes the transformation, gets a valid pointer, does something with the memory and frees it. No code analysis can figure out whether the memory block is still use or not, or whether the pointers are valid. The allocation and use may be even compiled completely separately. So the basic premise is false.

You may consider it contrived, but there are use cases for keeping around different pointers than what malloc() gave you. Or if you know the alignment (for instance to multiple of 16) you can use the lowest bits of the pointer to encode some extra information and clear the bits when you are actually using it as a pointer. Etc. It is exactly the ability do such low-level stuff why you use C in the first place.

Re: I've taken out union and some other things that I rarely use -> Union are useful

Howard:

1) I do like the idea of TrapC, overall it makes lots of sense !

2) Unions (like varian records in Pascal) are very useful for typecasting, especially in system low level, protocols, and more : please consider implementing it for this reason, and also to make compatibilty easy.

3) "New" instead of "malloc" as described here seems fine to me.

4) One feature to consider is to drastically reduce the need for C macros, by creating compilers objects (like in assembly) so debuggers will always work !

"Keep is as simple a possible, but not simpler"

Albert Einstein

Re: calloc?

#define malloc new

#define calloc new

#define free(P) ;

Re: calloc?

Though (in my experience) calloc far more often used than malloc ( unless speed was absolutely critical, & the miniscule overhead of clearing the data was just too much then do not use malloc) , in C would use typically calloc as always safer having "cleared" data than retaining preexisting value that happened to be in that area of memory e.g. there's a small but non zero chance* that if you are testing your pointer data to see if it matches a value, that might just be a match with the "junk" that was present in the memory to begin with.

I've generally been of the opinion that you should initialise correctly, and the correct initialisation of a region is not necessarily all zeros. I've seen bugs where failure to set correct initial values for an algorithm has been masked by an earlier initialisation (to shut the compiler up? I don't really know why people do this, int somevar=0; and then set the value it really should be later). Calloc is in the same class, if you really want zeros then it's the fastest way to achieve it, a nul-terminated string then you'll get it but it's not the most efficient. And if using realloc you'll need to deal with it anyway. (There's even a more subtle type of bug, which is more at the algorithm than processing level, where starting with an array of zeroes will bias your output, have been looking at that in a variant of multilevel spline fits for a while now, it's not a coding error as such, but a tendency to reach for things like calloc might encourage the mindset.)

Re: This'll be down voted...

I'm not down voting you, but I'm curious - don't you use any scripting languages for the small problems which crop up, day to day? Something like bash, or AWK, or Python, or Perl?

For example, to count the total size of files in a directory, using bash and AWK would look something like this:

ls -lrt | awk 'tot += $5; END {print tot}'

. I don't doubt you could code this in Fortran, but it would be much longer, more tedious, and more error prone to write.

Re: Code analysis

you aren't wrong...but

1) the demand for programmers greatly outstrips the supply of GOOD programmers.

2) the demand from bosses to produce results NOW and worry about mess later is, if not universal, very common.

3) more and more programming work is going to barely-skilled low-cost "other country" development houses, where quality of work is irrelevant.

So...safer languages are needed.

Except...that lowers the bar for people to think they are "good" programmers, which ends up reminding people there are more ways to lose data than just memory errors in C. I saw something once a number of years ago, where some prestigious school washed out 75% of their computer science students when they were teaching C. Once they switched to Java, they graduated 75% of their entering CS students. So most of the graduates still sucked, but they could pass and get a sheet of paper and go writing banking software.

I have no idea what the answer is...

Re: No terminating '\0'?

You didn't read it closely enough.

There IS a terminating /0, but it will block any attempt to write anything other than /0 to the 8th character of a 8 character array. It will fail the comparison with that 8 character string for that reason.

If you ran that same code in C that comparison would succeed, because the 'success' variable that immediately follows it on the stack is where the 9th character /0 would be written beyond the bounds of the 8 character buffer[] variable. If you ran that same code in C but with success set to -1, the value of success would be altered (-2^24+1 or something like that) when that 9th character /0 was written.

Re: An old idea

Perhaps look at EPOC16, from the late 80s/early 90s, then EPOC32 (the precursors to Symbian OS) to see just how old...

TRAP() and TRAPD() - all sounds pretty familiar to this old git! and all within a std C/C++ compiler of its day - exceptions were not a thing back then.

No amount of safety handling can deal with the 'open a file' to do some work, opening the file fails but we still magically manage to do the work. Sure some langs can automatically handle the error state more elegantly than others but they cant automagically fix the underlying issue - the data set becoming unavailable... or maybe they can these days by simply sprinkling some AI ontop...