C still powers the world

C, C++, Pascal, Assembly, Raspberry, Java, Matlab, Python, BASIC, SQL, PHP, etc.
Användarvisningsbild
lillahuset
Gått bort
Inlägg: 13969
Blev medlem: 3 juli 2008, 08:13:14
Ort: Norrköping

Re: C still powers the world

Inlägg av lillahuset »

Att C har blivit så populärt beror till stor del att det är ett väldigt enkelt språk som finns till de flesta arkitekturer.
Det mesta som är lite mer komplicerat finns i olika bibliotek som är skrivna i C. Resultatet av detta är att C är nästan trivialt att porta till en ny arkitektur.
De flesta kompilatorer genererar dessutom väldigt effektiv kod.

En av nackdelarna med C är att det är ganska stor risk att skära sig på den vassa kniven. Och när man skär sig på en riktigt vass kniv gör det inte ont förrän senare.
xxargs
Inlägg: 10183
Blev medlem: 23 september 2006, 14:28:27
Ort: Södertälje

Re: C still powers the world

Inlägg av xxargs »

ADA var en myt, en dröm på 80 och början av 90-talet associerad med amerikans militär, NASA, stora 16 bitars datorer med massor a RAM etc.

Det var totalt utanför räckhåll på 8 bits epoken på 80-talet där 64 kB dynamisk ram kostade en månadslön och disketter det enda som var ekonomiskt överkomligt i lagring, och en hårddisk på 10 MB kostade 10 papp - exklusive kontrollern... däremot fanns det mer eller mindre inkompletta men fungerande C-kompilatorer (kriteriet var att kompilatorn skulle kunna kompilera sig själv till en fungerande binär på sin egen källkod) för CP/M och Z80-miljön på den tiden - och om man ville slanta mycket även kommersiella varianter...
MiaM
Inlägg: 9912
Blev medlem: 6 maj 2009, 22:19:19

Re: C still powers the world

Inlägg av MiaM »

bearing skrev:Anledningen till att C har blivit stort är väl mest tillfälligheter. Hade ju varit bättre om t.ex. Ada eller annat säkrare språk blivit stort.
Som jag förstått det var de första kompulatorerna för C relativt bra, vilket gjorde att språket valdes framför andra. Med mycket kod skriven stannade man så klart kvar vid språket i fortsättningen. Trots de lite märkliga och svårfunna buggar som uppkom ibland.
Nja, det var väl mest så att de språk som fanns då C växte fram var väl skit i jämförelse? Förutom de totalt utdöda föregångarna B, BCPL o.s.v. så var det väl FORTRAN och PASCAL som kunde ses som nån tänkbar konkurrent.

Att PASCAL fick ett lyft på åttiotalet har vi väl Borland att tacka för. De gjorde en väldigt snabb och liten kompilator ihop med integrerad utvecklingsmiljö, där allt var så litet att det fram till och med TP 3.0 rent av gick att köra på CP/M på en 8080/8085/Z80. Att kompilatorn inte producerade särskilt bra kod var en annan sak, den var ändå många gånger bättre än t.ex. interpreterande BASIC och det gick många gånger snabbare att skriva sina program än att använda assembler.

Angående det xxargs skriver:
Vi ska inte glömma att de C-kompilatorer som fanns var en plåga under samma tidsepok. Jag har petat lite på C innan jag hade hårddisk. Då hade jag ändå en dator med "en årslön" av minne, enligt ditt mått av minnespriser :) , dock bara diskettstationer. Det var på den tiden man kunde komma över lösa diskdrives av mer eller mindre märklig typ utan att betala särskilt mycket, så jag hade nog som mest tre diskettstationer varav en var en 80-spårs 5,25" DS/DD-diskdrive vars disketter var inkompatibla med alla andras burkar. Men det gick bra att använda den driven med en diskett för att ha includefiler, libbar å sånt till C-kompilatorn. Tiden det tog att kompilera med disketter var ingen höjdare.

Samtidigt på samma burk, rent av med mindre minne, så gick det att köra en integrerad miljö med editor, assemblator och debugger där enda problemet var att man av lathet ibland inte orkade spara källkoden innan man provkörde senaste ändringen och därför tappade just senaste ändringen ifall man gjort något fel som gjorde att man var tvungen att boota om.

