Lähdekoodien ja moduulien organisointi

C-ohjelman perusyksikkö on yksittäinen lähdekooditiedosto (source file), jonka nimen on sovittu päättyvän .c-päätteeseen. Toinen nimi tälle on käännösyksikkö (compilation unit). Lähdekooditiedostossa voi olla yksi tai useampia aliohjelmia tai pelkkää vakiodataa. Ei ole mitään yleistä standardia ohjaamassa, mitä yhteen tiedostoon laitetaan: Siellä voi olla vaikkapa kokonainen 100 000 rivin ohjelma kaikkine määrityksineen ja aliohjelmineen, tai siellä voi olla yksi 30 rivin aliohjelma, tai siellä voi olla vain rimpsu merkkijonoja, joita halutaan käyttää datana. Suosituksena voi maalaisjärjellä ajatella, että yhdessä tiedostossa saisi mieluiten olla hallittavissa oleva määrä yhteen tiettyyn toimintokokonaisuuteen liittyviä asioita. Jos tiedosto alkaa jossain vaiheessa kasvaa liian isoksi, se voi olla hyvä jakaa jollain loogisella perusteella pienempiin osiin.

Lisäksi C-ohjelmiin liittyvät .h-päätteisiksi sovitut ns. otsikkotiedostot (header file). Otsikkotiedostoissa julkaistaan tietorakenteiden määrittelyt ja sovelluksen yhteiseen käyttöön tarkoitettujen .c-tiedostoissa toteutettujen aliohjelmien kutsurajapinnat (eli kunkin aliohjelman "otsikkorivi"). Otsikkotiedostoihin laitetaan siis C-kielellä kirjoitettujen ohjelmamoduulien tai kirjastojen julkiset rajapinnat, joten ne ovat paljolti samassa roolissa kuin uudemmissa oliokielissä luokkien julkiset luokat julkisine metodeineen. Myöskään otsikkotiedostoista ei ole standardia ohjaamassa, mitä yhteen tiedostoon tulee suhteessa .c -päätteisiin lähdekoodeihin. Maalaisjärjellä ajatellen voisi olla fiksua, että esimerkiksi yhtä .c -lähdekooditiedostoa vastaisi samalla alkuosalla nimetty .h -tiedosto, jossa julkaistaan julkiseksi tarkoitetut tyypit ja aliohjelmat juuri kyseisestä .c -koodista. Tarpeen mukaan joko .c tai .h -tiedostot voi olla järkevää nimetä eri tavoin tai jakaa hienojakoisemmin kuin vastinkappaleensa.

Laajemman sovelluksen C-lähdekoodi koostuu yhdestä tai useammasta .c -ohjelmasta ja .h -otsikkotiedostosta.

C:ssä ei ole mitään kiinnitettyä hakemistorakennetta ohjelman osioille, kunhan kääntäjä tietää, mistä sen pitää etsiä .h ja .c -tiedostoja. Maalaisjärjellä ajatellen ohjelma voi olla fiksua jakaa alihakemistoihin sitten, kun sen tarvittavien lähdekoodi- ja otsikkotiedostojen määrä kasvaa niin isoksi, että kokonaisuutta on vaikea hallita yhdessä hakemistossa, tai jos ryhmittely alihakemistoihin on muusta syystä tarpeen esimerkiksi toiminnallisten kokonaisuuksien suhteen. Esimerkiksi kelvannee Linuxin lähdekoodin miljoonien koodirivien jakautuminen käyttöjärjestelmän tyypillisten tehtäväkokonaisuuksien mukaisiin alihakemistoihin (muistinhallinta omassaan, tiedostojen hallinta omassaan, laiteajurit omassaan, jne.).

Valmiiden kirjastojen otsikkotiedostot kuten stdlib.h ovat usein hakemistossa /usr/include (voit huvikseen listata hakemiston jalavassa, halavassa tai itka203-testi:ssä, tietenkin). Tiedostoissa on tosiaan vain "otsikot" eli aliohjelmien ja tietorakenteiden esittelyt sekä erinäisten vakioiden määrittelyjä. Varsinaiset toteutukset eli valmiiksi käännetyt aliohjelmakirjastot ovat usein hakemistossa nimeltä /lib (peruskirjastot) ja /usr/lib (tarpeen mukaan kyseiseen tietokoneyksilöön asennetut lisäkirjastot sovellusohjelmien kääntämistä ja ajamista varten). 64-bittisessä esimerkkijärjestelmässämme vastaavat hakemistot ovat /lib64 ja /usr/lib64. Kääntäjä voidaan ohjata etsimään kirjastoja ja otsikoita muualtakin kuin oletuspaikoista antamalla sille tietyt komentoriviargumentit; sijainteja ei ole sinänsä mitenkään ennalta sovittu.

C-ohjelman sijoittelussa tiedostoihin ja hakemistoihin on siis aika rajaton vapaus. Ohjelmoijalla on kaikki vastuu siitä, että rakenne on selkeä: hyvä ja ylläpidettävä koodi luultavasti on sellainen, joka on jaettu toiminnallisuuden mukaisesti järkevänkokoisiin, samankaltaisia asioita tekeviä tai käsitteleviä aliohjelmia sisältäviin .c-tiedostoihin ja vastaavasti .h-tiedostoihin, jotka julkaisevat .c-tiedostojen rajapinnat muiden moduulien käytettäväksi.

Esimerkiksi Linux-käyttöjärjestelmän ydin on hyvä (tai ainakin käyttökelpoisuudellaan jonkinlaista tunnettuutta kerännyt) kohtalaisen laaja (joitain miljoonia lähdekoodirivejä sisältävä) C-ohjelmisto, jonka organisoinnista ym. käytänteistä mallia ottamalla ei välttämättä mene kovin pahasti pieleen.

Ohjelman luonti: moduulien erillinen kääntö, yhdistäminen linkittämällä

C-ohjelmien lähdekoodi on siis .c ja .h -päätteisiä tekstitiedostoja. C-koodin suorittaminen taas on pääasiassa sitä, kun aliohjelmat kutsuvat toisia aliohjelmia jossakin järjestyksessä. Ajettavassa ohjelmassa on löydettävä jokainen tarvittava aliohjelma, joita voi olla monessa paikassa, mm.:

• itse käännettävässä sovelluksessa, mahdollisesti eri lähdekooditiedostoissa ja -hakemistoissa
• C:n standardiapukirjastoissa (libc, libm, jne.)
• Käyttöjärjestelmän yhteensopivuuskirjastoissa, joiden olemassaolon esim. POSIX määrää (libpthread.so ym.)
• sovelluskohtaisissa apukirjastoissa (esim. laajat grafiikka-, ääni-, pelimoottori-, matematiikka-, ym. kirjastot; esim. libGL.so, libSDL2.so, libsatlas.so ym.).

Isot, monia lähdekooditiedostoja sisältävät, C-ohjelmat käännetään ensiksi erillisesti ns. objektitiedostoiksi, joiden pääte on .o tai .obj. Kussakin objektitiedostossa on vastaavassa lähdekooditiedostossa (eli .c -tiedostossa) olleiden aliohjelmien käännetyt konekielikoodit sekä symbolit (symbol) eli käytännössä aliohjelmien selväkieliset nimet, joiden kautta konekielikoodien sijainti löytyy. Toki objektitiedostoissa voi olla mukana myös metatietoja kuten käännöspäivämäärä, kääntäjän versiotiedot sekä esim. debuggaustietoa kuten alkuperäisen lähdekoodin tiedostonimiä ja rivinumeroita. Linuxissa objektitiedoston muoto on ns. ELF-formaatin mukainen.

Toiminnallisesti samaan asiaan liittyviä objektitiedostoja voidaan yhdistää toisiinsa ns. kirjastoiksi (unix-maailmassa archive eli .a -tiedostot), joissa on siis kaikissa mukaan otetuissa objektitiedostoissa olevien aliohjelmien konekielikoodi. Apukirjastot ovat yleensä tällaisina .a -kirjastoina valmiina liitettäväksi niitä käyttäviin sovelluksiin.

Lopulliseen suoritettavaan ohjelmatiedostoon täytyy luonnollisesti yhdistellä eli linkittää (link) kaikki erillisissä objektitiedostoissa ja kirjastoissa sijaitsevat aliohjelmat ja datat. Tämä ohjelman rakentamisen viimeinen vaihe tehdään käännösvaiheen linkkerillä (engl. linker t. link editor), joka on tätä varten tehty työkaluohjelma. Täsmälleen yhden objektitiedoston pitää sisältää sovitunlainen main() -aliohjelma, että C-ohjelman sisäänmenopiste (entry point) määrittyy yksikäsitteisesti. Tällä tavoin käännetty ja linkitetty lopullinen tiedosto sisältää siis main()-aliohjelman ja mahdollisesti paljon muiden aliohjelmien koodia. Ohjelmaa kutsutaan staattisesti linkitetyksi, mikäli se toimii sellaisenaan ilman lisäkirjastoja. Kaikki tarvittavat objektit on siinä silloin mukana.

