Apa itu bahasa pemrograman yang aman?


54

Bahasa pemrograman aman (PL) semakin populer. Saya ingin tahu apa definisi formal PL yang aman. Misalnya, C tidak aman, tetapi Java aman. Saya menduga bahwa properti "aman" harus diterapkan untuk implementasi PL daripada PL itu sendiri. Jika demikian, mari kita bahas definisi implementasi PL yang aman. Upaya saya sendiri untuk memformalkan gagasan ini menghasilkan hasil yang aneh, jadi saya ingin mendengar pendapat lain. Tolong, jangan katakan bahwa setiap PL memiliki perintah yang tidak aman. Kami selalu dapat mengambil bagian yang aman.


Komentar bukan untuk diskusi panjang; percakapan ini telah dipindahkan ke obrolan .
Gilles 'SANGAT berhenti menjadi jahat'

"Kami selalu dapat mengambil bagian yang aman" Bagaimana Anda bisa yakin bahwa bahasa yang dihasilkan masih Turing-lengkap? (yang biasanya dimaksud dengan "bahasa pemrograman")
effeffe

"properti" aman "harus diterapkan pada implementasi PL daripada ke PL itu sendiri" - Anda dapat memanggil PL aman jika ada implementasi yang aman.
Dmitry Grigoryev

Jawaban:


17

Ketika kita menyebut bahasa "aman" dalam beberapa hal , itu secara resmi berarti bahwa ada bukti bahwa tidak ada program yang baik dalam bahasa yang dapat melakukan sesuatu yang kita anggap berbahaya. Kata "aman" juga digunakan secara kurang formal, tapi itulah yang orang di sini pahami maksud pertanyaan Anda. Ada banyak definisi properti yang berbeda yang kami inginkan memiliki bahasa "aman".

Beberapa yang penting adalah:

  • Definisi Andrew Wright dan Matthias Felleisen tentang "kesehatan jenis" , yang dikutip di banyak tempat (termasuk Wikipedia) sebagai definisi yang diterima tentang "keamanan jenis," dan bukti 1994 mereka bahwa subset dari ML memenuhi itu.

  • Michael Hicks mendaftar beberapa definisi "keamanan memori" di sini . Beberapa adalah daftar jenis kesalahan yang tidak dapat terjadi, dan beberapa didasarkan pada memperlakukan pointer sebagai kemampuan. Java menjamin bahwa tidak ada kesalahan tersebut yang dimungkinkan (kecuali jika Anda secara eksplisit menggunakan fitur bertanda unsafe) dengan meminta seorang pengumpul sampah mengelola semua alokasi dan deallokasi. Rust membuat jaminan yang sama (sekali lagi, kecuali jika Anda secara eksplisit menandai kode sebagai unsafe), melalui sistem tipe affine-nya, yang membutuhkan variabel untuk dimiliki atau dipinjam sebelum digunakan paling banyak sekali.

  • Demikian pula, kode aman thread biasanya didefinisikan sebagai kode yang tidak dapat menunjukkan jenis bug tertentu yang melibatkan utas dan memori bersama, termasuk ras data dan kebuntuan. Properti ini sering diberlakukan pada tingkat bahasa: Rust menjamin bahwa balapan data tidak dapat terjadi dalam sistem tipenya, C ++ menjamin bahwa std::shared_ptrsmart pointernya ke objek yang sama di banyak utas tidak akan menghapus objek sebelum waktunya atau gagal menghapusnya ketika referensi terakhir untuk itu dihancurkan, C dan C ++ juga memiliki atomicvariabel dibangun ke dalam bahasa, dengan operasi atom dijamin untuk menegakkan beberapa jenis memori-konsistensi jika digunakan dengan benar. MPI membatasi komunikasi antarproses ke pesan eksplisit, dan OpenMP memiliki sintaks untuk memastikan bahwa akses ke variabel dari utas yang berbeda aman.

  • Properti yang memori tidak akan pernah bocor sering disebut safe-for-space. Pengumpulan sampah otomatis adalah fitur satu bahasa untuk memastikan hal ini.

  • Banyak bahasa memiliki jaminan bahwa operasinya akan memiliki hasil yang jelas dan program-programnya akan berperilaku baik. Sebagai supercat memberikan contoh di atas, C melakukan ini untuk aritmatika yang tidak ditandatangani (dijamin untuk membungkus dengan aman) tetapi tidak menandatangani aritmatika (di mana overflow diizinkan untuk menyebabkan bug yang sewenang-wenang, karena C perlu mendukung CPU yang melakukan hal-hal yang sangat berbeda ketika menandatangani aritmatika meluap), tetapi kemudian bahasa terkadang secara diam-diam mengubah jumlah yang tidak ditandatangani menjadi yang ditandatangani.

  • Bahasa fungsional memiliki banyak invarian yang dijamin dapat dipertahankan oleh setiap program yang dibentuk dengan baik, misalnya, fungsi murni tidak dapat menyebabkan efek samping. Ini mungkin atau mungkin tidak digambarkan sebagai "aman."

  • Beberapa bahasa, seperti SPARK atau OCaml, dirancang untuk memfasilitasi pembuktian kebenaran program. Ini mungkin atau mungkin tidak digambarkan sebagai "aman" dari bug.

  • Bukti bahwa suatu sistem tidak dapat melanggar model keamanan formal (oleh karena itu menyindir, "Setiap sistem yang terbukti aman mungkin tidak.")


