Error Checking, Utilities, Libraries menjelaskan bagaimana penanganan error checking, menjelaskan untilties dan contoh-contohnya, serta menjelakan beberapa tipe dari libraries.
ERROR CHECKING
Salah satu perbedaan utama antara pemrograman sistem dan pemrograman aplikasi adalah bahwa pemeriksaan kesalahan bukanlah sesuatu yang baik untuk dimiliki tetapi sangat penting sehingga seseorang tidak dapat hidup tanpanya. Sangat umum, Anda dapat melihat orang melakukan “printf” untuk mengeluarkan pesan kesalahan ke konsol. Meskipun lebih baik daripada tidak melakukan pemeriksaan kesalahan, ini tidak cukup bahkan ketika tidak melakukan pemrograman sistem.
CATATAN:
KAMI AKAN MENDASARKAN CONTOH KAMI DI SINI PADA BAHASA PEMROGRAMAN C
Ketika setiap program berjalan dan menjadi sebuah proses, ada tiga file yang dibuka untuknya secara default, stdin, stdout dan stderr. Dua yang pertama jelas adalah konsol input dan output dan yang ketiga, stderr, adalah tempat tujuan pesan kesalahan. stdin dan stdout dapat dialihkan, sedangkan stderr tidak bisa. Oleh karena itu, pesan kesalahan adalah keluaran terbaik menggunakan:
fprintf(stderr,”your error message”);
Anda juga harus tahu bahwa printf dan fprintf(stdout,”…”) melakukan tugas yang sama.
Selain menggunakan fprintf, ada dua alat penting lainnya untuk digunakan dalam pengecekan error: perror dan assert, keduanya adalah standar ANSI C dan tersedia di semua sistem operasi yang mengklaim mendukung ANSI C’1987.
PERROR
Saat komputer dihidupkan, program yang dijalankan pertama kali disebut “ sistem operasi.” Ia mengontrol hampir semua aktivitas di komputer. Ini termasuk siapa yang masuk, bagaimana disk digunakan, bagaimana memori digunakan, bagaimana CPU digunakan, dan bagaimana Anda berbicara dengan komputer lain. Dalam diskusi berikut, contoh Sistem Operasi studi kami adalah “Unix”.
Cara program berbicara dengan sistem operasi adalah melalui “system calls“. System calls terlihat seperti procedure call (lihat di bawah), tetapi berbeda — ini adalah permintaan ke sistem operasi untuk melakukan beberapa aktivitas.
System calls itu mahal. Sementara procedure call biasanya dapat dilakukan dalam beberapa instruksi mesin, system calls memerlukan komputer untuk menyimpan statusnya, membiarkan sistem operasi mengendalikan CPU, meminta sistem operasi melakukan beberapa fungsi, meminta sistem operasi menyimpan statusnya , dan kemudian minta sistem operasi memberikan kontrol CPU kembali kepada Anda.
Biasanya ketika kesalahan terjadi dalam system calls atau libraries, nilai pengembalian khusus kembali, dan variabel global “errno” diatur untuk mengatakan apa kesalahannya. Misalnya, Anda mencoba membuka file yang tidak ada:
ch1a.c mencoba membuka file ~huangj/nonexist untuk dibaca. File itu tidak ada. Jadi, fopen mengembalikan NULL (baca halaman manual untuk fopen), dan menyetel errno untuk menandai kesalahan. Saat Anda menjalankan program, Anda akan melihat bahwa errno disetel ke 2. Untuk mengetahui artinya, Anda dapat melakukan salah satu dari dua hal berikut:
- Cari nilai errno di /usr/include/errno.h ( Anda harus melihat /usr/include/sys/errono.h pada UNIX flavor machines karena pada jenis sistem tersebut, standar C errno.h memang memiliki “#include < sys/errno.h >” di dalamnya.). Anda akan melihat baris:
- #define ENOENT 2 /* No such file or directory */
- 2. Gunakan prosedur “perror()” — sekali lagi, baca halaman manual. Itu mencetak apa artinya errno. Jadi, keluaran dari f1 adalah
- f = null. errno = 2
- f1: No such file or directory
Ini adalah antarmuka standar untuk kesalahan.
ASSERT
Sering kali, ada kebutuhan untuk membuat asumsi saat menulis kode. Semua orang melakukannya. Tapi bagaimana jika anggapan itu salah? Apakah ada cara yang baik untuk memeriksanya? Jawabannya adalah dengan menggunakan assert.
Penggunaan paling umum dari assert (kemungkinan besar diimplementasikan sebagai makro pada sebagian besar sistem operasi yang dapat Anda temukan) adalah untuk mengidentifikasi kesalahan program selama pengembangan. Argumen yang diberikan kepada assert harus dipilih sehingga berlaku hanya jika program beroperasi sebagaimana dimaksud. Makro mengevaluasi argumen assert dan, jika ekspresi argumen false (0), memperingatkan pengguna dan menghentikan eksekusi program. Tidak ada tindakan yang diambil jika argumen true (nonzero).
Saat pernyataan gagal, pesan keluaran dengan teks berikut akan dibuat:
assertion failed in file name in line num
di mana name adalah nama file sumber dan num adalah nomor baris dari pernyataan yang gagal.
Penggunaan assertions secara bebas di seluruh program Anda dapat menangkap kesalahan selama pengembangan. Aturan praktis yang baik adalah Anda harus menulis assertions untuk setiap asumsi yang Anda buat. Misalnya, jika Anda berasumsi bahwa argumen not NULL, gunakan assertions untuk memeriksa kondisi tersebut.
Di sini kami memeriksa bahwa beberapa asumsi yang kami buat untuk strcpy benar. Setelah kami yakin tidak ada kesalahan dalam perangkat lunak, kami dapat dengan mudah menonaktifkan semua pemeriksaan assertion dengan menambahkan “#define NDEBUG” sebelum “#include < assert.h >” muncul di kode sumber.
LIBRARY IN COMPUTING
Dalam ilmu komputer, Library adalah kumpulan subrutin atau kelas yang digunakan untuk mengembangkan perangkat lunak. Libraries berisi kode dan data yang menyediakan layanan untuk program independen. Ini memungkinkan kode dan data untuk dibagikan dan diubah secara modular. Beberapa file yang dapat dieksekusi adalah program dan libraries yang berdiri sendiri, tetapi sebagian besar libraries tidak dapat dieksekusi. Executable dan libraries membuat referensi yang dikenal sebagai link satu sama lain melalui proses yang dikenal sebagai linking, yang biasanya dilakukan oleh linker.
Sebagian besar sistem operasi (OS) modern menyediakan libraries yang mengimplementasikan sebagian besar layanan sistem. Libraries semacam itu telah mengkomoditisasi layanan yang diharapkan oleh aplikasi modern dari OS. Dengan demikian, sebagian besar kode yang digunakan oleh aplikasi modern disediakan di libraries ini.
TYPES OF LIBRARIES
STATIC LIBRARIES
Secara historis, libraries hanya bisa statis. Static library, juga dikenal sebagai arsip, terdiri dari serangkaian rutin yang disalin ke aplikasi target oleh compiler, linker, atau binder, menghasilkan file objek dan file yang dapat dieksekusi yang berdiri sendiri. Proses ini, dan file yang dapat dieksekusi yang berdiri sendiri, dikenal sebagai static build dari aplikasi target.
Linker menyelesaikan semua alamat yang belum terselesaikan menjadi alamat tetap atau yang dapat dipindahkan (dari basis umum) dengan memuat semua kode dan libraries ke lokasi memori runtime yang sebenarnya.
Linker dapat bekerja pada jenis file objek tertentu, dan karenanya memerlukan jenis libraries yang spesifik (kompatibel). Proses linking menyelesaikan referensi dengan mencari libraries dalam urutan yang diberikan. Biasanya, ini tidak dianggap sebagai kesalahan jika sebuah nama dapat ditemukan beberapa kali dalam sekumpulan libraries tertentu.
DYNAMIC LINKING
Dynamic linking berarti bahwa subrutin libraries dimuat ke dalam program aplikasi saat runtime, bukannya ditautkan pada waktu kompilasi, dan tetap sebagai file terpisah pada disk. Hanya sedikit pekerjaan yang dilakukan pada waktu kompilasi oleh linker; itu hanya mencatat rutinitas library apa yang dibutuhkan program dan nama atau nomor indeks dari rutinitas di library. Sebagian besar pekerjaan linking dilakukan pada saat aplikasi dimuat (load time) atau selama eksekusi (runtime). Linking code yang diperlukan, yang disebut loader, sebenarnya adalah bagian dari sistem operasi yang mendasarinya. Pada saat yang tepat loader menemukan libraries yang relevan pada disk dan menambahkan data yang relevan dari libraries ke ruang memori proses.
Beberapa sistem operasi hanya dapat menautkan di library pada waktu muat, sebelum proses mulai dijalankan; yang lain mungkin dapat menunggu hingga setelah proses mulai dieksekusi dan ditautkan di library tepat ketika itu benar-benar direferensikan (yaitu, selama runtime). Yang terakhir sering disebut “delay loading” atau “deferred loading“. Dalam kedua kasus tersebut, library semacam itu disebut dynamically linked library.
RELOCATION
Satu masalah yang harus ditangani oleh loader adalah bahwa lokasi sebenarnya dalam memori dari data library (pustaka) tidak dapat diketahui sampai setelah semua pustaka yang dapat dieksekusi dan yang terhubung secara dinamis telah dimuat ke dalam memori. Ini karena lokasi memori yang digunakan bergantung pada pustaka dinamis tertentu yang telah dimuat. Tidak mungkin untuk bergantung pada lokasi absolut dari data di executable, atau bahkan di library, karena konflik antara libraries yang berbeda akan terjadi: jika dua di antaranya menentukan alamat yang sama atau tumpang tindih, tidak mungkin menggunakan keduanya di program yang sama.
Namun, dalam praktiknya, shared libraries (pustaka bersama) di sebagian besar sistem tidak sering berubah. Oleh karena itu, dimungkinkan untuk menghitung kemungkinan alamat pemuatan untuk setiap pustaka bersama di sistem sebelum diperlukan, dan menyimpan informasi tersebut di pustaka dan yang dapat dieksekusi. Jika setiap pustaka bersama yang dimuat telah mengalami proses ini, maka masing-masing akan memuat di alamat yang telah ditentukan sebelumnya, yang mempercepat proses penautan dinamis. Optimalisasi ini dikenal sebagai pre-binding di Mac OS X dan pre-linking di Linux. Kerugian dari teknik ini termasuk waktu yang dibutuhkan untuk precompute alamat ini setiap kali shared libraries berubah, ketidakmampuan untuk menggunakan pengacakan tata letak ruang alamat, dan persyaratan ruang alamat virtual yang cukup untuk digunakan (masalah yang akan diatasi dengan adopsi 64-bit arsitektur, setidaknya untuk saat ini).
LOCATING LIBRARIES AT RUNTIME
Dynamic linkers/loaders sangat bervariasi dalam fungsinya. Beberapa bergantung pada jalur eksplisit ke libraries yang disimpan di executable. Setiap perubahan pada penamaan library atau tata letak sistem file akan menyebabkan sistem ini gagal. Lebih umum, hanya nama perpustakaan (dan bukan jalurnya) yang disimpan dalam file yang dapat dieksekusi, dengan sistem operasi menyediakan sistem untuk menemukan perpustakaan di disk berdasarkan beberapa algoritme.
Salah satu kelemahan terbesar dari dynamic linking adalah bahwa executable bergantung pada perpustakaan yang disimpan secara terpisah agar dapat berfungsi dengan baik. Jika pustaka dihapus, dipindahkan, atau diganti namanya, atau jika versi DLL yang tidak kompatibel disalin ke tempat yang lebih awal dalam pencarian, file yang dapat dieksekusi akan gagal dimuat. Di Windows ini umumnya dikenal sebagai DLL hell.
Unix-like systems
Sebagian besar sistem Unix-like memiliki “search path” yang menentukan direktori sistem file untuk mencari dynamic libraries. Pada beberapa sistem, jalur default ditentukan dalam file konfigurasi; di tempat lain, sulit dikodekan ke dalam dynamic loader. Beberapa format file yang dapat dieksekusi dapat menentukan direktori tambahan untuk mencari libraries untuk program tertentu.
Microsoft Windows
Microsoft Windows akan memeriksa registri untuk menentukan tempat yang tepat untuk menemukan ActiveX DLL, tetapi untuk DLL lainnya akan memeriksa direktori tempat program dimuat; direktori kerja saat ini; setiap direktori yang diatur dengan memanggil fungsi SetDllDirectory();
AmigaOS
Di bawah libraries sistem umum AmigaOS disimpan dalam direktori yang ditentukan oleh LIBS: path assignment dan application-specific libraries dapat disimpan dalam direktori yang sama dengan aplikasi yang dapat dieksekusi. AmigaOS akan mencari lokasi ini saat executable mencoba meluncurkan shared library. Aplikasi juga dapat menyediakan jalur eksplisit saat mencoba meluncurkan library.
SHARED LIBRARIES
Selain dimuat secara statis atau dinamis, pustaka juga sering diklasifikasikan menurut cara pembagiannya di antara program. Dynamic libraries hampir selalu menawarkan beberapa bentuk berbagi, memungkinkan pustaka yang sama digunakan oleh banyak program pada waktu yang sama. Static libraries, menurut definisi, tidak dapat dibagikan. Istilah “linker” berasal dari proses penyalinan prosedur atau subrutin yang mungkin berasal dari pustaka yang “”relocatable” dan menyesuaikan atau “linking” alamat mesin ke lokasi akhir setiap modul.
Istilah shared library agak ambigu, karena mencakup setidaknya dua konsep yang berbeda. Pertama, ini adalah pembagian kode yang terletak di disk oleh program yang tidak terkait. Konsep kedua adalah berbagi kode dalam memori, ketika program mengeksekusi halaman fisik RAM yang sama, dipetakan ke dalam ruang alamat yang berbeda. Tampaknya yang terakhir lebih disukai, dan memang memiliki sejumlah keunggulan. Misalnya pada sistem OpenStep, aplikasi seringkali hanya berukuran beberapa ratus kilobyte dan dimuat hampir secara instan; sebagian besar kode mereka terletak di libraries yang telah dimuat untuk tujuan lain oleh sistem operasi. Namun, ada biaya; kode bersama harus ditulis secara khusus untuk dijalankan di lingkungan multitasking.
Di sebagian besar sistem operasi modern, shared libraries dapat memiliki format yang sama dengan file executable “biasa”. Hal ini memungkinkan dua keuntungan utama: pertama, hanya perlu membuat satu loader untuk keduanya, bukan dua (memiliki satu loader dianggap sepadan dengan kompleksitas tambahannya). Kedua, memungkinkan executable juga untuk digunakan sebagai DLL, jika mereka memiliki tabel simbol.
Istilah DLL banyak digunakan pada produk Windows dan OS/2. Pada platform mirip Unix dan Unix, istilah shared library atau shared object lebih umum digunakan; akibatnya, ekstensi nama file yang paling umum untuk file pustaka bersama adalah .so, biasanya diikuti dengan titik lain dan nomor versi. Ini secara teknis dibenarkan mengingat semantik yang berbeda.
DYNAMIC LOADING
Dynamic loading adalah bagian dari dynamic linking di mana pustaka yang ditautkan secara dinamis di load dan unload pada saat run-time berdasarkan permintaan. Permintaan semacam itu dapat dibuat secara implisit pada waktu kompilasi atau secara eksplisit pada waktu proses. Permintaan implisit dibuat pada waktu kompilasi ketika linker menambahkan referensi pustaka yang menyertakan jalur file atau sekadar nama file. Permintaan eksplisit dibuat saat aplikasi melakukan panggilan langsung ke API sistem operasi saat runtime.
Sebagian besar sistem operasi yang mendukung pustaka yang ditautkan secara dinamis juga mendukung pemuatan pustaka tersebut secara dinamis melalui run-time linker API. Misalnya, Microsoft Windows menggunakan fungsi API LoadLibrary, LoadLibraryEx, FreeLibrary dan GetProcAddress dengan Microsoft Dynamic Link Libraries; Sistem berbasis POSIX, termasuk sebagian besar sistem UNIX-like dan UNIX, menggunakan dlopen, dlclose, dan dlsym. Beberapa sistem pengembangan mengotomatiskan proses ini.
REMOTE LIBRARIES
Solusi lain untuk masalah library adalah dengan menggunakan executable yang benar-benar terpisah (seringkali dalam bentuk yang ringan) dan memanggilnya menggunakan remote procedure call (RPC) melalui jaringan ke komputer lain. Pendekatan ini memaksimalkan re-use sistem operasi: kode yang diperlukan untuk mendukung library adalah kode yang sama yang digunakan untuk menyediakan dukungan dan keamanan aplikasi untuk setiap program lainnya. Selain itu, sistem seperti itu tidak memerlukan library untuk ada di mesin yang sama, tetapi dapat meneruskan permintaan melalui jaringan.
Kelemahan dari pendekatan semacam itu adalah bahwa setiap library call membutuhkan biaya overhead yang cukup besar. Panggilan RPC jauh lebih mahal daripada memanggil shared library yang telah dimuat di mesin yang sama.
OBJECT LIBRARIES
Meskipun dynamic linking awalnya dikembangkan pada 1960-an, itu tidak mencapai sistem operasi konsumen hingga akhir 1980-an; itu umumnya tersedia dalam beberapa bentuk di sebagian besar sistem operasi pada awal 1990-an. Selama periode yang sama inilah pemrograman berorientasi objek (OOP) menjadi bagian penting dari lanskap pemrograman. OOP dengan runtime binding memerlukan informasi tambahan yang tidak disediakan oleh traditional libraries; selain nama dan titik masuk kode yang terletak di dalamnya, mereka juga memerlukan daftar objek tempat mereka bergantung. Ini adalah efek samping dari salah satu keunggulan utama OOP, inheritance (pewarisan), yang berarti bahwa definisi lengkap dari setiap metode dapat didefinisikan di sejumlah tempat. Ini lebih dari sekadar mencantumkan bahwa satu perpustakaan memerlukan layanan perpustakaan lainnya; dalam sistem OOP yang sebenarnya, pustaka itu sendiri mungkin tidak diketahui pada waktu kompilasi, dan bervariasi dari satu sistem ke sistem lainnya.
Tidak lama kemudian mayoritas vendor komputer mini dan mainframe mengerjakan proyek untuk menggabungkan keduanya, menghasilkan format pustaka OOP yang dapat digunakan di mana saja. Sistem seperti itu dikenal sebagai object libraries, atau distributed objects jika mereka mendukung akses jarak jauh (tidak semuanya). Microsoft’s COM adalah contoh sistem seperti itu untuk penggunaan lokal, DCOM adalah versi modifikasi yang mendukung akses jarak jauh.