Linus: Overbevist om at vi får andre sprog i kernen

Selv om C blev udviklet til at skrive UNIX, så har det nogle svagheder til det formål:

• Der er for mange tilfælde af udefineret og implementationsafhængig opførsel, så man skal kende den specifikke compiler på den specifikke platform for at være sikker på, at koden gør det man mener. Alternativt, gå ind og kontroller den genererede kode, men det fjerner lidt af ideen med at bruge C i stedet for assembler. C kunne have været et udmærket sprog, hvis man fra starten havde specificeret opførslen præcist og maskinuafhængigt, men det er for sent nu.
• Typesystemet er for svagt, og der er for mange fejl, der slipper igennem -- specielt når man laver lavniveaukode.
• Lagerhåndteringen er ikke specielt god.

Det giver blandt andet anledning til sikkerhedshuller som f.eks. bufferoverløb.

Rust kunne være et godt bud, men kunne suppleres med ekstremt simple sprog, der er designet til formel verifikation af koden.

Hvis man læser artiklen har Linus nogle ret gode betragtninger om C og C++.

En del kan kortes ned til den meget direkte kontrol man har i C - det er åbenbart hvad koden gør (hvis altså man kan læse C). Den primære anke Linus har mod C++ er at for meget gemt væk i abstraktioner der i Linus' optik ikke giver fornøden værdi.

Mht. den maskinafhængig ordlængde på visse typer i C er det noget som enhver C programmør er opmærksom på, når det er relevant. Hvis man ikke ved hvornår det er af betydning bør man lave noget andet.

Typesystemet er mindre dogmatisk end i C++ og langt mindre end i f.eks. Dart eller (sic) Typescript og kan bekvemt overrides når det er nødvendigt, men det kræver en handling.

Lagehåndtering - hmm - joh der har Rust bestemt en fordel :)

I min erfaring er C et stærkt værktøj til en række opgaver i hænderne på en kapabel programmør. Har man middelmådige programmører til sin rådighed bør man lave andre opgaver eller bruge andre sprog.

Typesystemet er mindre dogmatisk end i C++ og langt mindre end i f.eks. Dart eller (sic) Typescript

Ikke forstået - hvordan finder du Typescripts typesystem dogmatisk? Og hvad mener du med (sic) her?

(sic) går på Typescript som sådan. Javascript er i sig selv et ret elegant sprog - med et par quirks - Typescript tilfører en langsommere build, source map, som næsten altid kan debugges, OO syntax, java lignende interfaces og et typesystem - heldigvis er der < any> til når transpileren forvirrer sig selv og dine annotationer kun giver fejl-på-fejl.

Javascript er et dynamisk funktionelt sprog, medens de fleste mainstream sprog er statiske OO sprog hvilket vel forklarer hvorfor TS er født.

Så - lidt samme argument som Linus' vedr. C/C++

Jeg tror ikke (sic) betyder det du tror det betyder :)

Typescript kan bruges til mange andre ting end at få din Javascript-kode til at ligne Java, se fx https://gcanti.github.io/fp-ts/

Hvis du med "OO syntax" mener klasser, er de jo ikke anderledes end Javascripts egne

Javascript er et dynamisk funktionelt sprog, medens de fleste mainstream sprog er statiske OO sprog hvilket vel forklarer hvorfor TS er født.

Javascript er multi-paradigme. Det er et ret voldsomt stretch at kalde det et funktionelt sprog, bare fordi man kan bruge diverse teknikker fra funktionsprogrammering. Med den logik er Java, C# og python også funktionelle sprog.

Jeg ville ønske at Ada/SPARK fik en langt større udbredelse end det har i dag. Typesikkerhed der virker, tasking som en integreret del af sproget, distribueret processering, veldefineret opførsel, fin interfacing med sprog som C, verifikation, etc... - At vedligeholde og forbedre et +1MSLOC system er faktisk til at håndtere! Største anke mod Ada er som regel udbredelsen. Hvis det blev introduceret i Linux kernen, ville dette givetvis ændre sig.

Man har vel lov at håbe :-)

Jeg ville ønske at Ada/SPARK fik en langt større udbredelse end det har i dag.

Her kommer vi ikke udenom at ISO-C folkene udgør den største trussel imod C som sprog.

Det havde været trivielt at importere gode ideer fra andre sprog.

F.eks kunne man have "stjålet" Ada's glimrende ide med at specificere hvilket range integer variable skal have (Integer range 1..10;) hvilket både ville gøre koden mere selv-dokumenterende og samtidig givet compilere og statiske analyseværktøjer noget at bide i.

Man kunne også have kigget på hvad C i meget stort omfang bliver brugt til frem for andre sprog, og have tilføjet explicit struct layout og endianess og derved gøre C til verdens bedste sprog til data-udveksling og hardware interface:

struct foobar {  
    int32_t > @0;  
    int8_t @11;  
    int64_t > @12;  
}

