Fungsi secara tidak sengaja membatalkan parameter referensi - apa yang salah?

Hari ini kami menemukan penyebab bug buruk yang hanya terjadi sesekali pada platform tertentu. Rebus, kode kami terlihat seperti ini:

class Foo {
  map<string,string> m;

  void A(const string& key) {
    m.erase(key);
    cout << "Erased: " << key; // oops
  }

  void B() {
    while (!m.empty()) {
      auto toDelete = m.begin();
      A(toDelete->first);
    }
  }
}

Masalahnya mungkin tampak jelas dalam kasus sederhana ini: Bmelewatkan referensi ke kunci A, yang menghapus entri peta sebelum mencoba mencetaknya. (Dalam kasus kami, itu tidak dicetak, tetapi digunakan dengan cara yang lebih rumit) Ini tentu saja perilaku yang tidak terdefinisi, karena keymerupakan referensi yang menggantung setelah panggilan ke erase.

Memperbaiki ini sepele - kami baru saja mengubah tipe parameter dari const string&menjadi string. Pertanyaannya adalah: bagaimana kita bisa menghindari bug ini sejak awal? Tampaknya kedua fungsi melakukan hal yang benar:

• Atidak memiliki cara untuk mengetahui yang keymengacu pada hal yang akan dihancurkan.
• Bbisa membuat salinan sebelum meneruskannya A, tetapi bukankah tugas callee untuk memutuskan apakah akan mengambil parameter dengan nilai atau dengan referensi?

Apakah ada aturan yang gagal kita ikuti?

Atidak memiliki cara untuk mengetahui yang keymengacu pada hal yang akan dihancurkan.

Meskipun ini benar, Atahu hal-hal berikut:

1. Tujuannya adalah untuk menghancurkan sesuatu .

2. Dibutuhkan parameter yang sama persis dengan jenis yang akan dihancurkan.

Dengan adanya fakta-fakta ini, dimungkinkan untuk Amenghancurkan parameternya sendiri jika mengambil parameter sebagai pointer / referensi. Ini bukan satu-satunya tempat di C ++ di mana pertimbangan seperti itu perlu diatasi.

Situasi ini mirip dengan bagaimana sifat operator=operator penugasan berarti bahwa Anda mungkin perlu khawatir tentang penugasan mandiri. Itu adalah kemungkinan karena tipe thisdan tipe parameter referensi adalah sama.

Perlu dicatat bahwa ini hanya bermasalah karena Anantinya bermaksud menggunakan keyparameter setelah menghapus entri. Jika tidak, maka itu akan baik-baik saja. Tentu saja, maka semuanya menjadi mudah untuk bekerja dengan sempurna, kemudian seseorang berubah Auntuk menggunakannya keysetelah berpotensi dihancurkan.

Itu akan menjadi tempat yang bagus untuk komentar.

Apakah ada aturan yang gagal kita ikuti?

Dalam C ++, Anda tidak dapat beroperasi dengan asumsi bahwa jika Anda secara buta mengikuti serangkaian aturan, kode Anda akan 100% aman. Kami tidak dapat memiliki aturan untuk semuanya .

Pertimbangkan poin # 2 di atas. Abisa saja mengambil beberapa parameter dari tipe yang berbeda dari kunci, tetapi objek itu sendiri bisa menjadi sub-objek dari kunci di peta. Dalam C ++ 14, finddapat mengambil jenis yang berbeda dari jenis kunci, asalkan ada perbandingan yang valid di antara mereka. Jadi jika Anda melakukannya m.erase(m.find(key)), Anda dapat menghancurkan parameter meskipun tipe parameter bukan tipe kunci.

Jadi aturan seperti "jika tipe parameter dan tipe kuncinya sama, ambil menurut nilainya" tidak akan menyelamatkan Anda. Anda akan membutuhkan lebih banyak informasi dari itu.

Pada akhirnya, Anda perlu memperhatikan kasus penggunaan khusus Anda dan melakukan penilaian, berdasarkan pengalaman.

