core dump Ohjelman kaatuessa tietynlaisiin virheisiin (erityisesti muistivirheeseen, segmentation fault), sen senhetkinen tila (muistin kuva) voidaan tallettaa levylle ns. core dumppina. Nykyisin tämä on yleensä oletuksena estetty, mutta ohjelmankehitysvaiheessa se kannattaa sallia, Bourne- tyyppisissä shelleissä (bash, ksh jne) komennolla ulimit -c unlimited csh:n tyyppisissä vastaavasti limit coredumpsize unlimited Dumpin koolle voi myös antaa

core & gdb Debuggerit kuten gdb osaavat lukea core dumppeja, ja niillä voi helposti katsoa mihin kohtaan ohjelma kaatui ja mitkä olivat muuttujien arvot sillä hetkellä. $ gdb a.out core (gdb) p a Muuttujanimien yms käyttö edellyttää, että ohjelma on käännetty -g optiolla.

Yleisiä bugeja ● Määrittelemättömän muuttujan käyttö. Yleensä kääntäjä valittaa tästä, mutta jos ao. muuttujanimi sattuu olemaan ulompana (kirjastossa tms) määritelty, koodi saattaa kääntyä mutta toimia (joskus hyvinkin oudolla tavalla) väärin ● Alustamattoman muuttujan käyttö. Tästä kääntäjä ei yleensä osaa valittaa, koodi saattaa joskus toimia, joskus ei. Vaikka jotkin muuttujat (static ym) alustetaankin automaattisesti, siihen ei kannata luottaa.

● Vertailun (==) ja sijoituksen (=) sekoittaminen. Joskus kääntäjä osaa varoittaa tästä, joskus ei. ● Puolipiste väärässä paikassa, erityisesti ehdon perässä (“if (x); {... }” yms). ● Kokonaislukujakolasku: /-symbolia käytetään sekä kokonaisluku- että liukulukujakolaskuun joskus hieman hämäävillä säännöillä (esim. “float x = 1/2;”)

● Taulukon ylivuoto. Ehkä kaikkein yleisin tietoturva- aukkojen syy. Tyypillisiä tilanteita: taulukon määritteleminen yhtä liian pieneksi, virheellinen lopetusehto silmukassa, merkkijonofunktioiden käyttö kokoa tarkistamatta, scanf(“%s”...), gets(); debuggausvinkki: watchpoint taulukon viimeiseen alkioon tai sen jälkeen lisättyyn ylimääräiseen muuttujaan.

● Funktion käyttö ilman prototyyppiä: tästä seuraa helposti virheellinen tyyppimuunnos ja oudosti satunnaisen näköisesti väärin toimiva koodi. Erityisesti funktion määrittelyn ollessa samassa tiedostossa myöhemmin prototyyppi helposti unohtuu (kääntäjä tosin usein varoittaa). Erikoistapauksena #include'n puuttuminen. ● Virheelliset/puuttuvat tyyppimuunnokset. Kääntäjä yleensä valittaa, ei kuitenkaan aina (muuttuvien parametrilistojen kanssa, vanhan ei-prototyyppikoodin kanssa).

● scanf, printf ja &: milloin tarvitaan, milloin ei ● scanf ja väärä formaatti: kääntäjä ei huomaa ● scanf(“%s”...) ja tyhjiä sisältävät merkkijonot ● merkkivakiot ('a') vs. merkkijonovakiot (“a”) ● merkkijonojen vertailu ==:lla ja kopiointi =:lla ● merkkijono ilman loppu-\0:aa ● merkkijono johon loppu-\0 ei mahdu

● fgetc, getc, getchar: palautusarvo on int, ei char (“char c; while ((c=getchar()) != EOF) {...” ● feof(): kertoo _edeltävän_ operaation jälkeisen tilan (“while (!feof(f)) {...” EI yleensä toimi oikein) ● syöttöpuskurin tyhjentämättä jättäminen (scanf jne jättävät ylimääräiset sinne seuraavan lukuoperaation löydettäväksi ● switch ja break'in puuttuminen

● && ja || vs. & ja | ● && ja || ja logiikkavirheet (“while (!(a==10) || !(a==20)) {...” ● “a < b < c”, “a == b == c” yms ● prioriteettivirheet (liian vähän sulkuja) ● liian vähän sulkuja makromäärityksissä ● sivuvaikutukset makroissa ● kirjastofunktioiden nimien uudelleenkäyttö ● kirjastofunktioiden virhekoodien tarkistamatta jättäminen

libusb Libusb on käyttäjätason rajapinta USB-laitteiden käyttöön Linuxissa (ja *BSD:ssä ja OsX:ssä). (Varoitus: libusb on muuttumassa, tulollaan oleva versio 1.0 on monin paikoin erilainen kuin nyt käytössä oleva ja tässä kuvattu 0.1 -versio.)

Tyyppejä: struct usb_bus linkitetty lista (next, prev) linkki laitelistan alkuun struct usb_dev linkitetty lista devnum, descriptor, config struct usb_device_descriptor bDeviceClass, idVendor, idProduct,...

● usb_find_busses ● usb_find_devices ● usb_get_busses ● halutun laitteen haku linkkilistasta ● usb_claim_interface, usb_release_interface ● usb_open, usb_close ● usb_set_configuration ● usb_control_msg, usb_get_string...