1
Ini mungkin atau mungkin tidak digambarkan sebagai "aman" dari bug. Bisakah Anda menjelaskan sedikit ini? Apa yang Anda maksud dengan "dari bug"?
scaaahu

2
@scaaahu Berikut adalah contoh situs web yang merujuk ke perangkat lunak yang secara formal terbukti benar sebagai “terbukti aman.” Dalam konteks ini, ini merujuk pada perangkat lunak untuk mencegah pesawat bertabrakan, sehingga itu berarti aman dari benturan.
Davislor

1
Saya menerima jawaban ini karena mencantumkan jenis keamanan. Jenis yang saya pikirkan adalah keamanan memori.
beroal

Sementara jawaban ini mencantumkan beberapa tautan bermanfaat dan banyak contoh, kebanyakan dari mereka benar-benar kacau. Pengumpulan sampah memastikan bahwa memori tidak akan pernah bocor atau tidak menggunakan blok "tidak aman" secara otomatis memberi Anda keselamatan atau limpahan yang ditandatangani sebagai Perilaku Tidak Terdefinisi karena С kompiler perlu mendukung beberapa CPU aneh, serius? Dan hanya sebuah kata singkat untuk Ada / SPARK yang merupakan satu-satunya dari bahasa yang disebutkan yang menganggap serius keselamatan.
VTT

93

Tidak ada definisi formal "bahasa pemrograman yang aman"; itu gagasan informal. Sebaliknya, bahasa yang mengklaim memberikan keamanan biasanya memberikan pernyataan formal yang tepat tentang jenis keamanan apa yang diklaim / dijamin / disediakan. Misalnya, bahasa dapat memberikan keamanan jenis, keamanan memori, atau jaminan serupa lainnya.


13
Sebagai addeumdum, jika kita berbicara tentang C vs Java seperti posting OP: itu adalah keamanan memori yang dijamin di Jawa dan bukan dalam C. Jenis keamanan disediakan oleh keduanya dengan cara mereka sendiri. (Ya banyak orang yang membaca ini sudah tahu itu, tetapi mungkin beberapa tidak).
Walfrat

17
@ Walfrat Itu bagian dari itu. Java juga tidak memiliki perilaku yang tidak terdefinisi, yang merupakan sesuatu yang kita harapkan dari bahasa yang menyebut dirinya 'aman'. Adapun sistem tipe, saya tidak berpikir sistem tipe statis yang kuat adalah apa yang orang cenderung maksud dengan 'aman'. Bahasa yang diketik secara dinamis seperti Python pada umumnya 'aman'.
Max Barraclough