Jag har inte kört något i ADA själv, men mitt intryck är att ADA försöker vara en slags "plusplus"-motsvarighet till Pascal på det sätt C++ är en påbyggnad av C.

Den största bristen med C, som hela världen fått lida av många gånger, är att det inte finns någon inbyggd range-checking för framförallt strängar (men även arrayer som ju rent tekniskt är samma sak som strängar i vanlig C). Hade det funnits range-checking av längden på strängar så hade vi sluppit enormt många av alla buggar (framförallt säkerhetsrelaterade) som dykt upp under många år. Visst är det en prestandaförlust att ha sådan koll överallt automagiskt, men då kan man göra så att den default är på och man själv måste slå av den med kompilatordirektiv och då blir tvungen att tänka efter när man gör detta. Den som t.ex. sätter ihop en Linuxdistribution skulle kunna låta detta vara påslaget överallt där man själv inte audit:at koden. Dessutom skulle det kunna vara påslaget på alla ställen där prestanda inte har största betydelse. Exempelvis kan det vara påslaget i sshd men inte i httpd på en burk som agerar webserver.
Användarvisningsbild
TomasL
EF Sponsor
Inlägg: 45175
Blev medlem: 23 september 2006, 23:54:55
Ort: Borås
Kontakt:

Re: C still powers the world

Inlägg av TomasL »

Det har ju funnits rätt många kuliga språk genom tiderna, till exempel LISP och OCCAM är två av dem som i princip dött helt och hållet.
LISP blev man tvungen att lära sig en gång i tiden, väldigt stökigt.
Findecanor
Inlägg: 982
Blev medlem: 2 juli 2010, 23:04:07

Re: C still powers the world

Inlägg av Findecanor »

MiaM skrev:Den största bristen med C, som hela världen fått lida av många gånger, är att det inte finns någon inbyggd range-checking för framförallt strängar (men även arrayer som ju rent tekniskt är samma sak som strängar i vanlig C). Hade det funnits range-checking av längden på strängar så hade vi sluppit enormt många av alla buggar (framförallt säkerhetsrelaterade) som dykt upp under många år.
En del av felet är inte range-checking i språket i sig utan att C-biblioteket har funktioner som inte gör range-checking alls eller gör det inte ibland: de värsta är strcpy() and strcat().
På BSD lade man 1999 till funktionerna strlcpy() and strlcat() ('l' för "limit") som alltid kollar längd och alltid nollterminerar och andra Unix-varianter, bl.a. Solaris följde. Windows lade istället till sina egna strxxx_s() - varianter.
GNU libc (nästan varje Linux) har dock fortfarande inte strl - varianterna. När någon försökte lägga till det redan år 2000 så ratades det av maintainern med:
This is horribly inefficient BSD crap. Using these function only leads to other errors. Correct string handling means that you always know how long your strings are and therefore you can you memcpy (instead of strcpy).
Eller, översatt: "Man behöver inte säkrare funktioner om man skriver buggfri kod" ...
*suck*
Användarvisningsbild
jesse
Inlägg: 9233
Blev medlem: 10 september 2007, 12:03:55
Ort: Alingsås

Re: C still powers the world

Inlägg av jesse »

>En del av felet är att C-biblioteket har funktioner som inte gör range-checking alls...

mnja... men begränsningen i C är väl i så fall att du inte vet längden på en sträng, array eller vad som helst utan att behöva trixa med sizeof(...) eller använda macron som i char namn[MAX_ANTAL_TECKEN] vilket i sig lätt kan bli fel... jag håller nog med om att det kunde vara inbyggt på nåt vis, men att man skulle kunna välja bort det eftersom man ibland kanske inte har råd med extra kontroller i alla loopar, särskilt i små microcontrollers.
Användarvisningsbild
sodjan
EF Sponsor
Inlägg: 43150
Blev medlem: 10 maj 2005, 16:29:20
Ort: Söderköping
Kontakt:

Re: C still powers the world

Inlägg av sodjan »

Många problem där C är inblandat har ju just med hanteringen av "strängar"
och buffrar att göra. T.ex. att förlita sig på att det ska finnas ett null som
avslutar en sträng (istället för att man vet längden). Sen har det med
minnesskydd att göra också, t.ex. att data areor kan exekveras. Och
att exekverbar kod inte är skrivskyddad (så att en "buffer overflow"
kan skriva över exekverbar kod). Det är en kombination av brister i
C i sig och brister i OS'et där det körs.