Saya akan mengatakan ya, ada aturan sederhana yang Anda langgar yang akan menyelamatkan Anda: prinsip tanggung jawab tunggal.

Saat ini, Adilewatkan parameter yang digunakan untuk menghapus item dari peta, dan melakukan beberapa pemrosesan lainnya (mencetak seperti yang ditunjukkan di atas, tampaknya sesuatu yang lain dalam kode sebenarnya). Menggabungkan tanggung jawab itu bagi saya sepertinya merupakan sumber masalah.

Jika kita memiliki satu fungsi yang hanya menghapus nilai dari peta, dan lainnya yang hanya memproses nilai dari peta, kita harus memanggil masing-masing dari kode tingkat yang lebih tinggi, jadi kita akan berakhir dengan sesuatu seperti ini :

std::string &key = get_value_from_map();
destroy(key);
continue_to_use(key);

Memang, nama-nama yang saya gunakan tidak diragukan lagi membuat masalah lebih jelas daripada nama aslinya, tetapi jika nama-nama itu bermakna sama sekali, mereka hampir pasti akan memperjelas bahwa kami berusaha untuk terus menggunakan referensi setelah itu telah dibatalkan. Perubahan konteks yang sederhana membuat masalahnya jauh lebih jelas.

Apakah ada aturan yang gagal kita ikuti?

Ya, Anda gagal mendokumentasikan fungsi tersebut .

Tanpa deskripsi kontrak parameter-passing (khususnya bagian yang berkaitan dengan validitas parameter - apakah itu di awal panggilan fungsi atau seluruh), tidak mungkin untuk mengetahui apakah kesalahan dalam implementasi (jika kontrak panggilan adalah bahwa parameter tersebut valid ketika panggilan dimulai, fungsi tersebut harus membuat salinan sebelum melakukan tindakan apa pun yang mungkin membatalkan parameter) atau dalam pemanggil (jika kontrak panggilan adalah bahwa parameter harus tetap valid selama panggilan berlangsung, pemanggil tidak dapat berikan referensi ke data di dalam koleksi yang sedang dimodifikasi).

Sebagai contoh, standar C ++ itu sendiri menetapkan bahwa:

Jika argumen ke suatu fungsi memiliki nilai yang tidak valid (seperti nilai di luar domain fungsi atau pointer yang tidak valid untuk penggunaan yang dimaksudkan), perilaku tidak terdefinisi.

tetapi gagal untuk menentukan apakah ini hanya berlaku untuk panggilan instan dibuat, atau seluruh pelaksanaan fungsi. Namun, dalam banyak kasus jelas bahwa hanya yang terakhir yang mungkin dilakukan - yaitu ketika argumen tidak dapat dipertahankan dengan membuat salinan.

Ada beberapa kasus dunia nyata di mana perbedaan ini mulai berlaku. Misalnya, menambahkan std::vector<T>ke dirinya sendiri

Apakah ada aturan yang gagal kita ikuti?

Ya, Anda gagal mengujinya dengan benar. Anda tidak sendirian, dan Anda berada di tempat yang tepat untuk belajar :)

C ++ memiliki banyak Perilaku Tidak Terdefinisi, Perilaku tidak terdefinisi bermanifestasi dengan cara yang halus dan menjengkelkan.

Anda mungkin tidak pernah dapat menulis kode C ++ 100% aman, tetapi Anda tentu dapat mengurangi kemungkinan secara tidak sengaja memperkenalkan Perilaku Tidak Terdefinisi dalam basis kode Anda dengan menggunakan sejumlah alat.

1. Peringatan kompiler
2. Analisis Statis (versi diperpanjang dari peringatan)
3. Binari Uji Instrumentasi
4. Binari Produksi Hardened

Dalam kasus Anda, saya ragu (1) dan (2) akan banyak membantu, meskipun secara umum saya menyarankan untuk menggunakannya. Untuk sekarang mari kita berkonsentrasi pada dua lainnya.