Olisi kuitenkin hyvä, jos apukirjaston kaikkia aliohjelmia ei tarvitsisi laittaa mukaan jokaisen niitä käyttävän ohjelman käännökseen. Onhan tilanhukkaa, jos vaikka megatavun kokoinen aliohjelmakirjasto laitetaan kymmeneen eri sovellukseen samanlaisena. Tätä varten useimmiten tehdään staattisen sijasta ns. dynaaminen linkitys (dynamic linking). Varsinkin laajat sovelluskohtaiset apukirjastot (kuten grafiikkakoneistot ym.) kannattaa kääntää ns. paikkariippumattomaksi koodiksi (engl. position independent code) tai ainakin uudelleensijoiteltavaksi (engl. relocatable), jolloin kirjaston koodi ei sisällä "kovakoodattuja" muistiosoitteita, vaan luottaa käyttöjärjestelmän ohjelmalatauksen tai ajon aikana toimivaan dynaamiseen linkkeriin kaikkien sisäisten muistiosoitteidensa suhteen.

Tällainen, useimmiten apukirjastoksi tarkoitettu koodi voidaan tallentaa ja toimittaa käyttäjän tietokoneelle jaettuna objektina (shared object, .so) eli dynaamisesti linkitettävänä kirjastona (dynamically linked library, .DLL). Paikkariippumaton kirjasto voidaan linkittää dynaamisesti sitä tarvitsevan ohjelman virtuaalimuistiavaruuteen: Kirjastoa käyttävän ohjelman käynnistyksen yhteydessä käyttöjärjestelmän linkitysjärjestelmä etsii kirjaston tiedostojärjestelmästä ja liittää sen konekielikoodin käynnistyvän ohjelman muistiavaruuteen. Käännösvaiheen linkitysohjelma on kirjannut ylös tarvittavan kirjaston tiedostonimen sekä symbolit (aliohjelmien ja datapätkien selväkieliset nimet), joita kyseisestä kirjastotiedostosta tarvitaan. Jos käyttäjän tietokoneelle ei ole asennettu jotakin ELFiin kirjattua dynaamisesti linkitettävää kirjastoa, ohjelman käynnistäminen ei tietenkään onnistu.

Etukäteen ei voi tietää, mihin muistiosoitteisiin kirjasto kartoitetaan, joten ajonaikaisen linkkerin täytyy sumplia aliohjelmakutsujen ja vakiodatan muistiviitteet kohdilleen symbolien perusteella. Osoitteiden selvitys on mahdollista tehdä joko ohjelman käynnistyessä tai "laiskasti" ohjelman suorituksen aikana, silloin kun jotakin kirjaston aliohjelmaa tarvitaan ensimmäistä kertaa. Ohjelmalla on mahdollisuus pyytää käyttöjärjestelmältä kirjaston linkittämistä myös ajon aikana, siis jopa kysyä käyttäjältä interaktiivisesti, minkä kirjastoversion hän haluaa liitettävän suoritettavan ohjelman osaksi.

Realistisia käyttötarpeita ajonaikaiselle linkittämiselle voisivat olla esim. konekielisenä jaettuna objektina / DLL:nä toimitetut musiikki- tai grafiikkaohjelmistojen plugin-liitännäiset eli "plugarit", joilla tehdään mitä moninaisimpia erikoisefektejä, mutta kaikkia sataa erilaista ei kannata ladata muistiin ennen kuin tiedetään, mitä muutamaa käyttäjä tällä kertaa tarvitsee.. Näin ohjelma käynnistyy alussa paljon nopeammin, kun ei tarvitse siinä vaiheessa vielä ladata plugareita.

Dynaamisesti linkitettävät kirjastot ovat Windows-maailmassa nimeltään dynamically linked library, .DLL ja Unix-maailmassa shared object, .so. Järjestelystä on etua ainakin seuraavin tavoin:

• Levytilaa kuluu vähemmän, kun useiden ohjelmien tarvitsema dynaaminen kirjasto voidaan tallentaa vain yhdessä paikassa.
• Useat ohjelmat voivat käyttää samaa fyysisessä keskusmuistissa olevaa kirjastoa, koska niiden sijainti kunkin prosessin virtuaalimuistialueella voi olla mikä tahansa. Näin ohjelmien lataamiseen kuluva aika ja keskusmuistin kokonaistarve pienenevät.
• Ohjelmista saadaan modulaarisia -- esim. jos rajapinta pysyy samana, bugikorjaukset tai parannukset ohjelmiin voidaan tehdä päivittämällä vain yksittäinen kirjasto (joka on pienempi kuin kokonaissofta).

Esimerkiksi Javan virtuaalikoneen suorituksessa tavallaan ohjelmat aina "linkittyvät dynaamisesti", koska luokkia (jotka tavallaan vastaavat C:n objektitiedostoja) ladataan muistiin laiskasti tarpeen mukaan. Jos ohjelma ei tarvitse joitain luokkia, niitä ei välttämättä ladata missään vaiheessa. Liitännäisten puuttumisen tai väärän asentumisen saattaa huomata vasta, kun kesken ohjelman suoritusta tulee poikkeus ClassNotFoundException tjsp.

Esimerkiksi jalavan /usr/lib64/ -hakemisto (alihakemistoineen) sisältää melkoisen paljon kirjastoja, joita sovellusohjelmiin voisi linkittää dynaamisesti (".so") tai staattisesti (".a").

Esikäännös: ylimääräinen makrokieli

Ikävä kyllä tämä seuraava kohtalaisen järkyttävä asia on käytävä läpi, ennen kuin C-koodin lukemiseen tulee mitään järkeä.

Perustyökalu käännösprosessin hallintaan: makefile

Demon esimerkkikoodien ohessa on Makefile, joka on työkalu "ohjelmistoprojektin" kokonaisuuden hallintaan, koodien kääntämiseen ja objektitiedostojen yhdistämiseen lopulliseksi tuotteeksi. Make-järjestelmä hoitaa monia asioita automaattisesti, mm. se osaa tiedostojen aikaleimojen perusteella kääntää uudelleen vain ne objektit, joiden lähdekoodi on muuttunut. Erityisesti isojen projektien kohdalla tämä lyhentää käännökseen kuluvaa aikaa dramaattisesti pienen koodimuutoksen jälkeen.

IDEt pitävät yllä vastaavia tietoja osana jonkinlaista "projektikuvausta". Muun muassa kääntäjäohjelman argumentit voivat olla erilaiset riippuen siitä, rakennetaanko ohjelma ilman optimointia ja debuggaustietojen kanssa ("Debug"-versio) vai jyrkällä optimoinnilla ilman debuggaustietoja ("Release"-versio). Makefilessä vastaava hoituisi C-kielisen ohjelman osalta sijoittamalla muuttujaan CFLAGS erilainen sisältö.

Koodien rakentamiseen on olemassa vielä paljon makefileä näppärämpiä työkaluja, mutta niitä ei aivan näin pienessä "projektissa" tarvita. Esimerkiksi Linuxin lähdekoodin rakentaminen toimivaksi binääriksi lepää make-järjestelmän päällä, mutta maken kautta käynnistellään skriptejä, apuohjelmia ja jopa graafisia käyttöliittymiä, joilla käännös konfiguroidaan interaktiivisesti.

Kertaus: mikä olikaan muuttuja

Ohjelmoinnissa voi yleensä määritellä muuttujia. Niillä on nimet, joiden kautta niihin pääsee käsiksi, niihin voi tallentaa dataa operaatioiden suorittamista varten (eli "sijoittaa arvoja muuttujiin"), ja niitä voi käyttää lausekkeissa mm. laskemiseen.

Vahvasti tyypitetyissä kielissä, jollaisia mm. C#, Java ja C ovat, muuttujien käyttöön liittyy rajoituksia: mm. muuttujat pitää esitellä aina tietyn tyyppisiksi, eikä tyyppiä voi enää esittelyn jälkeen muuttaa. Muuttujien tyypit on tunnettava jo ohjelmaa käännettäessä joka tilanteessa.

C#:ssa ja Javassa muuttujat jakautuvat primitiivityyppisiin (C#:n terminologian mukaan arvotyyppisiin) kuten int, double, boolean ja niin edelleen, joiden arvot elävät pinomuistissa sellaisenaan, ja olioviitteisiin, joiden tyyppiin kuuluu tieto siitä, minkä luokan (tai tästä perityn aliluokan) olioon viite vain voi osoittaa.