2
Definisi saya tentang keamanan jenis adalah pemeriksaan kompilasi yang mengatasinya. Itu mungkin bukan definisi formal. Perhatikan bahwa saya mengatakan "ketik keamanan", bukan "aman". Bagi saya "aman" merujuk pada "definisi saya" jenis dan keamanan memori "dan saya pikir itu mungkin yang paling luas. Tentu saja saya tidak berbicara tentang beberapa jebakan seperti refleksi / batal di C kompilasi yang tidak dapat menangani. Definisi lain yang mungkin dari safe adalah program yang tidak crash dengan kesalahan segmen seperti pointer unitialized di C. Hal-hal seperti itu umumnya diberikan dalam Python dan Java.
Walfrat

7
@ Walfrat Semua yang membuat Anda meskipun adalah bahasa di mana sintaks didefinisikan dengan baik. Itu tidak menjamin bahwa eksekusi didefinisikan dengan baik - dan berapa kali saya melihat crash JRE, saya dapat mengatakan kepada Anda bahwa sebagai suatu sistem itu bukan "aman". Di C di sisi lain, MISRA telah berupaya menghindari perilaku yang tidak terdefinisi untuk mendapatkan bagian bahasa yang lebih aman, dan kompilasi C menjadi assembler jauh lebih baik. Jadi itu tergantung pada apa yang Anda anggap "aman".
Graham

5
@MaxBarraclough - "Java juga tidak memiliki perilaku yang tidak terdefinisi" - Java tidak memiliki perilaku yang tidak terdefinisi dalam arti yang digunakan dalam spesifikasi C dalam definisi bahasa (walaupun itu memungkinkan beberapa kode untuk menghasilkan nilai yang tidak memiliki nilai yang telah ditentukan sebelumnya, misalnya mengakses variabel yang sedang dimodifikasi di utas lain, atau dengan mengakses doubleatau longsementara itu sedang diubah di utas lain, yang tidak dijamin tidak menghasilkan setengah dari satu nilai yang dicampur dalam cara yang tidak ditentukan dengan setengah lainnya) tetapi spesifikasi API Namun memiliki perilaku yang tidak terdefinisi dalam beberapa kasus.
Jules

41

Jika Anda bisa mendapatkan salinan Jenis dan Bahasa Pemrograman Benjamin Pierce , dalam pengantar, ia memiliki tinjauan yang baik tentang berbagai perspektif tentang istilah "bahasa aman".

Salah satu interpretasi yang diusulkan dari istilah yang mungkin Anda temukan menarik adalah:

“Bahasa yang aman sepenuhnya ditentukan oleh manual pemrogramnya.” Biarkan definisi bahasa menjadi himpunan hal-hal yang perlu dipahami oleh programmer untuk memprediksi perilaku setiap program dalam bahasa tersebut. Maka manual untuk bahasa seperti C bukan merupakan definisi, karena perilaku beberapa program (misalnya, yang melibatkan akses array yang tidak dicentang atau aritmatika pointer) tidak dapat diprediksi tanpa mengetahui rincian tentang bagaimana kompiler C tertentu menjabarkan struktur dalam memori , dll., dan program yang sama mungkin memiliki perilaku yang sangat berbeda ketika dijalankan oleh kompiler yang berbeda.

Jadi, saya akan ragu untuk menggunakan istilah "tidak aman" untuk merujuk pada implementasi bahasa pemrograman. Jika istilah yang tidak didefinisikan dalam bahasa menghasilkan perilaku yang berbeda dalam implementasi yang berbeda, salah satu implementasi mungkin perilaku produk yang mungkin lebih diharapkan, tetapi saya tidak akan menyebutnya "aman".