Även API'erna mot vissa OS system funktioner har brister där man
använder enkla pekare till buffrar/strängar istället för t.ex. "descriptors".
https://en.wikipedia.org/wiki/Data_descriptor
Findecanor
Inlägg: 982
Blev medlem: 2 juli 2010, 23:04:07

Re: C still powers the world

Inlägg av Findecanor »

Alla moderna operativsystem tillåter inte skrivning i programsegment och tillåter inte exekvering i vanliga minnessegment - så länge som hårdvaran stödjer det.
32-bittars x86 har dock inget skydd mot att inte köra från varsomhelst. Det kom först med x86-64.

En attack behöver dock inte alltid skriva över existerande kod - utan det räcker med att skriva över en returadress på stacken med en adress till den kod som hacken vill köra.
När en funktion anropas så lagras först aktuell programadress på stacken för att processorn ska kunna hitta tillbaka. Sedan allockerar funktionen minne på samma stack för sina lokala variabler.
Av historiska skäl växer processorstackar nedåt - och instruktionerna för funktionsanrop gör så - vilket har till följd att returadressen till den anropande funktionen alltid ligger på ett positivt index relativt en lokal array-variabel.
Man skulle kanske komma runt det genom att ha separata stackar för anrop och för data, men det skulle kräva att man allockerade ett extra processorregister just för data - och x86 har ganska få register så prestanda skulle bli lidande.
Användarvisningsbild
lillahuset
Gått bort
Inlägg: 13969
Blev medlem: 3 juli 2008, 08:13:14
Ort: Norrköping

Re: C still powers the world

Inlägg av lillahuset »

Inse att C ursprungligen skapades för PDP-7 1972 med 4kord RAM i grundutförande. Expanderbart till 64k.

Filosofin med C, om jag inte har missuppfattat allt, är ett enkelt språk med bibliotek för mer avancerade saker. Vill man att någon ska hålla handen får man använda lämpliga bibliotek.
Användarvisningsbild
sodjan
EF Sponsor
Inlägg: 43150
Blev medlem: 10 maj 2005, 16:29:20
Ort: Söderköping
Kontakt:

Re: C still powers the world

Inlägg av sodjan »

Findecore, det där undviks väl med descriptors? Då läggs inga lokala variabler
på stacken (om det är för funktionsanropet det gäller) utan descriptors, vilka
ju är en fast struktur som i sig pekar till datat.
jpalsson
Inlägg: 143
Blev medlem: 20 juli 2012, 13:14:41

Re: C still powers the world

Inlägg av jpalsson »

MiaM skrev: Att PASCAL fick ett lyft på åttiotalet har vi väl Borland att tacka för. De gjorde en väldigt snabb och liten kompilator ihop med integrerad utvecklingsmiljö, där allt var så litet att det fram till och med TP 3.0 rent av gick att köra på CP/M på en 8080/8085/Z80. Att kompilatorn inte producerade särskilt bra kod var en annan sak, den var ändå många gånger bättre än t.ex. interpreterande BASIC och det gick många gånger snabbare att skriva sina program än att använda assembler.
TurboC tyckte jag var en höjdare, första gången man fick uppleva hur trevligt ett IDE kan vara, supersnabb dessutom.
MiaM skrev: Vi ska inte glömma att de C-kompilatorer som fanns var en plåga under samma tidsepok. Jag har petat lite på C innan jag hade hårddisk. Då hade jag ändå en dator med "en årslön" av minne, enligt ditt mått av minnespriser :) , dock bara diskettstationer. Det var på den tiden man kunde komma över lösa diskdrives av mer eller mindre märklig typ utan att betala särskilt mycket, så jag hade nog som mest tre diskettstationer varav en var en 80-spårs 5,25" DS/DD-diskdrive vars disketter var inkompatibla med alla andras burkar. Men det gick bra att använda den driven med en diskett för att ha includefiler, libbar å sånt till C-kompilatorn. Tiden det tog att kompilera med disketter var ingen höjdare.