Viitteiden kohteena olevat oliot eivät ole suorittavan (virtuaalisen) koneen pinossa arvoina samaan tapaan kuin arvotyyppiset muuttujat, vaan kukin viite osoittaa ns. kekomuistissa sijaitsevaan, mahdollisesti hyvinkin monimuotoiseen dataan, jonka ominaisuudet ja käyttäytymisen viitetyypissä mainittu olioluokka metodeineen kuvaa.

Muuttujat eivät näissä kielissä voi olla muunlaisia kuin joko yksittäisiä arvoja tai viitteitä. Pelikenttä on pohjimmiltaan näinkin yksinkertainen. Taulukot ja merkkijonot ovat niissä olioita, joita käytetään vastaavantyyppisten viitteiden kautta. Ne ovat kuitenkin jopa niin usein tarvittuja olioluokkia, että kieliin on nähty tarpeelliseksi määritellä oma syntaksinsa niiden käyttöön ja niiden toteutuksessa saatetaan käyttää suorituskykyä parantavia optimointikeinoja konepellin alla.

Myös C-kielessä on tietyt ''primitiivityyppit'' tai ''arvotyypit'', jotka pitkälti vastaavat C:stä periytyvien oliokielten, kuten C#:n, vastaavia, suoraan lukuarvoina ilmeneviä, tyyppejä. Niiden lisäksi C:ssä on:

• ohjelmoijan määrittelemiä struktuurityyppejä (järjestettyjä yhdistelmiä muista tyypeistä; vähän niinkuin luokkia, joilla on vain julkisia attribuutteja eikä yhtään metodia; struktuurityypeissä voi olla sisällä muita struktuureja, eli rakenne voi olla hierarkkinen). Muita nimiä struktuurille voisi olla rakenne tai tietue.
• taulukkotyyppi kustakin primitiivityypistä tai keskenään samantyyppisistä struktuureista.

Kaikkien edellämainittujen tyyppien mukaiset arvot tallentuvat C-ohjelmassa muistiin peräkkäisinä tavuina, joiden määrä ja järjestys tiedetään käännösvaiheessa. Välissä saattaa olla käyttämätöntä tilaa, mikäli esim. jotkut arvot ovat yksitavuisia ja jotkut monitavuisia. Joka tapauksessa kaikkeen arvo-, struktuuri- ja taulukkodataan pääsee käsiksi valmiiksi käännösvaiheessa lasketulla muistiosoitteella. Näitä muistiosoitteita voi C-kielessä käsitellä suoraan:

• jokaisen tyypin mukaiselle datalle voi määritellä osoittimen, joka kuvaa yhden data-alkion ensimmäisen tavun muistiosoitetta.

Jokainen osoitin on C-kielessä yksinkertaisesti vain kokonaisluku, jossa on riittävän monta bittiä kääntäjän kohteena olevan prosessoriarkkitehtuurin muistiosoitteen tallentamiseksi. Esim. x86-64:ssä osoittimet ovat 64-bittisiä etumerkittömiä kokonaislukuja. Tarpeen tullen C-kielen voi pakottaa käsittelemään osoittimia aivan kuten kokonaislukuja, mutta normaalisti niiden semantiikka eli merkitys on viitteen kaltainen, eli niillä osoitetaan jotakin muuta dataa, ts. viitataan johonkin ''olioon''. Vaikka osoittimet ovat keskenään samanlaisia kokonaislukuja, niiden määrittelyssä pitää ilmoittaa myös niiden osoittaman datan tyyppi, jotta tästä viitesemantiikasta tulee täydellinen ja turvallisempi käyttää. Ilman tietoa tyypistä kääntäjä ei saisi laskettua muistiosoitteita peräkkäin talletetun taulukon sisään, eikä edes rakenteisen struktuurin/tietueen sisäisiin osioihin.

Tyypeistä, viitteistä ja C:n osoittimista

Tyypit kuvaavat sitä, minkä muotoisia tietoja muuttujissa tai muissa objekteissa (oliot tai tietorakenteet) pidetään tallessa ohjelman suorituksen aikana. Arvotyyppien sisältö on käytettävissä saman tien, sellaisenaan kuin se on; viitteen kautta käsiteltävä objekti sijaitsee jonkinlaisen muistiosoituksen tai vastaavan päässä.

C#:ssa ja Javassa olioiden attribuutit eli niiden sisältämä data sijoittuu kekomuistiin omien olioinstanssiensa osana. Virtuaalikone varaa kekomuistista tilaa attribuuteille aina kun tavukoodi käskee luomaan eli instantoimaan uuden olion. Sitten tapahtuu aliohjelmakutsu luokan konstruktorimetodiin. Metodien parametrit sekä niiden lokaalit muuttujat sen sijaan sijoittuvat pinomuistiin, jota tavukoodin virtuaalikonekäskyt käyttävät laskentaoperaatioissa. Olioviite, olipa se lokaali muuttuja, metodin parametri tai olion attribuutti, on arvoltaan olennaisesti jonkun kekomuistissa olevan olion sijaintitieto tai null, ts. ei viittaa/osoita mihinkään juuri tällä hetkellä.

Oliokielen viitekin on siis siinä mielessä "osoitin", että se "osoittaa" olioon. Oliokielissä kuitenkaan ei puhuta osoittimesta, koska termi viite (engl. reference) vapauttaa semantiikan laitteistosta, muistiosoitteista ja kokonaisluvuista tai muista konkreettisista toteutukseen liittyvistä yksityiskohdista - viitteen toteutus voi olla sisäisesti mitä tahansa, kunhan se semanttisesti viittaa olioinstanssiin tai ei mihinkään (null-viittaus). Jollain tapaa viitteet kuitenkin täytyy toteuttaa, että kielillä tehtyjä ohjelmia voidaan oikeasti suorittaa. Yksinkertaisimmillaan viitteen toteutus voisi olla juokseva numerointi ohjelman alusta alkaen syntyneisiin olioinstansseihin tai jopa suora muistiosoite dataan, jossa olioinstanssin tiedot löytyvät. (Mm. perintä tekee oliokielten sisäistä toteutusta monimutkaisemmaksi, koska koko perintähierarkian mukaisten metodien koodit täytyy olla löytyvillä: tervemenoa jatkokursseille ohjelmointikielten periaatteista ja kääntäjätekniikasta ym., mikäli kielten, kääntäjien ja tulkkien teknologia alkaa kiinnostaa enemmän).

C-kielen tapa käyttää muistia on laitteistoläheinen ja laitteiston näkökulmasta paljon yksinkertaisempi kuin oliokielissä: Muuttujilla, osoittimet mukaanlukien, on C:ssä yksi-yhteen vastaavuus laitteistossa suoritettavan prosessin muistiavaruuden sisällön kanssa. Lokaalit tietorakenteet (primitiivimuuttujat ja myös struktuurina määritellyt lokaalit muuttujat) sijaitsevat suorituspinossa kulloisenkin aliohjelman pinokehyksessä (ks. luennot ja materiaali, joka kertoo suorituspinosta ja pinokehyksestä), globaalit, ennakkoon alustetut rakenteet sijaitsevat data-alueella ja dynaamisesti varatut tietorakenteet ovat niille varatulla muistialueella, jota sanotaan keoksi myös C-kielessä. Käyttöjärjestelmän lataaja ja latauslinkittäjä kyhäävät prosessille virtuaalimuistiavaruuden, jossa objektitiedostossa listatut ennaltamäärätyt koodit, datat, nollaksi alustettu aputila, keko sekä dynaamisten kirjastojen tarvittavat osiot sijaitsevat ohjelman startatessa eli prosessorin suorituksen päätyessä executablessa ilmoitettuun aloitusmuistiosoitteeseen. Jos siis ei tullut ongelmia matkalla.

C:n primitiivityyppejä käytetään kuten C#:ssa tai Javassa, eli niiden arvoilla voidaan laskea lausekkeissa. Kääntäjä osaa tuottaa ohjelmakoodin, joka sisältää lokaalien muuttujien oikeat muistiosoitteet suhteessa kullakin hetkellä suorituksessa olevan aliohjelma-aktivaation pinokehyksen sijaintiin (edelleen ks. luennot ja moniste). Tämän lisäksi mihin tahansa muuttujaan voidaan tarvittaessa tehdä osoitin, joka on konkreettisesti alla olevan prosessoriarkkitehtuurin virtuaalimuistiosoite.