7
Tentu saja Masalah Tersendat mengatakan bahwa apa pun bahasanya, akan selalu ada program yang perilakunya tidak dapat diprediksi dari definisi bahasa. Jadi setiap definisi yang bergantung pada "memprediksi perilaku setiap program dalam bahasa" pada dasarnya salah untuk bahasa Turing-lengkap.
MSalters

15
@MSalters Ini adalah kesalahpahaman populer tentang masalah penghentian. Ketidakpastian masalah penghentian menyiratkan bahwa tidak mungkin untuk secara mekanis menurunkan perilaku program sewenang-wenang dalam bahasa lengkap Turing. Tetapi ada kemungkinan bahwa untuk setiap program tertentu , perilaku tersebut dapat diprediksi. Hanya saja Anda tidak dapat membuat program komputer yang membuat prediksi ini.
Gilles 'SANGAT berhenti menjadi jahat'

7
@ Giles: Bukan itu masalahnya. Misalkan ada bukti non-terminasi untuk setiap program non-terminasi. Kemudian Anda dapat menyebutkan bukti non-terminasi untuk menemukan apakah suatu program dihentikan. Jadi masalah penghentian adalah decidable. Kontradiksi. Dengan demikian beberapa program non-terminasi tidak terbukti non-terminating.
Kevin

9
@Gilles: Saya sangat sadar akan fakta bahwa banyak program yang terbukti sepele atau tidak. Tetapi pernyataan di sini secara harfiah tentang perilaku setiap program. Bukti dari Teorema Henti menunjukkan bahwa ada setidaknya satu program yang tidak benar. Ini hanya bukti non-konstruktif, tidak akan memberi tahu Anda program mana yang tidak dapat ditentukan.
MSalters

8
@ MSalters Saya pikir sedikit tersirat adalah bahwa pernyataan itu adalah tentang perilaku skala kecil dari program, daripada skala besar, perilaku yang muncul. Sebagai contoh, ambil dugaan Collatz . Langkah-langkah individual dari algoritma tersebut sederhana dan didefinisikan dengan baik, tetapi perilaku yang muncul (berapa banyak iterasi sampai berhenti, dan jika itu benar-benar terjadi), sama sekali tidak. - "Prediksi" sedang digunakan secara informal di sini. Mungkin lebih baik ditulis sebagai "tahu bagaimana pernyataan yang diberikan dalam program arbitrer akan dieksekusi."
RM

18

Aman bukan biner, ini sebuah rangkaian .

Berbicara secara informal, keselamatan dimaksudkan oleh oposisi terhadap bug, 2 yang paling sering disebutkan adalah:

  • Keamanan Memori: bahasa dan implementasinya mencegah berbagai kesalahan terkait memori seperti penggunaan-setelah-bebas, bebas-ganda, akses di luar batas, ...
  • Jenis Keamanan: bahasa dan implementasinya mencegah berbagai jenis kesalahan terkait seperti gips dicentang, ...

Itu bukan satu - satunya kelas bug yang mencegah bahasa, kebebasan data-ras atau kebuntuan agak diinginkan, bukti kebenaran cukup manis, dll ...

Cukup program yang salah jarang dianggap "tidak aman" namun (hanya kereta), dan keamanan jangka umumnya dicadangkan untuk jaminan mempengaruhi kemampuan kita untuk alasan tentang program. Dengan demikian, C, C ++ atau Go, yang memiliki Perilaku Tidak Terdefinisi, tidak aman.

Dan tentu saja, ada bahasa dengan himpunan bagian yang tidak aman (Java, Rust, ...) yang dengan sengaja menggambarkan area di mana pengembang bertanggung jawab untuk menjaga jaminan bahasa dan kompiler berada dalam mode "lepas tangan". Bahasa-bahasa tersebut pada umumnya masih dijuluki aman , terlepas dari jalan keluarnya ini, sebuah definisi pragmatis.


7
Saya akan mengatakan itu adalah kisi.
PatJ

