C har nu också fått ett förslag i samma anda som Safe-C++ förslaget, TrapC. Angreppssättet är ett annat och efter att läst både Safe-C++ och TrapC får helt klart TrapC min röst.
Register har en artikel om detta från november
https://www.theregister.com/2024/11/12/trapc_memory_safe_fork...
TrapC blev aktuellt igen då förslaget släpptes igår.
Safe-C++ sätter bakåtkompatibilitet som prio#1, vilket givet att just "legacy" är en allt större anledning för någon att använda språket initialt känns fullt rimligt. Problemet är att slutresultatet blir något som inte alls ser ut som C++, om detta accepteras in i ISO-C++ blir det ännu en förändring som rätt fundamentalt förändrar hur man bör skriva C++.
TrapC introducerar några enstaka "breaking changes", men det spännande är att genom att göra det får man ett resultat som helt fixar problem som "use-after-free" (en av de absolut vanligaste orsakerna till säkerhetbuggar i C och C++, något som C++ i teorin löst från C++11 om man släpper användning av "nakna" pekare) och buffer-overrun (en annan otroligt vanlig bug som C++11 inte fixar lika transparent som TrapC).
Detta är ett smakprov på TrapC som inte har minnesläcka, vilket "vanlig C" skulle ha
char* strcat(char* to,const char* from) {
string s = to;
s += from; // realloc with copy-append if needed, no segfault
return s; // returning local ok in TrapC, no segfault, no leak
}
free() är i praktiken en no-op i TrapC, minneshanteringen är rätt mycket tagen från Rust (bygger på RAII). Saker likt detta gör att majoriteten av all existerande C kod kompilerar direkt i TrapC!
int main() {
int* p = malloc(sizeof(int));
free(p); // TrapC ignores free, p not freed yet
*p = 10; // UB in C, no problem in TrapC
return 0; // Leaving scope, TrapC now frees p automatically
}
Vidare fixar man en annan väldigt vanlig C bug i stränghantering, '\0' stöds men strängar, likt alla pekar-typer, innehåller RTTI samt vet sin längd. Så i TrapC är T* i praktiken std::vector<T>, vilket är det nyktra sättet att hantera minnesareor när möjligt.
Och för att gå tillbaka till ursprungliga frågeställningen i tråden: läser man inledningen till både Safe-C++ och TrapC dokumenten verkar båda "lägren" inse att man måste göra något. För allt fler organisationer drar nu öron åt sig kring de säkerhetsproblem C och C++ plågas av, samtidigt som man nu också fått "bevis" på att det var ett problem som kunde lösas inom ramen av att behålla de kritiska delarna i C och C++, nämligen förutsägbar minneshantering, zero-cost-abstractions men ändå automatisk upptäckt av alla/nästan alla minnesproblem (i.e. det kompilerar inte alt. det upptäcks runtime så programmet kan avslutas).
Är det något C++ behöver är det något likt TrapC, i.e. något som ser ut som C++ och där nästan all existerande C++ bygger direkt (och resten kan fixas relativt enkelt), men som tillåts innehålla enstaka "breaking changes". En uppenbar "breaking change" som behövs är att dessa säkerhetsgarantier måste vara opt-out (likt Rust "unsafe"), vilket är fallet i TrapC. Inte opt-in, vilket är fallet i Safe-C++.