Osoitin eli muistiosoite mihin tahansa muuttujaan saadaan C:ssä kirjoittamalla et-merkillä &muuttujan_nimi ja osoittimen osoittamaan arvoon päästään käsiksi tähdellä *osoittimen_nimi. Suomenkielisenä muistisääntönä "tähdätään" arvoon osoitinta pitkin. Englanninkieliset nimet operaattoreille ovat C99-standardin sisällysluettelon mukaan address operator & ja indirection operator *. Ensimmäisen etymologia liittyy toteutukseen muistiosoitteena ja jälkimmäisen sisältödatan "epäsuoraan" käyttöön, eli suoraan saadaan vain muistiosoite ja varsinaisen sisällön saantiin tarvitaan vielä uusi muistihaku tuon osoitteen perusteella.

Taulukoiden alkioiden arvoihin päästään syntaksilla taulukon_alun_osoite[indeksi] ja osoittimen päässä olevan tietorakenteen nimettyyn kenttään/attribuuttiin päästään nuolen näköisellä viivan ja suurempi kuin -merkin yhdistelmällä tietorakenteen_osoite->kentan_nimi. Tämän nimi on standardissa structure pointer operator -> ja "kenttäväki" näyttää tuntevan tämän nimellä arrow operator. Suomenkielisenä muistisääntönä: arvoon pystyy "osumaan nuolella" osoittimen kautta.

Seuraavassa koodissa tehdään osoitin kokonaislukuun ja sitä käytetään perinteisen aloittelijan ymmärrysvirheen takia kauhistuttavan väärin ja vaarallisesti:

/** Aliohjelma, joka palauttaa osoittimen kokonaislukuun:
 * Paluuarvon tyyppi on "int*", missä tähti tarkoittaa osoitinta.
 */

int* tyhma_aliohjelma(){

  int kokonaisluku;
  int *osoitin;

  /* Muuttujan nimeltä 'kokonaisluku' arvo sijaitsee pinokehyksestä
   * sille varatussa paikassa. Samoin muistiosoite nimeltä 'osoitin'.
   * C-kielessä ei luvata kummallekaan mitään tiettyä alkuarvoa.
   * Tässä vaiheessa voivat olla siis mitä tahansa. Erittäin helppo
   * joutua tämän(kin) ominaisuuden vuoksi vaikeuksiin! Kääntäjän
   * varoitukset on syytä laittaa päälle, ja niitä on syytä myös
   * lukea ja ymmärtää!
   */

  /* Sijoitetaan seuraavassa muuttujaan vakioluku 123;
   * käytännössä pinomuistin vastaavaan kohtaan
   * menee silloin lukuarvo 123:
   */

  kokonaisluku = 123;

  /* Osoitinkin on lukuarvo pinossa, mutta sen merkitys on olla
   * jonkun toisen muuttujan muistiosoite; tässä tapauksessa
   * sijoitetaan osoittimen pinokehyspaikkaan kokonaisluku:n
   * pinopaikan muistiosoite:
   */

  osoitin = &kokonaisluku;

  /* Funtsi juttua, ja piirrä tarvittaessa muistin sisällöstä kuvia
   * paperille, ja kysy jos ei muuten hahmotu! Debuggeria meidän pitäisi
   * veivata luennolla, demossa ja oma-aloitteisesti, kunnes tämä on
   * päivänselvää ja selkäytimessä!
   */

  /* Alla oleva on tässä tapauksessa JÄRKYTTÄVÄÄ JA VÄÄRIN
   * koska aliohjelmasta palautetaan muistiosoite, joka viittaa
   * nykyisen pinokehyksen sisään. Tämä kehys lakkaa olemasta
   * returnissa, mutta joku ehkä kuvittelee, että palautettu
   * muistiosoite tarkoittaisi aliohjelma-aktivaation
   * päätyttyäkin jotain järkevää. Ei tarkoita.
   *
   * *************************************************************
   * *   Se on virtuaalimuistiosoite; se osoittaa suorituspinon  *
   * *   sisään. Pinon sisältö vaihtelee aliohjelmakutsujen ja   *
   * *   niistä palaamisen yhteydessä. Muistipaikan käyttö       *
   * *   paikallisen kokonaisluku -nimisen muuttujan säilömiseen *
   * *   loppuu heti tuon seuraavan returnin suoritukseen:       *
   * *************************************************************
   *
   */

  return osoitin;
}

Edellisestä koodista kyllä palautuu muistiosoite, mutta mitään takeita kyseisen muistipaikan sisällöstä ei ole enää kutsusta palaamisen jälkeen!

Eli C:ssä käsitellään asioita hyvin laiteläheisesti. On helppo tehdä erittäin pahoja ohjelmointivirheitä osoittimien kanssa. Kääntäjä ei (aina) osaa varoittaa loogisesti väärin käytetyistä osoittimista, ja ajoaikana varsinkaan ei ole laitteiston ja C-kielestä konekielelle käännetyn ohjelman välissä mitään tuplavarmistuksia kuten C#:ssa tai Javassa on mahdollista virtuaalikoneen kautta toteuttaa. Nämä asiat on syytä ymmärtää mahdollisimman varhaisessa vaiheessa, ennen kuin syystä tai toisesta joutuu esimerkiksi töissä kirjoittamaan tai muokkaamaan C-koodia!

(Täytyy muistaa, että koodin optimointi voi vähän sekavoittaa kuvioita; muuttujan arvoa voidaan nimittäin pitää prosessorin rekisterissä, jolloin se on paljon nopeammin saatavilla laskutoimituksiin kuin pinomuistista. Tehdään tällä kurssilla kaikki käännökset ilman optimointia kääntäjän argumentilla -O0, jotta perusideat selviävät käännöksistä).

Miten edellinen esimerkki sitten olisi tehty ns. oikein? No oikeasti tuollaista aliohjelmaa tuskin tehtäisiin, koska eihän se tee mitään järkevää muutenkaan. Jos tarkoitus on laskea jokin kokonaisluku, niin varmaan ylipäätään tehtäisiin aliohjelma, jonka paluuarvon tyyppi on kokonaisluku eikä osoitin sellaiseen. Alempana tulee järkevämpi esimerkki, jossa luodaan kokonaislukutaulukko. Sellainen isompi rakennelma voi olla viisasta luoda aliohjelmassa, joka tosiaan palauttaa muistiosoitteen.

Osoittimet ovat ikään kuin olioviitteet, mutta varsinaisia olioitahan C-kielessä ei ole (ellei toteuta C:llä kirjastoa tai virtuaalikonetta, joka tarjoaa rajapinnan olioiden käyttöön:)), vaan osoitin osoittaa tavun mittaista muistipaikkaa. Osoitetusta muistipaikasta voi alkaa yksi tietyn tyyppinen primitiivialkio, esim. 8-bittinen tai 64-bittinen luku. Tai yhtä hyvin siitä voi alkaa muistialue, joka sisältää vaikka miten monimutkaisen ja ison tietorakenteen.

Maistelepa huvikseen seuraavia sanontoja, joita voisi ihminen päästää suustaan:

• "Viitemuuttuja osoittaa olioinstanssiin"
• "Osoitinmuuttuja viittaa tietorakenteeseen"
• "Viite olioon"
• "Osoitin tietorakenteeseen".

Näistä toivottavasti hahmottuisi tietty yhteys käsitteiden välillä! Jos ymmärrät viitteen niin ymmärrät pienellä vaivalla osoittimenkin, tai toisin päin. Puhuessaan ihminen voi vahingossa päästää suustaan jomman kumman näistä melkein samaa tarkoittavista sanoista... (Kirjoittaessa voi yrittää parempaa tarkkuutta terminologiassa, kun backspace-näppäin ja tekstieditorin undo-toiminto ovat käytössä.)

Opiskelijan kysymys: Ovatko edellä esitetyt lausumat tosia? Opettajan vastaus: Jaa-a. Kyllä ne melkein ovat. Huomattavia lillukanvarsia olisi edessä siellä, missä käytäisiin rajaa kohteeseen viittaamisen ja kohteen osoittamisen välillä. Tärkeintä lienee koettaa hahmottaa, mitä tarkoittaa se, että operaatioita kohdistetaan entiteettiin, joka ei ole "juuri tässä", mutta jonka sijainti tunnetaan (ts. käytössä on "viite" tai "osoite") jotta kyseiseen entiteettiin on mahdollisuus päästä käsiksi epäsuorasti, sijaintitietojen perusteella. Oliokielissä oliot ovat ajon aikana kekomuistissa ja suurin osa asioista tapahtuu epäsuorasti viitteiden kautta. Saman voi tehdä C-kielessä osoittimien avulla. Ne on vaan tylsästi alla olevan arkkitehtuurin virtuaalimuistiosoitteita, mutta epäsuoria viitteitä "olioihin" yhtä kaikki.