1
Sebagian besar implementasi bahasa pemrograman memiliki fitur yang tidak aman (misalnya Obj.magicdalam Ocaml). Dan dalam praktiknya, ini sangat diperlukan
Basile Starynkevitch

4
@ BasileStarynkevitch: Memang. Saya akan berpikir bahwa bahasa apa pun dengan FFI tentu mengandung beberapa tingkat yang tidak aman, karena memanggil fungsi C akan membutuhkan "pining" objek-objek GC dan secara manual memastikan bahwa tanda tangan di kedua sisi cocok.
Matthieu M.

15

Meskipun saya tidak setuju dengan jawaban DW, saya pikir itu membuat satu bagian dari "aman" tidak tertangani.

Seperti disebutkan, ada beberapa jenis keselamatan yang dipromosikan. Saya percaya itu baik untuk memahami mengapa ada banyak konsep. Setiap gagasan dikaitkan dengan gagasan bahwa program menderita terutama dari kelas bug tertentu, dan bahwa programmer tidak akan dapat membuat bug jenis khusus ini jika bahasa tersebut menghalangi programmer untuk melakukannya.

Perlu dicatat bahwa konsep-konsep yang berbeda ini karena itu memiliki kelas bug yang berbeda, dan kelas-kelas ini tidak saling eksklusif dan kelas-kelas ini tidak mencakup semua bentuk bug. Hanya untuk mengambil 2 contoh DW, pertanyaan apakah lokasi memori tertentu memegang objek tertentu adalah pertanyaan tentang keamanan jenis dan keamanan memori.

Kritik lebih lanjut terhadap "bahasa yang aman" mengikuti dari pengamatan bahwa pelarangan konstruksi tertentu yang dianggap berbahaya membuat programmer perlu membuat alternatif. Secara empiris, keamanan lebih baik dicapai oleh perpustakaan yang baik. menggunakan kode yang sudah teruji lapangan menyelamatkan Anda dari membuat bug baru.


10
Ini agak di luar topik untuk situs ini, karena rekayasa perangkat lunak sebenarnya bukan ilmu, tapi saya tidak setuju dengan pernyataan empiris Anda. Menggunakan perpustakaan yang baik tidak akan menyelamatkan Anda dalam bahasa yang tidak aman, karena Anda tidak terlindungi dari kesalahan menggunakannya. Bahasa yang aman memungkinkan Anda mendapatkan lebih banyak jaminan dari penulis perpustakaan dan memungkinkan Anda mendapatkan lebih banyak jaminan bahwa Anda menggunakannya dengan benar.
Gilles 'SO- berhenti bersikap jahat'

3
Saya dengan MSalters dalam hal ini. - "Bahasa yang aman memungkinkan Anda mendapatkan lebih banyak jaminan dari penulis perpustakaan dan memungkinkan Anda mendapatkan lebih banyak jaminan bahwa Anda menggunakannya dengan benar." Ini adalah non sequitur untuk semua tujuan praktis.
Kapten Giraffe

9

Perbedaan mendasar antara C dan Java adalah bahwa jika seseorang menghindari fitur Java yang mudah diidentifikasi (misalnya yang ada di Unsafenamespace), setiap tindakan yang mungkin dilakukan - termasuk yang "keliru" - akan memiliki sejumlah hasil yang terbatas. . Walaupun hal ini membatasi apa yang dapat dilakukan seseorang di Jawa - setidaknya tanpa menggunakan Unsafenamespace, itu juga memungkinkan untuk membatasi kerusakan yang dapat disebabkan oleh program yang salah, atau - yang lebih penting - oleh program yang akan memproses dengan benar file yang valid tetapi tidak secara khusus dilindungi terhadap yang salah.

