If you can develop tools to translate C to Rust then if the C code DOES contain memory errors then either (a) you’re going to copy those errors over (which presumably is impossible because the constructs to do so aren’t there in Rust) or (b) the tools will catch the errors and complain. If it’s (a) then you don’t gain anything. And if it’s (b) then why not just fix the bugs in the C code rather than risking rewriting it?

The only way this can possibly 'work' is if it simply adds "unsafe" around the entire program.

Thus converting to Rust, but achieving nothing whatsoever.

Of course, in reality what it will do is spew out something that vaguely looks like Rust but won't even compile, let alone do what the original code did.

So, that would be "something almost, but not quite entirely, unlike C"?

My first thought - if it could do as stated, wouldn’t it be better to say ‘here’s all the code - can you see any memory access vulnerability problems?’. Then, if you care, you could fix ‘em. No need for the thing running the code to support a different runtime.

It’d still be frickin’ amazing to have a static code analysis tool that could model every possible combination of interactions between concurrent threads and their associated memory access behaviour. Actually - that sounds just as magical.

Another challenge is that C allows code to do things with pointers...

That means you need to understand the code and abstract the algorithm before you can make any correct translation. That definitely excludes all current forms of ML/AI/LLM.

And then, "errors" or "bugs" in the original sources will also be transliterated into the new language making the problem worse. You probably need to go through hoops to translate the original source and the result is most likely worse than the source. At least it will be less maintainable.

Or, we will just "invent" a new program to fix the old program that needs a new program to fix the old program to fix the old program that needs a new program to fix the old program to fix the old program to fix the old program that needs a new program to fix... [recursion limit exceeded, core dumped]

Translate C to Rust... maybe. With an LLM? Are you absolutely fruitbat insane?

Fruit Bat Insane

FBI

I seem to recognise that from somewhere.

Very good, sir! Please stay where you are. The F ine B lack I nfantry (*) will be there shortly to escort you to your final destination.

(*) MIB mandated suit in black, of course

...have they lost their fucking minds?

Example of code which from my understanding can't be guaranteed inherently safe in any language: In/output generally, e.g. network buffers.

Output: Move date from native representation (i.e. defined by the local machine), to network packet representation (i.e. defined by the 'to-the-wire' network protocol).

Input: Do the reverse (even more dangerous).

Now do it portably. Hmmm... ok...

Now do it efficiently- because that's what will be demanded. Hmmm... ok...

Now do it in an 'inherently safe' language in 'safe' mode. By my understanding, that's impossible.

So it'll be labelled 'unsafe'. Fine. So why not write those unsafe parts in C, which can already do the job supremely well. And then do all the rest in whatever f'ing language you choose?

The hard part is 1) understanding that some parts *cannnot* be made safe by the language alone, and 2) recognising where the safe<>unsafe transition lies.

Once that's understood, (assume LANGUAGE_X is mandated), I don't really see how 'LANGUAGE_X_SAFE' + 'LANGUAGE_X_UNSAFE' helps the codebase, AI assisted or not.

It may make it worse. People who understand these issues (i.e. the right people for the job) will be forced to use 'LANGUAGE_X', which they probably hate(!)- because it's not the best tool for the job, instead of C which they know very well... is.

But as I've probably said before... let's C.

"... the software engineering community has reached a consensus," the research agency [DARPA] said, pointing to the Office of the National Cyber Director's call to do more to make software more secure.

1. Offices neither call nor say anything. They are not sentient entities, they are merely rooms, usually filled with desks, common verbal misusage notwithstanding.

2. "Office of the National Cyber Director" != "the software engineering community".

3. A call to do more to make software more secure is not, in itself, an explicit endorsement of converting, either manually or with LLM assistance, software written in C or C++ into Rust.

4. LLMs: Garbage In, Garbage Out.

5. LLMs: just another (hyped-as) cure-all of the moment. They're good for everything from too-high programmer salaries to low code quality, high transaction latencies, and liver spots. Buy now!

6. Why convert to Rust, vs converting to a different memory-safe programming language, such as Ada?

7. Concensus is irrelevant in matters of fact . The natural number "one" is less than the natural number "two"*. That's an immutable fact, closed to interpretation, PR spin, or "what the concensus is."**

* I'm writing about the numbers themselves, and not about any internal computer representations of those numbers.

** There are too damn many Golgafrinchan Ark B people on this world, including many who write computer programs.

The natural number "one" is less than the natural number "two"

I beg to differ! Two plus two is five, if you must insist, and pi is a whole number according to some legislative forces, just like cold weather proves the absurdity of a warming climate.

Now, please step aside to let the venture capitalist make some more money from our socialist taxes for the poor.

/s

Memory safe code in Rust would still not protect against malware. The solution is obvious. Design an advanced MMU to protect against memory safety bugs in the software.

a. Enhanced isolation between user-space and kernel-space in hardware.

b. Extended isolation of individual processes in hardware.