Lausuma "osoitin on viite" on aika lailla totta, koska muistiosoitteita käytettiin nykyisen olioviitteen roolissa aikana, jolloin ei vielä ollut oliokieliä ja nykyistä "viitteen" käsitettä. Lausuma "viite on osoitin" ei ole aivan yhtä totta, jos tarkoitetaan jäykästi (kuten C-kielessä), että "viite on muistiosoite prosessin virtuaalimuistiavaruuteen". Se voi kuitenkin olla totta silloin, jos kielen sisäisessä toteutuksessa viite itse asiassa onkin muistiosoite johonkin tietorakenteeseen, jossa pidetään kirjaa olioinstanssin elämästä.

Arvotyypit (eli ''primitiivityypit'')

C#:ssa ja Javassa spesifikaatiot kertovat, minkä kokoisia (bittien lukumäärällä mitattuna) mitkäkin arvotyypit ovat. Viitemuuttujia ei voi näissä kielissä käyttää laskemiseen, joten niiden sisäisellä toteutustavalla ei ole ohjelmoijalle mitään väliä.

Perinteisen C-kielen arvotyyppien ja osoittimien koko (ikävä kyllä) riippuu prosessoriarkkitehtuurista, jolle kääntäjä on tehty! Standardi määrittelee vain minimipituudet. Tästä päästiin kuitenkin eteenpäin C99-standardissa (ja siten mm. POSIXissa), joka vaatii peruskirjaston puolelta otsikkotiedoston stdint.h, jota käyttämällä ohjelmoija voi ihan suorastaan määrätä, kuinka monta bittiä hän kokonaislukuunsa haluaa. (Matemaattisessa laskennassa tarvittaville liukuluvuille ja niiden binääriesityksille on olemassa omat standardinsa, joita C99 myöskin tukee.)

Koska niitä tulee vanhassa koodissa joskus vastaan, katsotaan ensin itse C-kielessä, ilman yhteensopivuuskirjastoa stdint.h, määritellyt kokonaisluvut, joiden bittisyys saattaa vaihdella kääntäjästä riippuen (varottava siis luottamasta näiden arvoalueeseen):

unsigned char             - etumerkitön 8-bittinen (tai laajempi) luku
signed char               - etumerkillinen 8-bittinen (tai laajempi) luku
char                      - 8-bittinen luku (riippuu kääntäjästä onko
                            etumerkillinen vai ei; eli siirrettävässä
                            koodissa syytä sanoa eksplisiittisesti)