Samtidigt på samma burk, rent av med mindre minne, så gick det att köra en integrerad miljö med editor, assemblator och debugger där enda problemet var att man av lathet ibland inte orkade spara källkoden innan man provkörde senaste ändringen och därför tappade just senaste ändringen ifall man gjort något fel som gjorde att man var tvungen att boota om.
Håller med, innan jag kom över TurboC var jag hänvisad till nåt elände som hette DeSmet C, tog lång tid innan jag litade på att C var nåt att ha
efter den upplevelsen.
Då var kombinationen A86/D86 mycket trevligare på PC:n :-)
MiaM skrev: Jag har inte kört något i ADA själv, men mitt intryck är att ADA försöker vara en slags "plusplus"-motsvarighet till Pascal på det sätt C++ är en påbyggnad av C.
Syrran gick teknisk fysik på Chalmers på 90-talet, där var det ADA-first i alla lägen när det skulle lämnas in uppgifter.
(fast ibland fick hon lämna in körbara filer, då blev det C :-)
MiaM skrev: Den största bristen med C, som hela världen fått lida av många gånger, är att det inte finns någon inbyggd range-checking för framförallt strängar (men även arrayer som ju rent tekniskt är samma sak som strängar i vanlig C).
Nu var det väldigt länge sen jag skrev nåt i C, så kunskapen om hur skyddsmekanismer och annat fungerar nu är väldigt daterad.
Men, jag tror att man vinner mycket på att betrakta C som assembler med ett större utbud av bibliotek, dvs. man måste
ha det här med minneshantering i åtanke hela tiden för att inte råka in i problem.
Användarvisningsbild
hanpa
Utsparkad, på semester
Inlägg: 639
Blev medlem: 22 november 2016, 21:54:43
Ort: Hemort

Re: C still powers the world

Inlägg av hanpa »

Givet att det kommer in många nybörjare i programmering på "Arduino" så skulle man önska att man hade ett mer modernt programmeringsspråk, plus att man borde ha stöd för simulering av allt utan att behöva koppla in diverse komponenter för att provköra. Lite åt hållet som man jobbar med appar för iPhone eller Android.

En "Arduino IDE" baserat på Swift istället för C/C++ vore helt suveränt för då får man ett betydligt modernare programmeringsspråk med utmärkt stöd för att undvika de vanligaste programmeringsfelen dessutom.
Mr Andersson
Inlägg: 1394
Blev medlem: 29 januari 2011, 21:06:30
Ort: Lapplandet

Re: C still powers the world

Inlägg av Mr Andersson »

Swift kräver en runtime och alla former av range checking och minnesskydd kräver extra cpu-cykler och minne. Tror inte det skulle fungera så bra med de begränsade resurser som finns på AVR, främst på minnessidan. På t.ex. ARM och PIC32 tror jag det skulle fungera mycket bra (givet att man har externt ram. det inbyggda brukar vara ganska litet), men då får man en splittrad plattform där avr-arduino använder C och arm-arduino använder swift. Men jag skulle gärna vilja ha en swift-kompilator till bare metal ARM.

Simulatorer finns som tredje-partsprogram men jag har inte än sett någon som fungerar riktigt bra. En simulator som följer med den officiella arduinoprogramvaran skulle vara optimalt.
Användarvisningsbild
TomasL
EF Sponsor
Inlägg: 45175
Blev medlem: 23 september 2006, 23:54:55
Ort: Borås
Kontakt:

Re: C still powers the world

Inlägg av TomasL »

jpalsson skrev: Nu var det väldigt länge sen jag skrev nåt i C, så kunskapen om hur skyddsmekanismer och annat fungerar nu är väldigt daterad.
Men, jag tror att man vinner mycket på att betrakta C som assembler med ett större utbud av bibliotek, dvs. man måste
ha det här med minneshantering i åtanke hela tiden för att inte råka in i problem.
Hmm, C är väl definierat som ett lågnivåspråk jämsides assembler (som iofs inte är något språk, per definition).
Användarvisningsbild
hanpa
Utsparkad, på semester
Inlägg: 639
Blev medlem: 22 november 2016, 21:54:43
Ort: Hemort

Re: C still powers the world

Inlägg av hanpa »

Swift är fortfarande väldigt nytt. Det lär komma nya versioner med mindre behov av runtime och att man kan stänga av olika kontroller i runtime etc. Det fina med Swift är att kompilatorn i sig tar de allra vanligaste problem genom att språket är designat från början för att ge säker kod. Just nu finns det bara för Mac och Ubuntu vad jag vet men det pågår portering till andra plattformar.
Skriv svar