Secara tradisional, kompiler C akan memproses banyak tindakan dengan cara yang ditentukan standar dalam kasus "normal", sementara memproses banyak kasus sudut "dengan cara yang karakteristik lingkungan". Jika seseorang menggunakan CPU yang akan memendek dan terbakar jika numerik meluap dan ingin menghindari CPU yang terbakar, orang perlu menulis kode untuk menghindari kelebihan numerik. Namun, jika seseorang menggunakan CPU yang dengan sempurna akan memotong nilai dengan cara dua-pelengkap, seseorang tidak harus menghindari kelebihan dalam kasus di mana pemotongan tersebut akan menghasilkan perilaku yang dapat diterima.

Modern C mengambil langkah-langkah lebih jauh: bahkan jika seseorang menargetkan platform yang secara alami akan mendefinisikan perilaku untuk sesuatu seperti pelimpahan numerik di mana Standar tidak akan memaksakan persyaratan, melimpah di satu bagian dari program dapat memengaruhi perilaku bagian lain dari Program dengan cara sewenang-wenang yang tidak terikat oleh hukum waktu dan kausalitas. Sebagai contoh, pertimbangkan sesuatu seperti:

 uint32_t test(uint16_t x)
 {
   if (x < 50000) foo(x);
   return x*x; // Note x will promote to "int" if that type is >16 bits.
 }

Kompiler C "modern" yang diberi sesuatu seperti di atas mungkin menyimpulkan bahwa karena perhitungan x * x akan meluap jika x lebih besar dari 46340, ia dapat melakukan panggilan ke "foo" tanpa syarat. Perhatikan bahwa meskipun akan dapat diterima jika sebuah program berhenti secara tidak normal jika x berada di luar jangkauan, atau meminta fungsi mengembalikan nilai apa pun dalam kasus seperti itu, memanggil foo () dengan out-of-range x dapat menyebabkan kerusakan jauh melampaui salah satu dari kemungkinan itu. Tradisional C tidak akan menyediakan alat pengaman apa pun di luar apa yang disediakan oleh programmer dan platform yang mendasarinya, tetapi akan memungkinkan alat pengaman membatasi kerusakan dari situasi yang tidak terduga. Modern C akan mem-bypass setiap peralatan keselamatan yang tidak 100% efektif untuk menjaga semuanya terkendali.


3
@ Davidvidhorn: Mungkin contoh saya terlalu halus. Jika int32 bit, maka xakan dipromosikan untuk ditandatangani int. Dilihat dari alasannya, penulis Standar berharap bahwa implementasi non-aneh akan memperlakukan jenis yang ditandatangani dan tidak ditandatangani dengan cara yang setara di luar beberapa kasus tertentu, tetapi gcc kadang-kadang "mengoptimalkan" dengan cara yang memecah jika a uint16_tdengan uint16_tberlipat ganda menghasilkan hasil di luar INT_MAX , bahkan ketika hasilnya digunakan sebagai nilai yang tidak ditandatangani.
supercat

4
Contoh yang baik. Ini adalah salah satu alasan mengapa kita harus selalu dikompilasi dengan (pada GCC atau Dentang) -Wconversion.
Davislor

2
@ Davidvis: Ah, saya baru saja memperhatikan bahwa godbolt membalik urutan di mana versi kompiler terdaftar, jadi memilih versi terakhir gcc dalam daftar menghasilkan yang terbaru daripada yang paling awal. Saya tidak berpikir peringatan itu sangat membantu karena cenderung menandai banyak situasi seperti return x+1;yang seharusnya tidak menjadi masalah, dan memberikan hasilnya ke uint32_t akan melumpuhkan pesan tanpa memperbaiki masalah.
supercat

2
@supercat Menghilangkan tes tidak ada gunanya jika kompiler diperlukan untuk mengembalikan tes di tempat yang berbeda.
user253751

3
@immibis: Arahan "asumsikan" dapat memungkinkan kompiler mengganti banyak tes, atau pemeriksaan yang akan dilakukan berkali-kali dalam satu loop, dengan satu tes yang dapat diangkat di luar loop. Itu lebih baik daripada meminta pemrogram untuk menambahkan pemeriksaan yang tidak akan diperlukan dalam kode mesin untuk program memenuhi persyaratan, untuk tujuan memastikan bahwa kompiler tidak "mengoptimalkan" pemeriksaan yang diperlukan untuk memenuhi persyaratan.
supercat