unsigned short int        - 16 bittinen luku, etumerkilliset ja -merkittömät
signed short int
short int

       (voi kirjoittaa myös "unsigned short", "signed short",
       "short" eli voi kirjoittaa ilman int'iä)

unsigned int              - 16 tai 32 bittinen tai muun kokoinen luku,
signed int                  tarkistettava koko aina kääntäjän speksistä.
int                         Jalavan GCC:ssä ilmeisesti 32-bittisiä

       (voi kirjoittaa myös "unsigned", "signed" eli ilman int'iä)

unsigned long int         - mahdollisesti useampibittinen kuin pelkkä int
signed long int             tarkistettava aina kääntäjän speksistä
long int

       (nämäkin voi kirjoittaa ilman int'iä)

unsigned long long int    - mahdollisesti vieläkin useampibittinen
signed long long int        tarkistettava aina kääntäjän speksistä;
long long int               ei edes löydy vanhemmista C-standardeista.

       (nämäkin voi kirjoittaa ilman int'iä)

Liukuluvut:

float                      - single precision (saattaa olla 32-bittinen)

double                     - double precision (saattaa olla 64-bittinen)

long double                - extended double precision (tarkempi kuin double)

Ei-mitään -tyyppi:

void                       - "ei mitään"; käytettävä aliohjelman
                             esittelyssä, jos paluuarvoa ei ole.
                             Voi myös tehdä void* -tyyppisiä
                             osoittimia, millä voi kiertää osoittimen
                             vahvan tyypityksen; mihin tahansa objektiin
                             voi osoittaa void-osoittimella. "Vaarallista",
                             mutta mahdollista, kuten moni muukin juttu.
                             (Ainoa tapa "geneeriseen" ohjelmointiin, jossa
                             halutaan toteuttaa abstrakti tietorakenne mille
                             tahansa alkiotyypille.)

Huomioita:

• "Merkki" eli char on kokonaisluku; sillä voi ajatella koodaavansa ASCII-merkin tai minkä tahansa muun asian, joka numeroituu melko vähillä biteillä (esim. ASCII 7 bitillä, välille 0..127)

  Merkeillä voi laskea yhteen tai vähentää, ne kun on vaan vähäbittisiä lukuja... 'A'+2 == 'C' jos merkistökoodaus on esim. ASCII, jossa 'A', 'B' ja 'C' ovat peräkkäisillä luvuilla koodattu. Huom: POSIX määrää (muistaakseni, tarkista), että merkit 0,1,2,3,4,5,6,7,8,9 ovat koodattu järjestyksessä peräkkäisiin kokonaislukuihin. Minkään muiden merkkien osalta POSIX ei määrää pakollista järjestystä, vaan esimerkiksi aakkosjärjestyksen luominen vaatii, että käytetyt kieli- ja merkistöasetukset tunnetaan ja sovelletaan oikeata järjestystä.

• Uudemmista kielistä tuttua boolean tai bool -totuusarvotyyppiä ei ole C:ssä olemassa aivan sellaisenaan.. C99 määrittelee sen hiukan hassulla nimellä _Bool kokonaisluvuksi, jossa on vähintään yksi bitti. Mikä tahansa kokonaisluku kelpaa C:ssä totuusarvoksi, ja tulkinta on, että 0 on epätosi ja kaikki nollasta poikkeavat arvot tarkoittavat totta. Vertailuoperaattoreiden käyttö loogisessa lausekkeessa koodaa standardin mukaan epätoden kokonaisluvulla 0 ja toden kokonaisluvulla 1.

  C:n jälkeen suunnitelluissa ohjelmointikielissä mm. totuusarvojen käsittely on tehty tavalla tai toisella selkeämmäksi, mutta C-kielen osalta täytyy "mennä niillä mitä on" (ja oli 1970-luvulla).

  Standardikirjaston otsikkotiedosto stdbool.h määrittelee tyypille ja totuusarvoille nätimmät nimet bool, true ja false, ja näitä onkin ihan fiksua käyttää C99-ohjelmissa totuusarvojen ilmaisemiseen. Luonnollisesti käyttö edellyttää lähdekooditiedoston alussa direktiivin #include<stdbool.h>.

  (Määritelmäthän ovat tietysti esikääntäjän makroja, jotka korvautuvat koodissa teksteillä ''_Bool'', ''1'' ja ''0'' ennen varsinaista C-käännöstä... suorakäyttökoneillamme keväällä 2015 tämän tiedoston sijainti on /usr/lib/gcc/x86_64-redhat-linux/4.4.4/include/stdbool.h jos joku haluaa käydä kurkkaamassa, miten C:n standardirajapintaa yksinkertaisimmillaan tuetaan kääntäjän tekijän toimesta. Tässä tapauksessa otsikkotiedostossa on kommenttien lisäksi pelkkiä esikääntäjädirektiivejä 14 kappaletta.)

Katsotaan sitten kokonaislukutyypit siten kuin C99-standardin yhteensopivuuskirjaston stdint.h -otsikkotiedoston vähimmillään tulee ne määritellä:

int_least8_t          - Vähintään 8-bittinen etumerkillinen kokonaisluku
int_least16_t         - Vähintään 16-bittinen etumerkillinen kokonaisluku
int_least32_t         - Vähintään 32-bittinen etumerkillinen kokonaisluku
int_least64_t         - Vähintään 64-bittinen etumerkillinen kokonaisluku

uint_least8_t         - Vähintään 8-bittinen etumerkitön kokonaisluku
uint_least16_t        - Vähintään 16-bittinen etumerkitön kokonaisluku
uint_least32_t        - Vähintään 32-bittinen etumerkitön kokonaisluku
uint_least64_t        - Vähintään 64-bittinen etumerkitön kokonaisluku

Käytännössä nämä ovat kääntäjän ja standardikirjaston tekijän määrittämiä synonyymejä aiemmassa listassa olleille pidemmille tyyppinimille, jotka pohjalla olevan C-kielen spesifikaatio määrittelee kiinnittämättä niiden pituutta tarkemmin. Hyvä puoli näiden kirjastosta löytyvien tyyppinimien käytössä on, että jopa jo vuodesta 1999 alkaen (kun C-kieli oli noin 30 vuotta vanha) saatiin määriteltyä yhteisiä sopimuksia, joiden perusteella ohjelmoija voi tietää, että yhteenlaskun tulos mahtuu oikeasti siihen muuttujaan, johon hän summansa laskee, riippumatta siitä, minkä valmistajan kääntäjällä ja mille laitteistolle koodi käännetään. Uudemmissa kielissä, kuten esimerkiksi Javassa ja sittemmin C#:ssa, on osattu ottaa alusta lähtien huomioon, että bittien määrällä on väliä, joten ne on otettu huomioon jo ensimmäisissä määritelmäversioissa tarkemmin kuin alkuperäisessä C:ssä.

Katsotaan vielä kiinteän kokoiset kokonaislukutyypit tasan 8-, 16-, 32- ja 64-bittisille luvuille. Standardi sallii, että näitä ei tarvitse olla olemassa, mikäli käännetään laitteistoon, joka ei tue näitä nimenomaisia kokonaislukutyyppejä. Kuitenkin jos kääntäjän on mahdollisuus toteuttaa jokin tai kaikki näistä lukutyypeistä järkevällä tavoin, niin siinä tapauksessa standardin mukaisen kirjaston stdint.h -tiedoston täytyy määritellä kyseiset nimet juuri tällä tavoin:

int8_t       - Tasan 8-bittinen etumerkillinen kokonaisluku, jossa
               negatiiviset luvut esitetään erityisesti ns. "kahden
               komplementtimuodossa": -1 = 0xFF, -2 = 0xFE, jne..
               pienin mahdollinen luku on -128 = 0x80 ja suurin
               mahdollinen luku on 127 = 0x7F. Tällainen lukualue
               "pyörähtää ympäri" ylimmän bitin asettuessa:

               ... 126 = 0x7E, 127 = 0x7F, -128 = 0x80, -127 = 0x81 ...

               Etumerkillisten lukujen ympäripyörähdys juuri tällä
               tapaa perustuu sinänsä yleisesti käytettyyn
               2-komplementtiesitykseen, jota C99 eksplisiittisesti
               EI lupaa tyyppimuunnosten yhteydessä. Koodia, joka
               luottaisi tähän ilmiöön, ei missään nimessä saisi
               kirjoittaa.

int16_t      - Tasan 16-bittinen etumerkillinen kokonaisluku (2-kompl.)
               pienin luku -32768 = 0x8000, suurin luku 32767 = 0x7FFF

int32_t      - Tasan 32-bittinen etumerkillinen kokonaisluku (2-kompl.)
               pienin -2147483648 = 0x80000000, suurin 2147483647 = 0x7fffffff

int64_t      - Tasan 64-bittinen etumerkillinen kokonaisluku (2-kompl.)
               pienin -9223372036854775808 = 0x8000000000000000
               suurin  9223372036854775808 = 0x7fffffffffffffff

uint8_t      - Tasan 8-bittinen etumerkitön kokonaisluku, alue 0..255

               Etumerkittömien kokonaislukujen ympäripyörähdys on
               C99:ssä luvattu tapahtuvan suurimmasta luvusta
               nollaan, joten "modulo 256" -laskureita voi huoletta
               tehdä uint8_t -tyypillä, mutta ei int8_t -tyypillä,
               kuten edellä todettiin.

uint16_t     - Tasan 16-bittinen etumerkitön kokonaisluku, alue 0..65535

uint32_t     - Tasan 32-bittinen etumerkitön kokonaisluku, alue 0..0xffffffff

uint64_t     - Tasan 64-bittinen etumerkitön kokonaisluku,
               alue 0..0xffffffffffffffff

               (maksimi on 10-järjestelmässä jotakin useampinumeroista..
               kaksi potenssiin 64 miinus 1. Hintsusti suurempi kuin
               18 triljoonaa eli 18 * 10^18. Heksaesitys riittää meille.)

Useimpiin tarkoituksiin riittää käyttää vähimmäispituuden määrittäviä kokonaislukuja, jotka C99:ssä on välttämättä määritelty. Ohjelmoijan vastuulla on miettiä, kuinka suuria kokonaislukuja hän suurimmillaan käsittelee ja että valittu tyyppi riittää niiden käsittelyyn. Joskus täsmällisellä pituudella saattaa olla väliä, jolloin joutuu maksamaan sen hinnan, että standardin määritelmätekstinkin mukaan ohjelman voi kääntää vain niille alustoille, jotka sattuvat tukemaan juuri kyseisiä lukuesityksiä. (Sovellukset ehdottoman tasamittaisille luvuille todennäköisesti muutenkin liittyvät tiettyyn laitteistoon, joissa jokin tallennustila tai -muoto edellyttää bitti bitiltä tietyn muotoista dataa.)

Hieno homma tämän yksinkertaistetun johdantokurssin kannalta on, että tyyppi uint64_t sattuu olemaan täsmälleen esimerkkilaitteiston eli x86-64:n yleisrekisterien ja muistiosoitteiden mittainen, ja kahden komplementtiesitystäkin laite käyttää, joten etumerkillinen int64_t toimii C-kielessä täysin samoin kuin konekielessä. Debugger-esimerkit saadaan näyttämään nätiltä ja yksinkertaiselta, kun C-koodeissa käytellään näitä tyyppejä ja osoittimia, jotka ovat luonnostaan saman kokoisia!

Struktuuri- eli tietuetyypit eli ohjelmoijan määrittelemät koostetut tyypit

Lokaaleille primitiivityypeille varataan tilaa pinosta tai globaalilta data-alueelta sen verran kuin ne tarvitsevat. C-ohjelmoija voi koostaa primitiivityypeistä isompia ns. tietueita eli struktuureja, jotka ilmenevät muistitilana kaikille jäsenilleen. Esim. seuraavaa tyyppiä voisi käyttää pistemäisen massan kuvaamiseen vaikkapa pelissä, jossa heitetään tykinkuulia (tai vihaisia lintuja tai muuta mitä nyt yleensä voi heittää):

typedef struct {
    double x, y, z;  // Sijainti kolmiulotteisessa avaruudessa
    double massa;    // Kappaleen massa
    int idnumero;    // Kappaleen yksilöivä tunnistetieto
} pistemassa3d;

Käyttöesim:

pistemassa3d kappaleA;    /* kappaleA olisi pistemassa3d -tyyppinen*/

kappaleA.y = -3.0;        /* jäseniin pääsisi käsiksi näin*/
kappaleA.massa = 48.0;    /* jäseniin pääsisi käsiksi näin*/

...

Yllä sijoitus kappaleA.y = -3.0 asettaisi liukuluvun -3.0 muistipaikkaan, joka on varattu kyseiselle tietuekentälle. Kenttä sijaitsee tietueelle varatun kokonaistilan sisällä. Kääntäjä pitää kirjaa siitä, mikä mm. y-kentän osoite on suhteessa kokonaisuuteen. Ohjelmoijalle päin tämä näyttää periaatteessa samalta kuin oliokielessä luokka, jossa on vain julkisia attribuutteja eikä yhtään metodia. Kuitenkin käsitteellisiä eroja on: C-kielessä struktuuri kaikkine arvoineen syntyy oletuksena lokaaliin pinoon eikä mihinkään eri paikkaan, kuten olioille varattuun kekomuistiin. Ja yllä esimerkissä kappaleA ei ole semanttisesti millään tavoin viite tai osoitin, vaan se tarkoittaa koko datakönttää. Siis sijoitus:

pistemassa3d kappaleA, kappaleB;

...

kappaleB = kappaleA;

aiheuttaisi koko kappaleA -tietueen sisällön kopioitumisen kenttä kentältä kappaleB -tietueen vastaaviin kenttiin (käytännössä tapahtuisi tavujen kopiointi muistissa paikasta toiseen). Jotta turhilta siirroilta vältyttäisiin, ja jotta voitaisiin käyttää dynaamista muistinvarausta ja kekomuistia C:ssä, tarvitaan osoittimia yleensä aivan välttämättä.

Osoitintyypit

Mihin tahansa muuttujaan voidaan viitata osoittimella, eli voidaan esitellä vastaavan tyyppinen osoitinmuuttuja, johon voidaan sijoittaa viitattavan muuttujan muistiosoite. Lisäksi, koska osoitinkin on olennaisesti muuttuja, voidaan siihen tehdä osoitin! Siis seuraavanlaiset muuttujat ovat C:ssä yleisiä:

double luku;           /* Primitiivityyppi, liukuluku nimeltä 'luku'*/
double *pluku;         /* osoitintyyppi! Liukuluvun muistiosoite. */
double **ppluku;       /* osoitintyyppi: Liukuluvun osoitteen osoite */
double ***pppluku;     /* edelleen liukuluvun osoitteen osoitteen osoite */

/* jne... eli muistiosoituksen "epäsuoruuden" asteelle ei ole rajoitusta.*/

char **argv;  /* Osoitin joka osoittaa osoittimeen joka osoittaa chariin */
char *argv[]; /* Itseas. sama asia! Taulukot ovat muistiosoitteita.. */

Huomaa, että tyypin syntaksissa osoitin merkitään tähdellä *, joka edeltää välittömästi sen muuttujan nimeä, josta halutaan tehdä osoitin eikä arvo. Se kannattaa kirjoittaa C:ssä kiinni muuttujan nimeen, vaikka olisi mahdollista kirjoittaa se tyypin nimeen. Syy on seuraava C-kielen kommervenkki:

double  a, b;    /* Määritelty kaksi liukulukua arvoina */
double *c, *d;   /* Määritelty kaksi osoitinta liukulukuihin */
double  e, *f;   /* e on arvo, f on osoitin. */
double* g, h;    /* g on osoitin, h on arvo!! Vaara on tässä.*/
double  *i, j;   /* Tämä on toivottavasti selkeämpi kirjoitusasu! */

Huomaa, että vaikka kaikki osoittimet ovat samanlaisia (eli muistiosoitteita, vähintään osoiteavaruuden bittimäärän kokoisia bittijonoja), ne ovat C-kielessä tarkkaan tyypitettyjä: double-osoittimella ei voi osoittaa vahingossa esim. int-muuttujaan (Tahallaan ja tositarkoituksella voi, eräällä syntaksilla, jota tässä ei käsitellä! Mutta jälleen käyttötarkoitukset ovat harvassa ja yleensä sellaisia vältellään. C:ssä ohjelmoijalla on täysi kontrolli kaikesta ja vastuu oikeellisen ohjelman tekemisestä. Turvaverkot ovat minimaalisia; kääntäjän varoitukset ovat yksi sellainen. Paras ohjelma suunnitellaan tietysti niin, että turvalliselta ja vahvasti tyypitetyltä keskitieltä ei tarvitse normaaliolosuhteissa juurikaan poiketa)

Osoitinaritmetiikka

C:ssä on toteutettu ns. osoitinaritmetiikka eli osoittimeen voidaan lisätä ja vähentää lukumääriä: Muistiosoitteethan ovat tyypillisesti aina yhden tavun (8 bittiä) osoitteita, joten esim. jos taulukossa on 4 tavun mittaisia eli 32-bittisiä lukuja, niin aina seuraavan alkion osoittamiseksi pitäisi lisätä muistiosoitteeseen nelonen. Taas jos taulukossa on 64-bittisiä asioita, niin pitäisi lisätä kahdeksan. Taas jos taulukossa on 1234 tavun mittaisia merkkijonopuskureita tai muita datarakenteita, niin ilmeisesti pitää lisätä 1234 että osoitin päätyy osoittamaan seuraavaa alkiota. Koska C-kääntäjä tietää, minkä tyyppiseen (ja minkä mittaiseen) asiaan osoitinmuuttuja osoittaa, niin se osaa tulkita esim. koodin osoitin++ tai osoitin = osoitin + 1 siten että jatkossa osoitetaan seuraavan samantyyppisen alkion ensimmäistä tavua; muistiosoitteeseen ei siis lisätä ykköstä vaan osoitetun tyypin mukaisen arvon koko tavuissa. Mieti läpi ja piirrä ruutupaperille tarvittaessa.

Taulukon toteutus C:ssä

Uudemmissa oliokielissä taulukot ovat käytön kannalta tavallisia olioita (jonkin Object -yliluokan rajapinta on käytössä), vaikka niille on kääntäjän tasolla rakennettu "syntaksisokeria" ja kaiketi tehokas sisäinen toteutustapa. Silloin on olio-ohjelmoinnin kaikki mukavuudet ja herkut käytössä, mm. taulukon pituuden saa attribuutista tai saantimetodista taulukko.length jne. C-kielessä mitään tällaista ei ole -- olioabstraktiota kun ei tueta tämän yksinkertaisen ja laiteläheisen kielen määrittelemillä ominaisuuksilla.

C-kielessä taulukko on muistialue, joka sijaitsee peräkkäisissä, yhden alkion mittaisissa muistipaikoissa (varaustavasta riippuen prosessin pinossa, data-alueella tai dynaamisella alueella eli "keossa"). Mitään muuta se ei ole. Viiden 64-bittisen luvun taulukko nimeltä taul olisi seuraavanlainen:

.                  +-------------------+
Muistipaikka  N+48 | Jotain ihan muuta!|
                   |                   |
Muistipaikka  N+40 |                   |
                   +-------------------+
Muistipaikka  N+32 | taul[4] (8 tavua) |
                   +-------------------+
Muistipaikka  N+24 | taul[3] (8 tavua) |
                   +-------------------+
Muistipaikka  N+16 | taul[2] (8 tavua) |
                   +-------------------+
Muistipaikka  N+8  | taul[1] (8 tavua) |
                   +-------------------+
Muistipaikka  N    | taul[0] (8 tavua) |
                   +-------------------+
Muistipaikka  N-8  | Jotain ihan muuta!|
                   |                   |
Muistipaikka  N-16 |                   |
                   +-------------------+

HUOM: Tässä muistipaikan numero N == taul == &taul[0]
      eli C:ssä taulukkomuuttuja ja osoitin ensimmäiseen
      alkioon ovat samaistettavissa.

Mitään muuta taulukko ei C:ssä ole kuin varattua muistia. Taulukkoon viitataan aina tavallaan muistiosoitteen avulla. Syntaksi vain näyttää kätevältä:

oso = taul;      /* oso saisi arvokseen alkion taul[0] muistiosoitteen! */

aa  = taul[2];   /* Kääntäjä laskisi valmiiksi alkion taul[2]
                    muistipaikan, ja aa saisi siellä sijaitsevan
                    lukuarvon */

paa = &taul[2]   /* Tässä kääntäjä laskisi alkion taul[2] muistipaikan,
                    ja nimenomaan se muistipaikka eli osoite
                    laitettaisiin muuttujaan paa, jonka pitäisi
                    olla tyypiltään osoitin samantyyppiseen tietoon,
                    kuin mitä taulukko sisältää */

hmm = taul + 2;  /* "Osoitinaritmetiikan" vuoksi sama kuin edellinen. */

HUOMAA: Kukaan ei kerro ajonaikaisesti, minkä verran taulukolle on varattu muistista tilaa! Taulukon käyttö C-kielessä edellyttää aina sitä, että ohjelmoija pitää ihan itse kirjaa taulukoiden koosta jossain muuttujassa tai vakiossa. Esimerkiksi aina kun aliohjelmalle annetaan parametrina taulukko (eli ensimmäisen alkion muistiosoite), se tarvitsee tavalla tai toisella tiedon myös siitä, mihin taulukko päättyy, eli missä on viimeinen käsiteltävä alkio. Helpoimmillaan tämän voi antaa erillisenä kokonaislukutyyppisenä parametrina, johon laitetaan taulukon alkioiden lukumäärä.

Merkkijonon toteutus C:ssä

C#:ssa ja Javassa merkkijonot voidaan tehdä esim. String tai StringBuffer -luokkien instansseina, mitä niiden nimet nyt kussakin kielessä sattuvat olemaan. Tässäkin on olio-ohjelmoinnin mukavuudet ja herkut käytössä: mm. merkkijonon pituuden saa tietää olion rajapinnan kautta, esim. Javassa metodilla merkkijono.length() ja C#:ssa ominaisuudella merkkijono.Length. Muuttuvaisella jonolla eli StringBuffer tai StringBuilder -luokan oliolla on mahdollisuus pidentyä ja lyhentyä mielivaltaisia määriä metodien suorituksen yhteydessä. C-kielessä mitään tällaista ei ole - ei ole olioita rajapintoineen.

C-kielessä merkkijono sijaitsee taulukossa, johon on varattu tilaa ``char``-tyyppisille muuttujille vähintään merkkijonon merkkien verran plus yksi. Plus yksi sen takia, että C:ssä merkkijonon loppu pitää ilmoittaa "nollamerkillä", siis char-tyyppisellä kokonaisluvulla 0. Tästä nähtiin luennoilla esimerkki "Hei maailma" -sovelluksen tavujonoa katsomalla. Sama ilmiö löytyy sekä C-kielisessä että Assembler-kielisessä versiossa. Esimerkiksi merkkijonon "Au" sijoittuminen muistiin voisi olla seuraavanlainen:

.                  +-------------------+
Muistipaikka  N+6  | Jotain ihan muuta!|
                   |                   |
Muistipaikka  N+5  |                   |
                   +-------------------+
Muistipaikka  N+4  | jono[4] 'x'       |
                   +-------------------+
Muistipaikka  N+3  | jono[3] 'y'       |
                   +-------------------+
Muistipaikka  N+2  | jono[2] '\0' eli 0|
                   +-------------------+
Muistipaikka  N+1  | jono[1] 'u'       |
                   +-------------------+
Muistipaikka  N    | jono[0] 'A'       |
                   +-------------------+
Muistipaikka  N-1  | Jotain ihan muuta!|
                   |                   |
Muistipaikka  N-2  |                   |
                   +-------------------+

Eli merkkijonon alku on jossain muistipaikassa ja merkkijonolle on varattu tilaa viiden yksitavuisen merkin verran (yksi tavu riittää ASCII- tai UTF-8 -koodatuille ameriikan aakkosille; ääkkösten ja muiden maailman kielien käsittely on monimutkaisempaa, joten ohitetaan se suosiolla tässä johdannossa). Koska jono on "Au" eli siinä on merkit 'A' ja 'u', ne ovat vastaavissa paikoissa taulukkoa. Niiden jälkeen on nolla, joka kertoo, että jono päättyy siihen. Muilla taulukon arvoilla ei ole merkitystä, koska niitä ei tulkita kuuluvaksi merkkijonoon enää nollamerkin jälkeen, vaikka ne mahtuvat merkkijonolle varattuun muistialueeseen. Merkit 'x' ja 'y' voisivat yhtä hyvin olla lukuarvot 123 ja 234 tai ihan mitä vaan. Ei väliä; merkityksellinen merkkijono loppui jo merkkiin, joka tuli viimeisenä ennen nollaa.

Sanotaan, että varattu muistitila on merkkijonopuskuri (string buffer), johon mahtuu nollamerkkikoodauksen takia korkeintaan "puskurin koko - 1" merkkiä pitkä jono.

Vaihtuvankokoisten merkkijonojen käyttö C-kielessä edellyttää erillisen apukirjaston tekemistä, joka hoitaa mm. isompien puskurimuistien varaamista dynaamisesti, mikäli puskuriin ollaan lukemassa enemmän kuin nykyiseen tilaan mahtuu.

Tietoturvaan liittyvä välihuomautus

Seuraava huomautus on välttämätöntä ja toisaalta hyvin soveliasta tehdä tässä vaiheessa, vaikka tietoturvaan liittyvät seikat käydäänkin tarkemmin syventävillä kursseilla. Kyseessä on yksi hyvä esimerkki havaituista käytännön ongelmista, joita voidaan osittain yrittää ratkaista uusilla teknologisilla ja ohjelmistollisilla keinoilla. Loppupäätelmänä on kuitenkin, että ainakin näinä päivinä tietoturva on vielä paljolti ohjelmistojen tekijöiden vastuulla.

Jos vahingossa merkkijonopuskuriin sijoitettaisiin esimerkiksi käyttäjän syötteestä enemmän merkkejä kuin sinne mahtuu, olisi kyseessä "puskurin ohikirjoitus" eli Buffer overrun/overflow, joka on historiallisesti erittäin suosittu ja helppo tapa murtautua tietojärjestelmiin -- jos kirjoitetaan merkkejä (eli tavuja) sopivasti yli puskurialueen, saatetaan päästä kirjoittamaan niitä jopa muistiosoitteeseen, jossa olisi suoritettavaa koodia. Sinne voisi kirjoittaa sopivilla merkeillä mitä tahansa konekieltä ja saada tietokone tekemään ihan mitä itse haluaa. Vertaa luentoesimerkkiin, jossa merkkijono "Hello, hello, hello!" sijaitsee juuri ennen suoritettavaa ohjelmakoodia. Merkkijonon tavujen (ja nollamerkin) perässä ovat suoritettavan konekielisen ohjelmakoodin tavut. Entä jos ohjelma pelkän tulostamisen lisäksi lukisikin käyttäjältä jonkun oman tervehdystekstin kyseisen oletustervehdyksen tilalle? Herrajeesus, jos käyttäjän syötteestä vahingossa luettaisiin tavuja yli merkkijonolle varatun tilan - suoritettava koodi muuttuisi tietenkin ihan miksi vain tuo kyseinen käyttäjä haluaisi. Eihän hän voi arvata, että ohjelmassani on sellainen aukko? Ei kun kyllä hän vaan tosiaankin tietää, jos hän tutkii ohjelmani toimintaa vaikka disassemblynä ja haluaa käyttää riittävästi aikaa löytääkseen sieltä käyttökelpoisen tietoturva-aukon!

Tällainen hyökkäys onnistuu ihan vain vastaamalla ohjelman kysymykseen "Who are you?", jos sen tekijä ei osannut ohjelmoida C:llä turvallisesti! Onneksi prosessorien muistinsuojaus nykyään jonkun verran auttaa... ajettavan koodialueen tai vakiomerkkijonoja sisältävän data-alueen virtuaaliosoitteet voivat olla kirjoitussuojattuja, jolloin ohjelma kaatuu ns. suojausvirheeseen, jos joku konekielikäsky yrittää sijoittaa koodialueelle. Toista oli ennenvanhaan, kun suojaus prosessori- ja käyttöjärjestelmäteknologian puolesta oli alkeellisempaa. Vielä ihan muutama vuosi sitten erään sinänsä sangen hyödyllisen ja yleisesti tunnetun pilvipalvelun asiakasohjelmisto vaati toimiakseen pinoalueen suoritusoikeutta... asiaa vähänkään tuntevalle tällainen on aivan järkeenkäymätön mörkö. Onneksi myös kyseinen softa on sittemmin päivitetty tältä osin järkevämmäksi.

Varovaisuudesta ei saa ikinä tinkiä: C-ohjelman, joka lukee merkkejä yhtään mistään, TÄYTYY olla toteutettu siten, että varattu puskurialue ei missään nimessä ylity! Mitä tämä taas edellyttää? Sitä, että ohjelmoija pitää kirjaa puskurille varatusta tilasta, vaikkapa jossakin muuttujassa, ja käyttää sellaisia algoritmeja, jotka hyödyntävät tuon tiedon. Sama asia siis kuin muidenkin taulukoiden yhteydessä.

Olisiko ratkaisu olla käyttämättä vanhaa ja vaaralliseksi todettua C-kieltä ja käyttää sen sijaan jotakin uudempaa virtuaalikoneen päällä toimivaa tai tulkattavaa kieltä? ... Yksi vastaus löytyy lukemalla uutisia näiden uudempien alustojen havaituista tietoturvaongelmista ja ekstrapoloimalla jonkinlainen arvio toistaiseksi havaitsemattomien ongelmien määrästä. Sovellusohjelmoijan ainoa oikea johtopäätös käytetystä kielestä tai alustasta riippumatta on: Varovaisuudesta ei saa ikinä tinkiä. Mieti mitä teet, tiedä mitä teet, tiedä mitä satunnainen käyttäjä pystyy halutessaan tekemään. Ja jos sillä on oikeasti väliä, varmista että lisäksi vielä joku muu validoi sen mitä olet tehnyt. Joissain sovelluksissa, kuten siviililentokoneita ohjaavien ohjelmistojen tekemisessä, on erittäin tarkkaan standardoidut menettelyt ohjelmakoodin laadunvarmistukseen. Ikävä kyllä tavallisten ei-lentävien softien tekemisessä ei ole mitään globaalisti valvottua laatustandardia, vaan siellä ollaan aikalailla omalla ja firman vastuulla liikenteessä.

Tervemenoa jatkokursseille Tietoverkkoturvallisuus, Ohjelmistoturvallisuus ja muu Informaatioturvallisuuden maisterikoulutuksen kurssitarjonta, mikäli aihepiiri alkaa kiinnostaa enemmän. (Kaksi nimeltä mainittua kurssia kuuluvat suurimpaan osaan tietotekniikan nykyisistä maisterikoulutuksista -- eivät ole huonoja kursseja muillekaan alan toimijoiksi haluaville.)

Muita tyyppejä

C:ssä on pari muutakin eksoottista tyyppiä, jotka jätetään opiskeltavaksi tarkemmin muusta lähteestä tarvittaessa:

• enum eli lueteltu tyyppi:

  enum {APPELSIINI, OMENA, PAARYNA};
  

  määrittelisi lukuarvot APPELSIINI==1, OMENA==2, PAARYNA==3; voi käyttää esimerkiksi vaihtuvien tilojen koodaamiseen.

• union tyyppi, joka itse asiassa vaihtaa tyyppiä sijoituksen mukaan; varmaan aiheuttanut monta sekaannusta ja vaikeaselkoisuutta ajan mittaan, veikkaan. On tämä joskus näppäräkin, mutta ehkä ihan syystä jätetty pois myöhemmistä, muutoin C:n pohjalta määritellyistä, kielistä, kuten C# ja Java.