Programozás

Március 4-én megjelent a tcl 8.4.2.0-as verziója, olvasható a www.tcl.tk lapon.

Elmélyült beszélgetés folyt a Slashdot-on két stanford-i kutatóról, név szerint Díawson Engler-ről és Yichen Xie-ről, akik egy tanulmányt írtak (pdf) a programforrásokban található redundáns (többszörözött) kódokról, halott kódokról, stb. amelyek kernel hibákról (és lehetséges biztonsági lyukakról?) árulkodhatnak. Akit mélyebben érdekel a biztonságos programozás, a hibák a Linux és más operációs rendszerek magjában, annak hasznos olvasmány lehet.

A "Stanford Checker" (ismert még "MC" néven is) egy olyan project, amelyet egy stanfordi professzor, egy bizonyos Dawson Engler indított; és amelyik egy módosított verziójú gcc fordítót használ arra, hogy potenciális programozási hibákat keressen a C forráskódokban. A Stanford Checker csapat néhányszor postázott már a linux listára (LKML) olyan hibajelentéseket, amelyet az MC készített a linux kernel kódjáról. A legutolsó ilyen jelentés január 2-án látott napvilágot, és számos puffer túlcsordulási hibát fedezett fel a linux kernelben.

A Checker által készített lista elismerést váltott ki a kernel hackerekből, és azóta számos más igazi bugot is ki tudtak szűrni a kódból. Szerencsés lenne, ha a Checker bárki számára elérhető lenne, de sajnos egyelőre ez nincs így. Az MC csapat azt állítja, hogy még nincs kész, és ezért nem adják ki (egyelőre). A kernel fejlesztők jelenleg nem tudnak mit csinálni, mint hogy várnak a következő jelentésre.Dan Carpenter viszont nem volt elég türelmes, mert nekiállt elkészíteni a saját MC-szerű rendszerét. Az eredmény a Smatch lett, amelyet be is jelentett a kernel janitor-ok listáján január 1-én. A Smatch megpróbálja utánozni a Stanford Checker működését, és ezt azoknak a dokumentációknak alapján teszi, amit a MC csapat kiadott. Még elég sok munka van rajta; ahelyett hogy szép jelentést készítene, egy nagy mennyiségű nyers adatot ad vissza, amit perl szkriptekkel kell szűrni. A szkriptek induló verziója már elérhető, de még van mit javítani rajta.

Szóval a Smatch valószínűleg nem fogja kiütni a Stanford Checker-t a pozíciójából egyhamar. De ad egy szabad fejlesztői felületet egy szabadon elérhető ellenőrző eszköz kifejlesztéséhez, amely hasonló képeséégekkel rendelkezik. Kis szerencsével, és némi fejlesztési idő után a Smatch segítségére lehet a kernel fejlesztőknek.

A tanult szakmám rendszerprogramozó. Annak idején mikor a programozás alapjait tanultam, a Pascal ismeretek körül volt egy olyan általános nézet, hogy struktúrált programozás a mai divat, mindent eljárásokkal (függvényekkel) kell megoldani, és ami nagy ívben kerülendő a kódban a "goto" "break" "continue" átkozott hármas.

Edsger W. Dijkstra 1968-ban írt egy "Go To Statement Considered Harmful" című írást ez ügyben. Sokak szerint a "goto" alkalmazása "spagetti" kódot eredményez. A másik ismert személyiség aki ezt a nézetet vallja Niklaus Wirth, aki a Pascal nyelvet fejlesztette. Linus Torvalds szerint ez nem így van. Szerinte a "goto" nem ártalmas. A "goto" kérdés minden éven visszatér az LKML-en, és minden alkalommal flamet vált ki. Most Rob Wilkens kérdezte Linus-t, hogy miért kódol "goto" utasításokat a Linux forrásába? Példa:

Scott Ladd frissítette a GNU GCC és az Intel CC összehasonlító oldalát, amelyen most már a GCC 3.2.1-es, míg az Intel C++ 7.0-ás verziójával, Pentium4-es processzoron futtatott tesztek is elérhetők.

Kapcsolódó oldalak:

Benchmarking Intel C++ to GNU g++

GCC vs. ICC

A norvég Trolltech cég kiadta a Qt legújabb verzióját a 3.1-et. A QT egy multi-platform C++ GUI (Graphical User Interface) fejlesztő eszköz.

Talán még sokan keresnek egy hatásos IDE-t világmegváltó szoftverjeik kifejlesztéséhez. Örömmel tudathatjuk, hogy közép-európai idő szerint ma hajnalban megjelent a már jól ismert Anjuta DevStudio fejlesztő környezet 1-es stabil verziója. Az Anjuta .1.9-es verziója, II. 14.-n jelent meg, úgyhogy ez került a WOODY-ba. A végleges stabil 1-es kiadásnak augusztusban készült el a bétája, úgyhogy a beportolás nagy esemény lesz, főleg, mivelhogy a nagy rivális DevC++ még sehol sincsen:Az Anjuta - (nevezhetjük anyukának is) - egy GNOME-os progi, elvileg már támogatja a GNOME 2-s dolgokat, úgyhogy, ha már jól bejárattuk a GNOME 2-t és tetszik, akkor biztos be fog jönni. Ezen felül rendkívül komoly i18n supporttal rendelkezik, bár mi magyarok ebben is le vagyunk maradva, úgyhogy akár az ovisok is könnyen írhatnak GCC progikat. Ezeknél azonban sokkal komolyabb new-kat is tartalmaz. Pl.: rendkívül fejlett verzió-követést, Mime-handling-et, a debuggerhez ghex jellegű hex, advanced Find cuccok, sok hover feature...