Endelig kunne man have givet C et simpelt klasse-koncept, i stil med den "C-with-classes" som Bjarne havde lavet i starten af 1980'erne, fordi rigtig meget C-kode er OO kode der må vride sig selv som klejner for at implementere OO i et sprog der ikke har det.

Når den slags indlysende og "gratis" ting netop ikke kommer med i ISO-C, kunne man nemt få det indtryk at dem der vedligeholder ISO-C standarden har et skjult agenda med at skræmme folk bort fra sproget.

Når den slags indlysende og "gratis" ting netop ikke kommer med i ISO-C, kunne man nemt få det indtryk at dem der vedligeholder ISO-C standarden har et skjult agenda med at skræmme folk bort fra sproget.

Til gengæld har vi fået noget så nyttigt som komplekse tal og type-generiske makroer!

Jeg synes C11 går lidt mere i den rigtige retning, og tilføjer f.eks. en ordentlig hukommelsesmodel og (noget mere tvivlsomt) trådsupport i standardbiblioteket (i praksis bare pthreads), samt reelt nyttige ting som alignment og statiske assertions. Det er stadigvæk for lidt og for sent.

Til gengæld har vi fået noget så nyttigt som komplekse tal og type-generiske makroer!

Hvordan er det, er det ikke sådan at alt hvad der hedder strenghåndtering stadig er en ynk i C?

Hvordan er det, er det ikke sådan at alt hvad der hedder strenghåndtering stadig er en ynk i C?

Strenge? Det bruger vi ikke her - men prøv at følge efter den her pointer til char, måske er der et \0 et sted længere fremme...

F.eks kunne man have "stjålet" Ada's glimrende ide med at specificere hvilket range integer variable skal have (Integer range 1..10;)

Ja, det er en glimrende ide, og Ada har selv "stjålet" denne ide fra Pascal. Ideelt set burde heltal enten angive eksplicitte grænser eller være ubegrænsede. Et sprog kan sagtens understøtte begge slags.

Pascal og Ada påbyder, at det checkes, om et tal, der gemmes i en variabel, ligger i det angivne interval. Det sker som regel på køretid, hvilket nok ikke egner sig til kerneprogrammering. Men man kunne kræve, at der kommer warnings, hvis det ikke kan verificeres på compiletid. For at undgå alt for mange warnings, kan en programmør indsætte assertions, som kan hjælpe analysen og evt. indsætte "jeg ved, hvad jeg gør" klausuler på de steder, hvor compileren ikke kan verificere det. Alt for mange af disse bør dog betragtes som dårlig kodestil, og der bør være et compilerflag, der indsætter køretidstest ved disse, sådan at man under afprøvning kan fange fejl, men i produktionskoden slå disse checks fra af performancehensyn.

Pascal og Ada påbyder, at det checkes, om et tal, der gemmes i en variabel, ligger i det angivne interval. Det sker som regel på køretid, hvilket nok ikke egner sig til kerneprogrammering.

Compilerne er efterhånden så gode at forbavsende mange tjeks sker compile-time. Input "udefra" skal tjekkes (men det bør man jo gøre under alle omstændigheder). Bruger man SPARK Silver level er de tjeks forøvrigt helt unødvendige, for så har du bevist at du har tjekket hvad der bør tjekkes.

Når man nu (så let) har mulighed for at bevise fraværet af run-time exception, bør Kerneprogrammering selvfølgelig inkludere dette.

Kan du give et par eksempler på C-kode, som er implementationsafhængig af compileren?

Der er for mange tilfælde af udefineret og implementationsafhængig opførsel, så man skal kende den specifikke compiler på den specifikke platform for at være sikker på, at koden gør det man mener.

Kan du give et par eksempler på C-kode, som er implementationsafhængig af compileren?

Du laver sjov, ikk'?!? Men ok, jeg leger med:

Hvad er resultatet af følgende, med din compiler? Hvad burde resultatet være i henhold til standarden?

#include <stdio.h>  
   
void main (void)  
{  
    short int a = 65535;  
    short int b = a >> 1;  
    printf ("%d, %d\n", a, b);  
}

Tag gerne http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf og søg på "implementation-defined".

Kan du give et par eksempler på C-kode, som er implementationsafhængig af compileren?

CVE-2009-1897 i Linux – RedHat har et fint lille writeup. Eller Towards optimization-safe systems: analyzing the impact of undefined behavior.

C og C++ ville sandsynligvis miste en uacceptabel mængde performance, hvis optimizerne ikke måtte udnytte UB (jeg læste engang en god artikel om det, men fik desværre ikke gemt linket) – og reglerne er så subtile at selv yderst dygtige udviklere rammer ved siden af.

Ada er designt ud fra software engineering principper og har godt rygte inden for dette feldt. Ada har også rygte for at være utilnærmeligt og svært at bruge. Jeg kom forbi et citat en dag: Ada er ikke svært. Software engineering er svært.