c. ASLR implemented in hardware.

Don't tell me all the reasons it can't be done!

--

$83.4 billion: total profit (2022): ASUS, Acer, Dell, HP, Lenovo, Microsoft

More than three decades ago I developed a business system using dBaseII.

A few years later I wrote some code to convert it into C. Mostly because dBaseII was very slow, and dBaseIII was slower *and* riddled.

I'd expected it would probably work out around 80/20 automatic to manual conversion, but as it happened it worked out way better than that - I'd guess around 95/5.

The resulting system worked extremely well, and I continued to develop it.

But I always worried about memory safety, so I wrote a few memory-safe routines which I used instead of some of the standard library functions - in particular l wrote a protected version of malloc().

After a period of - ahem - improving my code, system halts because of things like out of bounds memory accesses simply stopped happening.

Thirty years later my code is still running businesses, and it's that long since it last halted for a memory problem. It's never been compromised.

If you want memory safety, from my experience I honestly don't think you need to do a lot more than code a few new library routines. Call it 'safelibc' or something like that.

Turning to AI for this reminds me of that old chestnut about the guy who decided to solve his problem using regexes... now he has two problems.

@sitta_europea:

> so I wrote a few memory-safe routines which I used instead of some of the standard library functions - in particular l wrote a protected version of malloc().

Interesting. Ages ago, I recall reading in Dr. Dobb mag a similar memory-safe wrapper around standard functions that added little overhead to the standard functions. iirc the wrapper overloaded the main functions so the main code read as normal.

SEcond that, I read a similar article (probably NOT by the same author) in BYTE magazine.

There must be a reason why neither microsoft, nor borland, not wacom, not intel, not GCC have adopted any of those as an extension of their libraries ... probably the trisolarians are preventing us

The only people who come across memory safety issues on a regular basis are those who work with a heap or other dynamic memory pool. This is an essential component in C++ programming since object instances can't be static**. This type of program also makes free use of automatics -- variables declared on a stack that assumes that the stack is indefinite, and so infinite, length. Away from this sort of environment programming is both more prosaic and so more controlled. Such programs will translate easily into Rust because they don't do anything that is likely to invoke Rust's signature features. Lots of productive work but in reality nothing actually getting done (in other words, "just another day at the office"!).

(**Not going to nitpick here. Too early in the morning.)

“Lots of productive work but in reality nothing actually getting done (in other words, "just another day at the office"!).”

Wow, that’s my last week in a nutshell.

"proper adherence to ISO standards and diligent application of testing tools"

Umm, seriously? If we all had programmed in according to ISO standards and tested things properly (and I am as guilty as anyone here), we could still use BASIC and the all powerful 'GOTO' command without error.

Whilst noting the, somewhat less than complimentary, comments above, I cannot help feeling that a tool which checked for things like buffer overflow or other memory use errors, and corrected them automatically would have saved me personally considerable time in the past. I have been highly critical of some applications of AI in the past (indeed on other posts in the Register), I would be interested to see how this translation is done before dismissing it as complete twaddle.

CAVEAT - I am a very limited objective 'C' programmer, my only experience of 'Visual C++' was painful, I used BASIC for Computer Science 'O'-level (yes I really am that old), dabbled with Pascal, and have had some 'fun' with Lisp and Prolog, am allergic to COBOL and have never even tried Rust.

Huh? Are we caught in the Ada loop again?

One historical feature of CPUs is that a register can hold an address, which can be used for data or for code: Z80: jmp (hl)

In C you can declare a variable to be a pointer to a bit of data or a function mimicking the old CPUs.

We haven't needed to write self modifying code in 50 years, either.

So the point I'm making is that wouldn't it be nicer to have a compiler which does not act so dumb and instead of printing warnings actually calculates the possibility of creating bad addresses and erroring out at that point? It may be better to have a front-end to a compiler which intelligently examines the code we have in the language it was written in, instead of translating bad code.

I hate seeing warnings when I compile other people's code and hate being told to ignore them.

Last time I touched pure C was to write drivers to SIL IV.

Good luck translating that to rust with the register accesses.

Good luck proving SIL IV level of testing has been reached...

C/C++ is as safe or as unsafe as the developer wishes.

Rust in peace.

Most Safety Critical systems don't use dynamic memory management.

The MISRA standard specifically forbids it, assuming it's being used.

I'm not saying C/C++ is perfect, far from it.

But to me it does scream "Use this, it's better!" Ignoring the convenient (for them), but convoluted back doors we've put in the code to access your system if we need to.

I'd point to the large world of open source code, and just as well, all the code used across the defense industrial base.

Yup, The defense industry is sure to want to dump its Top Secret C code into a LLM that will do who knows what with it, and subsequently spaff it out to who knows whom.

...it might even work.

My experience with LLMs—probably a year out-of-date by now—is that they did a decent job of translating the usual business logic. But weird memory access or pointer math was a bit too big a byte to chew. Haha.