Miért XBASE adatbázis kezelést használ és nem client-server technikát? Kérdezik sokan.A LafiSoft 1990 decemberében alakult. A 12 év munka, és tapasztalat határozta meg a jelenlegi fejlesztési stratégiát.

A válasz egy sereg paraméter összhangjából születik. Ezek az ügyviteli programok általában szóló üzemben, vagy helyi hálózatokon futnak. Ezek a legrosszabb esetben produkálnak 10Mbit/sec sebességet. A szóló gépek esetén ez a belső adatátviteli sebesség még nagyobb. Így nem okoz gondot a nagytömegű adatáramlás ami a clipper-xbase programokra jellemző. Főleg ha gondoskodunk róla, hogy az exe kódja se közlekedjen a kábeleken, azaz minden terminálon a helyi HDD-n tároljuk, onnan indítjuk.

A client-server alkalmazások ésszerű felhasználási területe az internetes adatbázis kezelés és a nagyvállalati rendszerek. Előnye, hogy a program csoportos fejlesztő munkával állítható elő, kódja tömör világos áttekinthető, jól ellenőrizhető. Az vizuális fejlesztői támogatás kimagasló, a program előállítási költsége így alacsony.

Hátránya mint minden túl intelligens rendszernek, hogy bár egységes egyenletes teljesítményt ad és nem lehet paramétereit kihegyezni az egyedi elvárások szerinti legjobb optimumra hangolni. Rákényszeríti a programozót helyenként nyakatekert és sematikus megoldások alkalmazására, aminek az ára sebesség és kezelhetőség romlásában jelentkezik. Rákényszerít a felhasználóra egy megosztott programrendszert aminek optimalizálása nem feltétlenül fedi le a felhasználó igényét.

Kettősségből (Kliens -server oldal) eredően sérülékenysége nagy. Feléphet az 'Ágyúval - verébre ' szindróma.

Mi az előnye egy jól megirt KYLIX-XBASE programnak? A program működése stabil, sebessége az index szekvenciális rendszernek köszönhetően maximális. Kylix grafikus eszközeivel kiegészítve változatos, a program használójának igényéhez maximálisan igazodó ablakrendszereket lehet készíteni. A generált gépi programkód futási sebessége maximális. Nem egy SQL értelemző fut ami interpreter jellegéből adódóan lassú. Primitív alacsony programozási szintből eredően speciális feladok is jól megoldhatóak vele nagy futási sebességgel.

Mi a hátránya? A forráskód relatíve nagy tömegű, a programozás csoportos munkavégzése nehezen kivitelezhető, ezért szeretik a magányos farkasok. Nagyságrenddel több programozói órát kell beleölni, tesztelési fázis költséges és hosszan elnyúlik, mire a hibák száma az elfogadható szint alá nem süllyed.

Összegezve, ne temessük még el az XBASE programokat.

Kétségtelenül a jővő a client-server alkalmazásoké, de a kisméretű ügyviteli alkalmazások esetén, használhatóságuk még nem érik el a jól megirt xbase társaikét. - egyenlőre.

Kiss Zoltán LafiSoft

http://www.lafisoft.hu

6400 Kiskunhalas Kassa u 24

tel: 06-77-425-262 ICQ 2510307

A népszerű compiler collection frissítve lett a 3.1.1 verzióra. A GCC 3.1.1 bugfix kiadás, úgy funkciók nem találhatóak benne.

Mark Mitchell (Release Manager) szerint a GCC 3.2 "hamarosan elérhető lesz (néhány napon vagy héten belül). Az egyedüli változás a GCC 3.2-ben a 3.1.1-hez képest a C++ ABI körül lesz."Nagyobb fixeket tartalmaz ez a kiadás.

Az UPX ( the Ultimate Packer for eXecutables) egy olyan program, amellyel binárisokat lehet tömöríteni úgy, hogy azok indíthatók maradnak.Támogatott formátumok:

* atari/tos

* djgpp2/coff

* dos/com

* dos/exe

* dos/sys

* linux/386

* rtm32/pe

* tmt/adam

* watcom/le (supporting DOS4G, PMODE/W, DOS32a and CauseWay)

* win32/pe

Changes in 1.21 (01 Jun 2002)

* New option "--crp-ms=" for slightly better compression at the cost of higher memory requirements during compression. Try "upx --best --crp-ms=100000". See the docs for more info.

* portability fixes

* compile fixes for g++ 3.0 and g++ 3.1