Tiedetään että C:n syntaksi on erilaista kuin Pascal:n
Mutta onko C:ssä jotain sellaista mitä Pascal:ssa (FreePascal) ei olisi?
Jos on niin mitä?
C Pascal
34
170
Vastaukset
- koodijunnu2
Molemma kielet ovat Turing-täydellisiä kieliä, joten samat ajettavat ohjelmat voi tehdä kummalla tahansa kielellä. Siten erot tulevat juurikin syntaksista. Esimerkiksi C:ssä voit määritellä muuttujan begin mutta et Pascalissa.
- aluksimelkosamaa
Olen samaa mieltä, että kumpikin on samanlaisia aluksi, mutta c:ssä on sitten paljon enemmän laajentumismahdollisuuksia jos uudet asiat alkavat kiinnosta alkuopettelun jälkeen. Oliot ja kaikki sisäkkeiset muuttuja ja struktuurien sekä muut ihmeelliset määrittelytyypit.
Alussa melko samaa, syntaksi on vain erilainen, laajentumismahdollisuuksien takia suosittaisin kyllä c:tä, vaikka se onkin aluksi hieman vaikeaa syntaksiltaan, mutta helposti oppii. - 41234234234234234
Pascalin kanssa voi syntyä ongelma jos pitää saada yhteyksiä Ring-0 eli järjestelmän tason käyttöihin.
aluksimelkosamaa kirjoitti:
Olen samaa mieltä, että kumpikin on samanlaisia aluksi, mutta c:ssä on sitten paljon enemmän laajentumismahdollisuuksia jos uudet asiat alkavat kiinnosta alkuopettelun jälkeen. Oliot ja kaikki sisäkkeiset muuttuja ja struktuurien sekä muut ihmeelliset määrittelytyypit.
Alussa melko samaa, syntaksi on vain erilainen, laajentumismahdollisuuksien takia suosittaisin kyllä c:tä, vaikka se onkin aluksi hieman vaikeaa syntaksiltaan, mutta helposti oppii."Oliot ja kaikki sisäkkeiset muuttuja ja struktuurien sekä muut ihmeelliset määrittelytyypit."
Tuota....c:ssä ei ole olioita...c :ssa on...struct:it toki löytyy.
1. C kieli on unix arkkitehtuurin natiivikieli
2. C kielen käytäntö kutsua aliohjelmia on erilainen kuin Pascalin, ja C kielen käytäntö on defacto. Tämä tarkoittaa sitä, että C kieliset kirjastot saadaan toimimaan muuallakin kun Pascal kielisiä ei käytännössä saa.
3. Pascal kieli standardissa muodossa on tiettävästi surkea ja jopa sellainenkin juttu kuin lähdekoodin lisäys taisi tapahtua jollain standardinvastaisella extensiolla. Pascal kieliset ohjelmat eivät siis ole niin hyvin siirrettäviä.
Käytännössä Pascal on jokseenkin kuollut kieli eikä sitä käytetä oikein missään. Joskus 5v sitten oli vielä Borlandin omaa variaatiota, Object Pascalia käytössä Delphi työkalussa mutta nykyään lähinnä ylläpidetään jotain ikivanhoja legacyjä joita ei ole kirjoitettu uudelleen (eikä ilmeisesti edes aiota, poistuvat vähitellen käytöstä).- fpc 2.6.4
Eräs esimerkki miten tehdään ja käytetään jaettuja kirjastoja Pascalilla (
testattu freepascal 2.6.4:llä joka on julkaistu vuonna 2014, mutta ei tämä ole
mikään uusi asia)
Aliohjelmakirjasto voidaan tehdä niin että valitaan Luo uusi projekti kohdassa
Aliohelmakirjasto
Täydennä alla kuvatunlaiseksi
----8 - cdecl
Pascal:ssa aliohjelmien kutsutapa ei ole "kiinnitetty" tiettyyn tapaan. Ohjelmoija voi kiinnittää ne aliohjelmat joita hän haluaa (esim. jaetut kirjastot).
Jos halutaan käyttää C-kielen tapaa niin sekin on mahdollista!
Kun lisätään aliohjelman esittelyyn sana: cdecl ; niin käytössä on C-kielen tapainen kutsutapa. cdecl kirjoitti:
Pascal:ssa aliohjelmien kutsutapa ei ole "kiinnitetty" tiettyyn tapaan. Ohjelmoija voi kiinnittää ne aliohjelmat joita hän haluaa (esim. jaetut kirjastot).
Jos halutaan käyttää C-kielen tapaa niin sekin on mahdollista!
Kun lisätään aliohjelman esittelyyn sana: cdecl ; niin käytössä on C-kielen tapainen kutsutapa.Ei kyllä taida olla Pascalin ominaisuus vaan riippuu työkalusta... Tuskin on standardi tapa.
Vielä kun joku osaisi perustella miksi pitäisi kiduttaa itseään jollain Pascalilla kun siitä on aika jo mennyt ohi. Vai onko tarkoituksena joku nostalgiafiilistely, vähän niin kuin Cobolilla tekisi ohjelmia?- tuoonhuomattavaero
Oliot eli struktuurit (struct {}), joita voi ajonaikana itseluoda, jopa itsekursiivisia globaaleita funktiota käyttäen näiden "olioiden eli struktuurien sisällä" ja täydentäen ovat C:ssä mahdollisia, koska niihin voivat vaikuttaa toisten yhtäaikaa ajossa olevien globaalien funktioiden samanaikaiset muut globaalit funktiot sekä muuttujat ;)
- ettäsillälaillese
cdecl kirjoitti:
Pascal:ssa aliohjelmien kutsutapa ei ole "kiinnitetty" tiettyyn tapaan. Ohjelmoija voi kiinnittää ne aliohjelmat joita hän haluaa (esim. jaetut kirjastot).
Jos halutaan käyttää C-kielen tapaa niin sekin on mahdollista!
Kun lisätään aliohjelman esittelyyn sana: cdecl ; niin käytössä on C-kielen tapainen kutsutapa.Tuollainen esim. "struct" määritelmä, joka määrittää jonkun funktiojoukon sekä koko ohjelman kääntäjäkohtaista syntaksia voi täysin määritellä #define-tiedostoissa, voit antaa pre-processorille sellaisessa tiedossa käskyn että "#defin struct BEGIN_ALREADY", jolloin kääntäjä tottelee koko loppuohjelman tuota uutta syntaksia joka on sen tietyn ohjelman kääntämistä varten tehty ;)
M-Kar kirjoitti:
Ei kyllä taida olla Pascalin ominaisuus vaan riippuu työkalusta... Tuskin on standardi tapa.
Vielä kun joku osaisi perustella miksi pitäisi kiduttaa itseään jollain Pascalilla kun siitä on aika jo mennyt ohi. Vai onko tarkoituksena joku nostalgiafiilistely, vähän niin kuin Cobolilla tekisi ohjelmia?"Oliot ja kaikki sisäkkeiset muuttuja ja struktuurien sekä muut ihmeelliset määrittelytyypit."
kyllä cdecl taitaa olla suht. "de-facto" pascal työkaluissa.
"Vielä kun joku osaisi perustella miksi pitäisi kiduttaa itseään jollain Pascalilla kun siitä on aika jo mennyt ohi."
Täysin samaa mieltä.- Vastaus perustuuu
code_red kirjoitti:
"Oliot ja kaikki sisäkkeiset muuttuja ja struktuurien sekä muut ihmeelliset määrittelytyypit."
kyllä cdecl taitaa olla suht. "de-facto" pascal työkaluissa.
"Vielä kun joku osaisi perustella miksi pitäisi kiduttaa itseään jollain Pascalilla kun siitä on aika jo mennyt ohi."
Täysin samaa mieltä.Miten ison Pascal ohelman olet tehnyt?
Oletko kokeillut sitä toisessa käyttöjärjestelmässä?
- cdecl
Pascal:ssa lisätään aliohjelman esittelyyn sana: cdecl ; niin käytössä on C-kielen tapainen kutsutapa. Tämä tapa on tullut (kai) aikoinaan Turbo Pascaliin. Siinä vaiheessa kun haluttiin käyttää eri ohjelmakirjastoja (viime vuosituhannella). Myös Delphissä kuten FreePascalissa on tämä tapa.
- joo pa
M-Kar kirjoitti:
Mutta ei siis ole Pascalin tapa vaan on työkalukohtainen viritys.
cdecl toimii kaikissa tällä vuosikymmenellä ilmestyneissä Pascaleissa (valmistajasta riippumatta).
Mitä järkeä olisi tehdä se erilailla (jos koodarit ovat käyttäneet sitä jo yli parikymmentä vuotta)? joo pa kirjoitti:
cdecl toimii kaikissa tällä vuosikymmenellä ilmestyneissä Pascaleissa (valmistajasta riippumatta).
Mitä järkeä olisi tehdä se erilailla (jos koodarit ovat käyttäneet sitä jo yli parikymmentä vuotta)?Mitä järkeä on tehdä sitä Pascalilla joka vaatii ylimääräistä, standardinvastaista säätämistä kun voisi asian tehdä fiksumminkin, esim. C:llä ?
- näinpä1
M-Kar kirjoitti:
Mitä järkeä on tehdä sitä Pascalilla joka vaatii ylimääräistä, standardinvastaista säätämistä kun voisi asian tehdä fiksumminkin, esim. C:llä ?
Standardin vastaista on esim. tehdä C tai C# grafiikka ohjelmia!
Esim. tulostaminen on ainoastaan sallittu standarditulostusvirtaan! - Höpö höpö
näinpä1 kirjoitti:
Standardin vastaista on esim. tehdä C tai C# grafiikka ohjelmia!
Esim. tulostaminen on ainoastaan sallittu standarditulostusvirtaan!Höpö höpö.
näinpä1 kirjoitti:
Standardin vastaista on esim. tehdä C tai C# grafiikka ohjelmia!
Esim. tulostaminen on ainoastaan sallittu standarditulostusvirtaan!C kielelle on standardoituja grafiikkarajapintoja, jotka ovat tehty C-kielellä.
- fffffffffee
M-Kar kirjoitti:
C kielelle on standardoituja grafiikkarajapintoja, jotka ovat tehty C-kielellä.
Osaatko sanoa mitä ne ovat? Ainakin nuo yleisimmät ikkunointijärjestelmät muuttuvat niin useasti ja ovat erilaisia (että tuskin niistä löytyy standardia).
Mutta joku X Window System tai openGL voisi olla (Ovat ainakin yleiskäyttöisiä kirjastoja ) ? Olisi kiva tietää mikä standardi on sen/niiden takana.
Ja jos on standardoitu niin todennäköisesti samaan standardiin nojautuu useampi valmistaja/tekijä (kilpailevia kirjastoja joiden väliltä voi valita)?
Kerro nyt ihmeessä! fffffffffee kirjoitti:
Osaatko sanoa mitä ne ovat? Ainakin nuo yleisimmät ikkunointijärjestelmät muuttuvat niin useasti ja ovat erilaisia (että tuskin niistä löytyy standardia).
Mutta joku X Window System tai openGL voisi olla (Ovat ainakin yleiskäyttöisiä kirjastoja ) ? Olisi kiva tietää mikä standardi on sen/niiden takana.
Ja jos on standardoitu niin todennäköisesti samaan standardiin nojautuu useampi valmistaja/tekijä (kilpailevia kirjastoja joiden väliltä voi valita)?
Kerro nyt ihmeessä!"Osaatko sanoa mitä ne ovat?"
Vanha Xlib sekä Motif ovat jo ikivanhoja standardeja (UNIX 98 workstation) mutta sitä ei välttämättä kannata enää käyttää. Mutta, esim. GTK 2 on standardoitu (ISO/IEC International Standard 23360), kuten myös Xlib löytyy tästä).
OpenGL:stä vastaa Khronos Group ja tämä on käytännössä konsortio johon kuuluu käytännössä ~kaikki alan yritykset ja jonka tarkoitus on ylläpitää specifikaatioita. "Open standards for graphics, media and parallel computation".
"Ja jos on standardoitu niin todennäköisesti samaan standardiin nojautuu useampi valmistaja/tekijä (kilpailevia kirjastoja joiden väliltä voi valita)?"
Kyllä, samoja standardeja käyttää useampi valmistaja/tekijä. GTK 2:sta esimerkiksi tukee Attachmate, Canonical, Debian ja Red Hat. OpenGL:ää nyt löytyy melkein joka paikasta.
Standardeissa on standardoitu kirjaston rajapinta ja kirjasto voi myös olla sama usealla valmistajalla jos lisensointi mahdollistaa sen. GTK 2 ja Motif perustuvat nykyisin käytännössä kaikki samaan koodiin eri valmistajilla.- muunneltavatrakentee
M-Kar kirjoitti:
"Osaatko sanoa mitä ne ovat?"
Vanha Xlib sekä Motif ovat jo ikivanhoja standardeja (UNIX 98 workstation) mutta sitä ei välttämättä kannata enää käyttää. Mutta, esim. GTK 2 on standardoitu (ISO/IEC International Standard 23360), kuten myös Xlib löytyy tästä).
OpenGL:stä vastaa Khronos Group ja tämä on käytännössä konsortio johon kuuluu käytännössä ~kaikki alan yritykset ja jonka tarkoitus on ylläpitää specifikaatioita. "Open standards for graphics, media and parallel computation".
"Ja jos on standardoitu niin todennäköisesti samaan standardiin nojautuu useampi valmistaja/tekijä (kilpailevia kirjastoja joiden väliltä voi valita)?"
Kyllä, samoja standardeja käyttää useampi valmistaja/tekijä. GTK 2:sta esimerkiksi tukee Attachmate, Canonical, Debian ja Red Hat. OpenGL:ää nyt löytyy melkein joka paikasta.
Standardeissa on standardoitu kirjaston rajapinta ja kirjasto voi myös olla sama usealla valmistajalla jos lisensointi mahdollistaa sen. GTK 2 ja Motif perustuvat nykyisin käytännössä kaikki samaan koodiin eri valmistajilla.Selitän vielä että "rekursiivinen funktio", eli c:ssä sanotaan että, sellainen että kun on eri tavoilla määriteltyjä funktioita esim. jonkun "olion" eli struktuurin sisällä, niin kaikissa tilanteessa voi määritellä aina jokaisen funktion jokaisen muuttujan staattiseksi sen funktion sisällä, struktuurin sisällä tai koko ohjelmalle.
Esim. kun kerran tutkin opengl:n lähdekoodia, niin juuri näissä 3d-laskennoissa oli hyödynnetty tuota ominaisuutta, että on struct { ... struct { ---, ja funktioiden kaikkien sisällä paljon eri tavoilla määriteltyjä muuttujia, jolloin se perusfunktio palauttaa arvon kun on sen saanut valmiiksi).
Itse tein eräälle firmalle, ja opetin toimistosihteeriä myös silloin samalla: osasi käyttää Exceliä, sellaisen ohjelman, joka muodostaa ja tulostaa excel-taulukkoon syötetyistä laskutustiedoista, aivan pankin näköisen, virallisen laskun laser-tulostimella.
Tuossa excelin sekä tietokantojen lukemisen ja manipuloimisen apuna käytin visualbasicia. Tuli aika hyvä, aina kun aika on kirjoittaa lasku niin syöttää vain numerot ja painaa nappia, niin tulee oikean muotoinen lasku ulostimesta, ja laskun numero juoksee automaattisesti. - kaksi koodia
M-Kar kirjoitti:
"Osaatko sanoa mitä ne ovat?"
Vanha Xlib sekä Motif ovat jo ikivanhoja standardeja (UNIX 98 workstation) mutta sitä ei välttämättä kannata enää käyttää. Mutta, esim. GTK 2 on standardoitu (ISO/IEC International Standard 23360), kuten myös Xlib löytyy tästä).
OpenGL:stä vastaa Khronos Group ja tämä on käytännössä konsortio johon kuuluu käytännössä ~kaikki alan yritykset ja jonka tarkoitus on ylläpitää specifikaatioita. "Open standards for graphics, media and parallel computation".
"Ja jos on standardoitu niin todennäköisesti samaan standardiin nojautuu useampi valmistaja/tekijä (kilpailevia kirjastoja joiden väliltä voi valita)?"
Kyllä, samoja standardeja käyttää useampi valmistaja/tekijä. GTK 2:sta esimerkiksi tukee Attachmate, Canonical, Debian ja Red Hat. OpenGL:ää nyt löytyy melkein joka paikasta.
Standardeissa on standardoitu kirjaston rajapinta ja kirjasto voi myös olla sama usealla valmistajalla jos lisensointi mahdollistaa sen. GTK 2 ja Motif perustuvat nykyisin käytännössä kaikki samaan koodiin eri valmistajilla.Standardilla on merkitystä vasta sitten jos koodipohja on eri. Standardin ideanahan on se että
siihen nojautuvat järjestelmät voivat vaihtaa eri valmistajaan (eri koodiin) "lennossa".
Lisäksi jos koodipohja on sama menetetään se etu että jos koodissa on haavoittuvuus niin
sitä ei pysty kiertämään vaihtamalla valmistajaa. Siksi on hyvä että tarjolla on useampi tekijä joka käyttää samaa rajapintaa mutta eri koodia sen alla! kaksi koodia kirjoitti:
Standardilla on merkitystä vasta sitten jos koodipohja on eri. Standardin ideanahan on se että
siihen nojautuvat järjestelmät voivat vaihtaa eri valmistajaan (eri koodiin) "lennossa".
Lisäksi jos koodipohja on sama menetetään se etu että jos koodissa on haavoittuvuus niin
sitä ei pysty kiertämään vaihtamalla valmistajaa. Siksi on hyvä että tarjolla on useampi tekijä joka käyttää samaa rajapintaa mutta eri koodia sen alla!"Standardilla on merkitystä vasta sitten jos koodipohja on eri. Standardin ideanahan on se että siihen nojautuvat järjestelmät voivat vaihtaa eri valmistajaan (eri koodiin) "lennossa"."
Voi se valmistaja olla eri, mutta koodi samaa pohjaa.
Ja tämähän on itseasiassa se ideaalinen tilanne. Jos ne olisi eri koodista rakennettu niin niissä kuitenkin olisi versioeroja ja säätämistä kun standardointi on helposti epätäydellistä kun on kyse jostain monimutkaisesta. On paljon helpompaa standardoida joku ASCII merkistö kuin joku ohjelmointirajapinta.
"Lisäksi jos koodipohja on sama menetetään se etu että jos koodissa on haavoittuvuus niin sitä ei pysty kiertämään vaihtamalla valmistajaa."
Ne ohjelmakomponentit jotka ovat standardin asemassa (esim. zlib) ovat kyllä niin hyvin hinkattua koodia että ei tarvitse ottaa stressiä mistään turva-aukoista.- FreePascal_koodaaja
M-Kar kirjoitti:
"Standardilla on merkitystä vasta sitten jos koodipohja on eri. Standardin ideanahan on se että siihen nojautuvat järjestelmät voivat vaihtaa eri valmistajaan (eri koodiin) "lennossa"."
Voi se valmistaja olla eri, mutta koodi samaa pohjaa.
Ja tämähän on itseasiassa se ideaalinen tilanne. Jos ne olisi eri koodista rakennettu niin niissä kuitenkin olisi versioeroja ja säätämistä kun standardointi on helposti epätäydellistä kun on kyse jostain monimutkaisesta. On paljon helpompaa standardoida joku ASCII merkistö kuin joku ohjelmointirajapinta.
"Lisäksi jos koodipohja on sama menetetään se etu että jos koodissa on haavoittuvuus niin sitä ei pysty kiertämään vaihtamalla valmistajaa."
Ne ohjelmakomponentit jotka ovat standardin asemassa (esim. zlib) ovat kyllä niin hyvin hinkattua koodia että ei tarvitse ottaa stressiä mistään turva-aukoista."Ne ohjelmakomponentit jotka ovat standardin asemassa (esim. zlib) ovat kyllä niin hyvin hinkattua koodia että ei tarvitse ottaa stressiä mistään turva-aukoista."
OpenSSL cryptography library - sehän on myös ollut avoimen lähdekoodin fanaatikkojen (eli fanaattisesti GPL -lisenssiä kannattavien) tekeleissä "standardin asemassa", joten M-Karin mukaan varmaankin "on kyllä niin hyvin hinkattua koodia että ei tarvitse ottaa stressiä mistään turva-aukoista."
Mutta kuinkas kävikään:
https://en.wikipedia.org/wiki/Heartbleed
Jos tuo OpenSSL olisi koodattu Objectpascalilla ja käännetty Freepascalilla, niin tuota Heartbleedia ei olisi koskaan ollutkaan.
Mutta tosiasia on se, että niin kauan kuin C ja C -kielten käyttöä yleisesti jatketaan, niin kauan tietoturva-aukkoja on ja tulee aina olemaan.
Jos C ja C -kielten käyttö kertakaikkiaan lopetettaisiin liian vaarallisena ja kirjoitettaisiin kaikki uusiksi Objectpascalilla, niin rikollisille koittaisivat kovat ajat, kun tietoturva-aukkoja ei löytyisi enää mistään.
Sopiikin epäillä, että C ja C -kielten vahva asema johtuu siitä, että illuminaatit ja vapaamuurarit ovat pitäneet ja edelleen pitävät huolta siitä, että yritysmaailmassa suositaan näitä vaarallisia ohjelmointikieliä.
Kas kun näin taataan, että käytännössä kaikissa C:llä ja C :lla koodatuissa ohjelmistoissa on 1 tai useampi tietoturva-aukko, ja ne on sinne tahallaan laitettu siksi, että näin esim. NSA:n on illuminaattien pyynnöstä helpompi murtautua mihin tahansa tietojärjestelmään.
C:n ja C :n suorastaan kiduttavan kryptinen syntaksi on tahallaan suunniteltu vaikeaksi ymmärtää. Näin varmistetaan se, että kun kyseisiä kieliä käyttävä koodari joutuu käyttämään 95% aivokapasiteetistaan hankalan ja ikävän syntaksin hallintaan niin muuhun koodaustyöhön jää enää 5%, tämä riittää varmistamaan, ettei koodaaja enää hallitse kokonaisuutta, vaan tietoturva-aukkoja aina syntyy.
FreePascalilla onkin kiva kirjoitella tietoturvallista koodia, menköön NSA:n pojat murtautumaan sen kilpailevan yrityksen järjestelmiin, jotka on C:llä ja/tai C :lla koodattu, siksi kilpailijan järjestelmän murtaminen on paljon helpompaa.
Kun järjestelmä koodataan huolellisesti Objectpascalilla, tulee NSA:n pojille suru puseroon, kun eivät kovasta yrittämisestä huolimatta löydä yhtään turva-aukkoa itse sovelluksesta.
Kuinka monta turva-aukkoa sitten löytyy itse käyttöjärjestelmästä, se on hyvä kysymys. Ja jos löytyy, ovatko ne ulkoapäin internetistä tulevien hyökkääjien hyödynnettävissä ?
Ketjussa väitetään Pascalilla tai Objectpascalilla koodaamisen olevan itsekidutusta.
Tosiasiassa asia on juuri päinvastoin: C:llä tai C :lla koodaus on itsekidutusta.
Mutta M-Karia suuresti häiritsee se, että esim. pascalin ja objectpascalin cdecl; -kutsutapamäärite ei ole ISO:n virallisesti standardoima. Mutta miksi edes tarvitsisi olla, kun se kuitenkin toimii samoin kaikissa tällä vuosituhannella julkaistuissa pascal / objectpascal -kääntäjissä.
Virallisella standardoinnilla ei saavuteta mitään etua, mutta haittoja kyllä:
Jos asiasta tehtäisiin virallinen standardi, niin dokumentointi eli asiakirjat olisivat ISO:n tekijänoikeuksien alaisia, eikä dokumentointia voisi enää avoimesti julkaista netissä, ei ainakaan maksamatta lisenssimaksuja ISO:lle.
Kuka ne sitten maksaisi?
Ei kukaan, vaan dokumentointi jouduttaisiin poistamaan julkisesta kaikkien saatavilla olevasta netistä, ettei tekijänoikeuksia loukattaisi.
Objectpascal -koodaajat osaavat hommansa ilmankin, että ISO järjestönä puuttuisi asioihin ja tulisivat rahastamaan tekijänoikeusvaateillaan.
Vaikkapa ruuvien ja mutterien kierteissä viralliset standardit ovat hyvä asia, ne takaavat yhteensopivuuden.
Mutta ohjelmointimaailmassa, kuka haluaa maksaa ylimääräistä siitä, että laaditaan tarpeettomia standardeja, ja dokumentointi siirtyy maksumuurin taakse?
Ehkä C ja C -koodaajat ovat niin hölmöjä, että haluavat maksaa.
ObjectPascal -koodaajien ei onneksi tarvitse, ei ainakaan itse ohjelmointikielen osalta. FreePascal_koodaaja kirjoitti:
"Ne ohjelmakomponentit jotka ovat standardin asemassa (esim. zlib) ovat kyllä niin hyvin hinkattua koodia että ei tarvitse ottaa stressiä mistään turva-aukoista."
OpenSSL cryptography library - sehän on myös ollut avoimen lähdekoodin fanaatikkojen (eli fanaattisesti GPL -lisenssiä kannattavien) tekeleissä "standardin asemassa", joten M-Karin mukaan varmaankin "on kyllä niin hyvin hinkattua koodia että ei tarvitse ottaa stressiä mistään turva-aukoista."
Mutta kuinkas kävikään:
https://en.wikipedia.org/wiki/Heartbleed
Jos tuo OpenSSL olisi koodattu Objectpascalilla ja käännetty Freepascalilla, niin tuota Heartbleedia ei olisi koskaan ollutkaan.
Mutta tosiasia on se, että niin kauan kuin C ja C -kielten käyttöä yleisesti jatketaan, niin kauan tietoturva-aukkoja on ja tulee aina olemaan.
Jos C ja C -kielten käyttö kertakaikkiaan lopetettaisiin liian vaarallisena ja kirjoitettaisiin kaikki uusiksi Objectpascalilla, niin rikollisille koittaisivat kovat ajat, kun tietoturva-aukkoja ei löytyisi enää mistään.
Sopiikin epäillä, että C ja C -kielten vahva asema johtuu siitä, että illuminaatit ja vapaamuurarit ovat pitäneet ja edelleen pitävät huolta siitä, että yritysmaailmassa suositaan näitä vaarallisia ohjelmointikieliä.
Kas kun näin taataan, että käytännössä kaikissa C:llä ja C :lla koodatuissa ohjelmistoissa on 1 tai useampi tietoturva-aukko, ja ne on sinne tahallaan laitettu siksi, että näin esim. NSA:n on illuminaattien pyynnöstä helpompi murtautua mihin tahansa tietojärjestelmään.
C:n ja C :n suorastaan kiduttavan kryptinen syntaksi on tahallaan suunniteltu vaikeaksi ymmärtää. Näin varmistetaan se, että kun kyseisiä kieliä käyttävä koodari joutuu käyttämään 95% aivokapasiteetistaan hankalan ja ikävän syntaksin hallintaan niin muuhun koodaustyöhön jää enää 5%, tämä riittää varmistamaan, ettei koodaaja enää hallitse kokonaisuutta, vaan tietoturva-aukkoja aina syntyy.
FreePascalilla onkin kiva kirjoitella tietoturvallista koodia, menköön NSA:n pojat murtautumaan sen kilpailevan yrityksen järjestelmiin, jotka on C:llä ja/tai C :lla koodattu, siksi kilpailijan järjestelmän murtaminen on paljon helpompaa.
Kun järjestelmä koodataan huolellisesti Objectpascalilla, tulee NSA:n pojille suru puseroon, kun eivät kovasta yrittämisestä huolimatta löydä yhtään turva-aukkoa itse sovelluksesta.
Kuinka monta turva-aukkoa sitten löytyy itse käyttöjärjestelmästä, se on hyvä kysymys. Ja jos löytyy, ovatko ne ulkoapäin internetistä tulevien hyökkääjien hyödynnettävissä ?
Ketjussa väitetään Pascalilla tai Objectpascalilla koodaamisen olevan itsekidutusta.
Tosiasiassa asia on juuri päinvastoin: C:llä tai C :lla koodaus on itsekidutusta.
Mutta M-Karia suuresti häiritsee se, että esim. pascalin ja objectpascalin cdecl; -kutsutapamäärite ei ole ISO:n virallisesti standardoima. Mutta miksi edes tarvitsisi olla, kun se kuitenkin toimii samoin kaikissa tällä vuosituhannella julkaistuissa pascal / objectpascal -kääntäjissä.
Virallisella standardoinnilla ei saavuteta mitään etua, mutta haittoja kyllä:
Jos asiasta tehtäisiin virallinen standardi, niin dokumentointi eli asiakirjat olisivat ISO:n tekijänoikeuksien alaisia, eikä dokumentointia voisi enää avoimesti julkaista netissä, ei ainakaan maksamatta lisenssimaksuja ISO:lle.
Kuka ne sitten maksaisi?
Ei kukaan, vaan dokumentointi jouduttaisiin poistamaan julkisesta kaikkien saatavilla olevasta netistä, ettei tekijänoikeuksia loukattaisi.
Objectpascal -koodaajat osaavat hommansa ilmankin, että ISO järjestönä puuttuisi asioihin ja tulisivat rahastamaan tekijänoikeusvaateillaan.
Vaikkapa ruuvien ja mutterien kierteissä viralliset standardit ovat hyvä asia, ne takaavat yhteensopivuuden.
Mutta ohjelmointimaailmassa, kuka haluaa maksaa ylimääräistä siitä, että laaditaan tarpeettomia standardeja, ja dokumentointi siirtyy maksumuurin taakse?
Ehkä C ja C -koodaajat ovat niin hölmöjä, että haluavat maksaa.
ObjectPascal -koodaajien ei onneksi tarvitse, ei ainakaan itse ohjelmointikielen osalta."Mutta kuinkas kävikään:"
Tuohan korjattiin ennätysnopeasti. Eikä tarvinnut sovelluskehittäjältä mitään toimia, tuli ihan käyttöjärjestelmän päivityksistä.
"Jos C ja C -kielten käyttö kertakaikkiaan lopetettaisiin liian vaarallisena ja kirjoitettaisiin kaikki uusiksi Objectpascalilla, niin rikollisille koittaisivat kovat ajat, kun tietoturva-aukkoja ei löytyisi enää mistään."
Kovat ajat koittaa siitä kun Lazarus ei ole stabiili vaan kerta vuoteen jotain paskotaan rikki. Pelkkä ohjelmointikieli ei niiltä turva-aukoilta suojaa.
"C:n ja C :n suorastaan kiduttavan kryptinen syntaksi on tahallaan suunniteltu vaikeaksi ymmärtää."
Tosiasiassa C:n ja C :n syntaksi osoittautui menestyksekkääksi koska se oli selkeä, nopeata kirjoittaa ja helppo lukea. C ja C jyräsi Pascalin. Eikä ainoastaan sitä vaan myös Ada:n jonka syntaksi on Pascalin kaltainen. On vaan paljon parempi kieli kuin mikään Pascal. C:n ja C :n syntaksia sitten apinoi Java, C#, PHP, Javascript, Typescript jne.
Tuntuu siltä, että vasta nämä Ruby, CoffeeScript, Python jne. tuovat jotain etua syntaksiin selkeyden osalta.
"Mutta ohjelmointimaailmassa, kuka haluaa maksaa ylimääräistä siitä, että laaditaan tarpeettomia standardeja, ja dokumentointi siirtyy maksumuurin taakse?"
Standardoi sitten vaikka W3C:ssä jos siltä tuntuu. Ja mikään ei muuten estä tekemästä toteutusta ensin, dokumentoi sen ja sitten vasta standardoi.- Turbo_P
M-Kar kirjoitti:
"Mutta kuinkas kävikään:"
Tuohan korjattiin ennätysnopeasti. Eikä tarvinnut sovelluskehittäjältä mitään toimia, tuli ihan käyttöjärjestelmän päivityksistä.
"Jos C ja C -kielten käyttö kertakaikkiaan lopetettaisiin liian vaarallisena ja kirjoitettaisiin kaikki uusiksi Objectpascalilla, niin rikollisille koittaisivat kovat ajat, kun tietoturva-aukkoja ei löytyisi enää mistään."
Kovat ajat koittaa siitä kun Lazarus ei ole stabiili vaan kerta vuoteen jotain paskotaan rikki. Pelkkä ohjelmointikieli ei niiltä turva-aukoilta suojaa.
"C:n ja C :n suorastaan kiduttavan kryptinen syntaksi on tahallaan suunniteltu vaikeaksi ymmärtää."
Tosiasiassa C:n ja C :n syntaksi osoittautui menestyksekkääksi koska se oli selkeä, nopeata kirjoittaa ja helppo lukea. C ja C jyräsi Pascalin. Eikä ainoastaan sitä vaan myös Ada:n jonka syntaksi on Pascalin kaltainen. On vaan paljon parempi kieli kuin mikään Pascal. C:n ja C :n syntaksia sitten apinoi Java, C#, PHP, Javascript, Typescript jne.
Tuntuu siltä, että vasta nämä Ruby, CoffeeScript, Python jne. tuovat jotain etua syntaksiin selkeyden osalta.
"Mutta ohjelmointimaailmassa, kuka haluaa maksaa ylimääräistä siitä, että laaditaan tarpeettomia standardeja, ja dokumentointi siirtyy maksumuurin taakse?"
Standardoi sitten vaikka W3C:ssä jos siltä tuntuu. Ja mikään ei muuten estä tekemästä toteutusta ensin, dokumentoi sen ja sitten vasta standardoi.C osoittaitui menestykseksi siksi että c-kääntäjä oli/on helppo tehdä. Turbo Pascal jyräsi kaikki muut Pascalit. Se oli nopein, siinä oli älykäs kääntäjä, innovatiivinen tuote jne. ylivoimainen tuote aikanaan. Turbo Pascalin heikkous oli se että sillä oli "väärä" valmistaja. Se rajoittui vain PC:n ja Appleen.
Turbo_P kirjoitti:
C osoittaitui menestykseksi siksi että c-kääntäjä oli/on helppo tehdä. Turbo Pascal jyräsi kaikki muut Pascalit. Se oli nopein, siinä oli älykäs kääntäjä, innovatiivinen tuote jne. ylivoimainen tuote aikanaan. Turbo Pascalin heikkous oli se että sillä oli "väärä" valmistaja. Se rajoittui vain PC:n ja Appleen.
Muistelehan tarkemmin. Turbo Pascal oli todella edullinen, ja juuri tämän edullisuuden ansiosta Pascal yleensäkin selvisi hengissä.
Oikeat C kääntäjät olivat kalliimpia silloin 80-luvulla- Turbo__P
M-Kar kirjoitti:
Muistelehan tarkemmin. Turbo Pascal oli todella edullinen, ja juuri tämän edullisuuden ansiosta Pascal yleensäkin selvisi hengissä.
Oikeat C kääntäjät olivat kalliimpia silloin 80-luvullaApplehan käytti Pascalia hyvin pitkän ajan käyttöjärjestelmän pohjassa mm, Macien ( Lisan) käyttöjärjestelmä oli pascalilla kirjoitettu.
- Turbo__P
M-Kar kirjoitti:
Muistelehan tarkemmin. Turbo Pascal oli todella edullinen, ja juuri tämän edullisuuden ansiosta Pascal yleensäkin selvisi hengissä.
Oikeat C kääntäjät olivat kalliimpia silloin 80-luvullaTurbo Pascal oli hurjan nopea verrattuna USCD pascaliin ja Algorin Pascaliin verrattuna (Microsoftin pascal oli myös raskaskäyttöinen). Lisäksi Turbo Pascalissa kääntäminen tapahtui heti. Turbo Pascalin tutustumisen jälkeen kaikki muut kielet olivat hyvin kankeita ja hitaita (muita kieliä (lähinnä c) oli pakko käyttää kun Turbo Pascal tuki vain PC:tä).
- hardwareohjelmointia
Tarkennan vielä tuota että mitä tarkoittaa "rekursiivinen struct, tai funktio" vaikka yhdessä:
struct abc { funktio(funktio(a));funktio(.x) struct g {struct abc)}}
Jos C:ssä kirjoitat, noin niin jossain kielessä tuollainen voisi olla loppumaton looppi, eli silmukka, funktio, joka kutsuu itse itseään jatkuvasti, mutta muuttujamäärittelyt ovatkin c:ssä sitten hieman laajempia kai kuin pascalissa.
pascalissa kai: funktio a(.. kutsuu itseään, eli funktio a()), itsensä sisältä, tuollainen on rekursiivista toimintaa, tuollainen.
Luulisi että ratkaisua ei synny, mutta ulkopuoliset tekevät sen ratkaisun sitten, joku ulkopuolinen funktio tai ohjelmiston tarkkailema fyysinen osa, hardwaresta tietokoneessa vaikka, kuten esim. DMA:n kanavan muistilaskuri, kun kerran ajoitin souraan in-portista, emolevyllä olevan DMA-piirin muistiosoitteesta että milloin lähtee aina välillä pois tuollaisesta rekursiivisesta silmukasta :D - AonkinEeikäO
Niin "numero-C:stä" minulla ei ole mitään kokemusta, mutta ainakin tavallisessa C:ssä sekä C :ssa kaikki toiminnot olivat täysin samanlaisia, joiltain oli vain vähän muutettu nimiä.
Periaatteessa C-kääntäjän saisi toimimaan Pascal-kääntäjän tavoin jos käyttäisi näitä #define-tiedostoja, joita se käsittelee ennen ohjelman kääntämistä.
#define a y -> aiheuttaa silloin että kääntäjä tulkitsee jokaisen a-kirjaimen y-kirjaimeksi ohjelmaa kääntäessään :)
Suuri etu on c:n kannalta on ehkäkin muistin käsittelyssä, on äärimmäisen helppoa varata suuriakin muistialueita, vaikka teratavuja dynaamiseen käyttöön välittömästi ;) - moniaCominaisuuksia
C:n muistinkäsittelystä myös eräs erikoinen piirre: jos näytönkiihdyttimessä on paljon muistia, tulee sellaisia c-kielisiä ajureita c-kääntäjää varten, yleensä paremmat kääntäjät muutenkin tarjoavat mahdollisuuden jakaa sitä käyttämätöntä grafiikkamuistia PCI-E -väylän kautta muihinkin käyttötarkoituksiin, muussa dynaamisessa muistissa, tulee sellainen optio, mutta pitää varata erikseen sillä optiolla normaalin RAM:n mukaan käyttöön.
- vanhojahyviä
Kerron hauskan jutun, kun meillä on kotipaikalla sellainen vanha Spectravideo, jouiuisin joskus tulee otettua esille ja pelataan tankki-peliä tai Spectronia sillä :)
Virittelee käyttöön, niin ja Ninja on kanssa niitä hyviä pelejä sillä.
Ketjusta on poistettu 1 sääntöjenvastaista viestiä.
Luetuimmat keskustelut
Metsäkoneen kuljettaja huuteli tutkijalle
"voisit kyllä ottaa rintaliivit pois ennen kuin tulet minulle juttelemaan, hän sanoo." https://yle.fi/a/74-20106446 On70410100Suomi on täysin sekaisin
Jo ties monettako päivää hirveä itku ja poru jostain helvetin nilviäisistä. https://www.is.fi/taloussanomat/art-20000104154422Kaikki ei vieläkään usko luontokatoon.
Suomussalmen Hukkajoella foliohattu metsäkoneen kuljettaja tuhosi tuhansia harvinaisia jokihelmisimpukoita eli raakkuja913036Sano vain suoraan, että nyt riittää
ettei kiinnosta. Sano, että lopeta! En ihmettelisi, jos olet saanut tarpeeksesi ja toivot minun ymmärtävän lopettaa. Eh432865Ohhoh! Ex-pääministeri Sanna Marinin Joni-rakas paljasti ilouutisen: "Tässä kuussa..."
Sanna Marin on ollut naimisissa Markus Räikkösen kanssa. Nyt hänen seurassaan on usein julkkishiusmuotoilija Joni Willb552674Mari Rantanen asettaa sairaan lapsen edun oman uransa edelle - (tekikö Marin samaa)
Noin toimii kunnon vastuuntuntoinen äiti, mutta siitäkin nämä mt-ongelmaiset vasemmistolaiset häntä täällä haukkuvat. "2302668- 1531855
Luokatonta toimintaa
Tyrmistyttävää toimintaa Stora Enson korjuu yrittäjältä Hukkajoella. Täyttä piittaamattomuutta laeista ja luontoarvoista731722Ensimmäisestä kohtaamisesta saakka
minulla on ollut hämmentynyt olo. Miten voit tuntua siltä, että olisin tuntenut sinut aina? Sinun kanssasi on yhtä aikaa141630Maailmankuulu homopingviini on kuollut
Minä niin toivoin että pariskunta olisi saatu kunniavieraiksi ensi kesän Prideen. 💔 "Maailmankuulu homopingviini on k61433