7

Ada beberapa lapisan kebenaran dalam suatu bahasa. Dalam rangka meningkatkan abstraksi:

  • Beberapa program bebas kesalahan (hanya program yang kebenarannya dapat dibuktikan). Yang lain telah menyebutkan bahwa penahanan kesalahan adalah aspek keselamatan yang paling konkret. Bahasa yang berjalan di mesin virtual seperti Java dan .net umumnya lebih aman dalam hal ini: Kesalahan program biasanya dicegat dan ditangani dengan cara yang ditentukan. 1
  • Pada level berikutnya, kesalahan yang terdeteksi pada waktu kompilasi alih-alih pada saat run time membuat bahasa lebih aman. Program yang benar secara sintaksis juga semestinya benar semaksimal mungkin. Tentu saja kompiler tidak dapat mengetahui gambaran besarnya, jadi ini menyangkut level detail. Tipe data yang kuat dan ekspresif adalah salah satu aspek keselamatan pada level ini. Orang bisa mengatakan bahasanya harus menyulitkan untuk membuat kesalahan jenis tertentu(ketik kesalahan, akses tidak terbatas, variabel tidak diinisialisasi, dll.). Informasi jenis run-time seperti array yang membawa informasi panjang menghindari kesalahan. Saya memprogram Ada 83 di perguruan tinggi dan menemukan bahwa program kompilasi Ada biasanya berisi urutan kesalahan yang lebih kecil daripada program C yang sesuai. Ambil saja kemampuan Ada untuk menentukan tipe bilangan bulat yang tidak dapat ditentukan pengguna tanpa konversi eksplisit: Seluruh kapal ruang angkasa jatuh karena kaki dan meter bingung, yang bisa dihindari orang dengan Sepele.

  • Pada level selanjutnya, bahasa harus menyediakan cara untuk menghindari kode boilerplate. Jika Anda harus menulis wadah sendiri, atau penyortirannya, atau gabungannya, atau jika Anda harus menulis sendiri, string::trim()Anda akan membuat kesalahan. Karena tingkat abstraksi naik kriteria ini melibatkan bahasa yang tepat serta perpustakaan standar bahasa.

  • Hari-hari ini bahasa harus menyediakan sarana untuk pemrograman bersamaan pada tingkat bahasa. Konkurensi sulit untuk diperbaiki dan mungkin mustahil dilakukan dengan benar tanpa dukungan bahasa.

  • Bahasa harus menyediakan sarana untuk modularisasi dan kolaborasi. Jenis yang kuat, rumit, yang ditentukan pengguna dari atas membantu membuat API ekspresif.

Agak orthogonal definisi bahasa harus dapat dipahami; bahasa dan perpustakaan harus didokumentasikan dengan baik. Dokumentasi yang salah atau hilang menyebabkan program yang salah dan salah.


1 Tetapi karena biasanya kebenaran dari mesin virtual tidak dapat dibuktikan bahasa-bahasa semacam itu mungkin agak tidak cocok untuk persyaratan keamanan yang sangat ketat.


1
+1 Untuk penjelasan lapisan demi lapisan yang jelas. Sebuah pertanyaan untuk Anda, kapal ruang angkasa Utuh telah jatuh karena kaki dan meter bingung, yang sepele bisa dihindari dengan Ada. , apakah Anda berbicara tentang Probe Mars yang Hilang Karena Kesalahan Matematika Sederhana ? Apakah Anda tahu bahasa yang mereka gunakan untuk kapal ruang angkasa itu?
scaaahu