Baik gcc dan Clang menampilkan -fsanitizeflag yang instrumen program-program yang Anda kompilasi untuk memeriksa berbagai masalah. -fsanitize=undefinedmisalnya akan menangkap bilangan bulat ditandatangani / limpahan, bergeser dengan jumlah yang terlalu tinggi, dll ... Dalam kasus spesifik Anda, -fsanitize=addressdan -fsanitize=memorykemungkinan akan mengambil masalah ... asalkan Anda memiliki tes memanggil fungsi. Untuk kelengkapannya, -fsanitize=threadlayak digunakan jika Anda memiliki basis kode multi-threaded. Jika Anda tidak dapat mengimplementasikan biner (misalnya, Anda memiliki perpustakaan pihak ke-3 tanpa sumbernya), maka Anda juga dapat menggunakannya valgrindmeskipun secara umum lebih lambat.

Kompiler terbaru juga menampilkan kemungkinan pengerasan kekayaan . Perbedaan utama dengan biner yang diinstrumentasi, adalah bahwa cek pengerasan dirancang memiliki dampak rendah pada kinerja (<1%), membuatnya cocok untuk kode produksi pada umumnya. Yang paling terkenal adalah pemeriksaan CFI (Control Flow Integrity) yang dirancang untuk menggagalkan serangan stack stack dan hi-jacking virtual pointer di antara cara-cara lain untuk menumbangkan aliran kontrol.

Maksud dari keduanya (3) dan (4) adalah untuk mengubah kegagalan yang terputus - putus menjadi kegagalan tertentu : keduanya mengikuti prinsip gagal puasa . Ini berarti:

• selalu gagal saat Anda menginjak ranjau darat
• gagal segera , mengarahkan Anda pada kesalahan daripada merusak memori secara acak, dll ...

Menggabungkan (3) dengan cakupan tes yang baik harus menangkap sebagian besar masalah sebelum mereka mencapai produksi. Menggunakan (4) dalam produksi dapat menjadi perbedaan antara bug yang mengganggu dan exploit.

@ catatan: posting ini hanya menambahkan lebih banyak argumen di atas jawaban Ben Voigt .

Pertanyaannya adalah: bagaimana kita bisa menghindari bug ini sejak awal? Tampaknya kedua fungsi melakukan hal yang benar:

• A tidak memiliki cara untuk mengetahui bahwa kunci mengacu pada hal yang akan dihancurkan.
• B bisa membuat salinan sebelum meneruskannya ke A, tapi bukankah tugas callee untuk memutuskan apakah akan mengambil parameter dengan nilai atau dengan referensi?

Kedua fungsi melakukan hal yang benar.

Masalahnya adalah dalam kode klien, yang tidak memperhitungkan efek samping dari panggilan A.

C ++ tidak memiliki cara langsung untuk menentukan efek samping dalam bahasa.

Ini berarti terserah kepada Anda (dan tim Anda) untuk memastikan hal-hal seperti efek samping terlihat dalam kode (sebagai dokumentasi), dan dipelihara dengan kode (Anda mungkin harus mempertimbangkan untuk mendokumentasikan pra-kondisi, kondisi pasca dan invarian) juga, untuk alasan visibilitas juga).

Perubahan kode:

class Foo {
  map<string,string> m;

  /// \sideeffect invalidates iterators
  void A(const string& key) {
    m.erase(key);
    cout << "Erased: " << key; // oops
  }
  ...

Dari titik ini Anda memiliki sesuatu di atas API yang memberi tahu Anda bahwa Anda harus memiliki unit test untuknya; Ini juga memberi tahu Anda cara menggunakan (dan tidak menggunakan) API.

bagaimana kita bisa menghindari bug ini sejak awal?

Hanya ada satu cara untuk menghindari bug: berhenti menulis kode. Semuanya gagal dalam beberapa cara.

Namun, pengujian kode di berbagai tingkatan (tes unit, tes fungsional, tes integrasi, tes penerimaan, dll) tidak hanya akan meningkatkan kualitas kode, tetapi juga mengurangi jumlah bug.