2
@scaaahu Ya, saya pikir saya maksudkan itu. Tidak, saya tidak tahu bahasanya. Sebenarnya, membaca laporan, tampaknya data yang dikirim oleh probe diproses oleh perangkat lunak di bumi menghasilkan file data yang kemudian digunakan untuk menentukan level dorong. Pengetikan bahasa sederhana tidak berlaku dalam skenario ini. Namun, mereka memiliki beberapa masalah dengan perangkat lunak dasar dan format file data, kebingungan yang mencegah deteksi dini masalah. Jadi ceritanya bukan argumen langsung untuk pengetikan yang kuat tetapi masih merupakan kisah peringatan.
Peter - Reinstate Monica

1

Tolong, jangan katakan bahwa setiap PL memiliki perintah yang tidak aman. Kami selalu dapat mengambil bagian yang aman.

Setiap bahasa yang saya tahu memiliki cara menulis program ilegal yang dapat (dikompilasi dan) dijalankan. Dan setiap bahasa yang saya tahu memiliki bagian yang aman. Jadi, apa pertanyaanmu sebenarnya?


Keamanan multidimensi dan subyektif.

Beberapa bahasa memiliki banyak operasi yang "tidak aman". Lainnya memiliki operasi yang lebih sedikit. Dalam beberapa bahasa, cara standar melakukan sesuatu pada dasarnya tidak aman. Pada yang lain, cara defaultnya aman. Dalam beberapa bahasa, ada subset eksplisit "tidak aman". Dalam bahasa lain, tidak ada himpunan bagian sama sekali.

Dalam beberapa bahasa, "keselamatan" mengacu secara eksklusif pada keamanan memori - layanan yang ditawarkan oleh perpustakaan standar dan / atau runtime di mana pelanggaran akses memori menjadi sulit atau tidak mungkin. Dalam bahasa lain, "safety" secara eksplisit menyertakan safety thread. Dalam bahasa lain, "keselamatan" mengacu pada jaminan bahwa suatu program tidak akan macet (persyaratan yang mencakup tidak mengizinkan pengecualian apa pun yang tidak tertangkap). Akhirnya, dalam banyak bahasa "keselamatan" mengacu pada keselamatan tipe - jika sistem tipe konsisten dalam cara-cara tertentu, dikatakan sebagai "suara" (kebetulan, Java dan C # tidak memiliki sistem tipe suara sepenuhnya).

Dan dalam beberapa bahasa, semua arti "keselamatan" yang berbeda dianggap sebagai himpunan bagian dari jenis keamanan (mis. Rust dan Pony mencapai keamanan benang melalui sifat-sifat sistem jenis).


-1

Jawaban ini sedikit lebih luas. Kata-kata aman dan keselamatan dalam beberapa dekade terakhir telah dimutilasi oleh bagian-bagian tertentu dari masyarakat berbahasa Inggris yang berorientasi politik, sehingga penggunaan umum mereka hampir tidak memiliki definisi. Namun, untuk subjek teknis saya masih kembali untuk mendefinisikan "keselamatan" dan "aman" sebagai: perangkat yang mencegah penggunaan sesuatu yang tidak disengaja atau yang membuat penggunaan tidak disengaja secara substansial lebih sulit, dan keadaan di bawah perlindungan perangkat seperti itu .
Jadi bahasa yang aman memiliki beberapa perangkat untuk membatasi kelas bug tertentu. Tentu saja batasan datang dengan ketidaknyamanan atau bahkan ketidakmampuan dalam beberapa kasus, dan itu tidak berarti bahwa bahasa "tidak aman" akan menghasilkan bug. misalnya saya tidak memiliki sumbat pengaman di garpu dan selama beberapa dekade berhasil, tanpa banyak usaha, untuk menghindari menusuk mata saya saat makan. Tentu saja lebih sedikit upaya daripada yang akan dikeluarkan menggunakan gabus. Jadi Keselamatan dilengkapi dengan biaya yang harus dinilai. (Garpu gabus adalah referensi ke karakter Steve Martin)

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.