Ternyata kode Assembly tulisan tangan yang menyediakan fungsi "strcmp" perbandingan string yang dioptimalkan untuk arsitektur prosesor Motorola 68000 (m68k) "selalu rusak" dan baru sekarang ditemukan pada akhir tahun 2022. Sementara penggemar open-source dan lainnya ingin berpikir bahwa bug dalam kode sumber terbuka mudah terlihat, terutama ketika menyangkut basis kode kernel Linux yang besar untuk kode yang menyentuh perangkat keras yang menua/niche yang tidak selalu demikian. Untuk prosesor Motorola 68000 yang berusia puluhan tahun, baru-baru ini terungkap bahwa implementasi strcmp() yang dioptimalkan secara halus rusak tetapi sekarang menjadi lebih jelas setelah perubahan kernel lainnya. Linus Torvalds menangani masalah ini dan berkomentar bahwa itu "selalu rusak" dan memang ketika menarik kode m68k strcmp() kembali ke Linux awal 2,6 hari ketika awalnya diimpor ke Git, fungsi tersebut memang rusak setidaknya kembali sejauh itu, jika tidak selalu kembali ke port Linux/m68k asli.

Tetapi untuk implementasi strcmp yang rusak ini rusak selama bertahun-tahun di kernel dan tidak diperhatikan, seperti yang dijelaskan Torvalds bahwa itu tidak kentara karena hanya rusak untuk kasus luapan dan sebagian besar pengguna kernel strcmp() tidak peduli pemesanan non-US-ASCII. Banyak pengembang juga hanya peduli jika strcmp() cocok dengan dua string atau tidak tetapi tidak selalu peduli dengan nilai yang dikembalikan sebaliknya. Masalah m68k strcmp() hanya menjadi lebih jelas sekarang dengan kode pengembangan kernel Linux 6.2 di mana flag compiler -funsigned-char sedang diatur untuk menangani kode buggy dengan lebih baik. Linus Torvalds menyimpulkan masalah dalam komit memperbaiki masalah ini, yang juga disematkan di bawah agar mudah dibaca. Perbaikan/penyelesaiannya hanya menghapus implementasi yang dioptimalkan (rusak) sehingga akan kembali menggunakan implementasi strcmp() generik di dalam kernel untuk mereka yang masih menjalankan perangkat keras seri Motorola 68000. Versi assembler m68 yang ditulis tangan dari strcmp() selalu rusak: ini mengembalikan perbedaan antara byte pertama yang tidak cocok yang dilakukan sebagai pengurangan 8-bit. Itu _hampir_ benar, tetapi rusak karena kasus luapan. Fungsi strcmp() memang harus mengembalikan tanda perbedaan antara byte pertama yang berbeda, tetapi pengurangan perlu dilakukan dalam jenis yang lebih luas dari `char`. Kalau tidak, pemesanan sebenarnya tidak stabil. Ini pada dasarnya tidak diketahui selamanya, karena tidak ada yang peduli dengan pemesanan non-US-ASCII di kernel (pada kenyataannya, sebagian besar pengguna hanya peduli tentang "cocok persis atau tidak"), jadi luapan tidak benar-benar terjadi dalam praktiknya, bahkan jika itu sangat sangat salah. Tetapi sebagian besar bug yang tidak terlihat itu menjadi sangat terlihat dengan perubahan baru-baru ini untuk membuat `char` tidak ditandatangani di kernel di semua arsitektur (komit 3bc753c06dd0: "kbuild: perlakukan char seperti biasa tidak ditandatangani"). Karena kode tidak hanya melakukan pengurangan pada lebar tipe yang salah, kode ini juga menggunakan `char` untuk kemudian membuat kompiler memperluas hasil dari perbedaan 8-bit ke nilai kembalian `int`. Jadi sekarang dengan unsigned char lebar aritmatika yang salah bahkan tidak diperluas tandanya, dan selalu mengembalikan hanya bilangan bulat positif. Kita dapat mengembalikan kode lama yang rusak hanya dengan mengubah `char` menjadi `signed char` seperti yang telah dilakukan di tempat lain di mana orang bergantung pada tanda tangan `char`, tetapi karena seluruh fungsi telah rusak sejak awal, dan kami memiliki implementasi fallback default yang tidak rusak, mari kita hapus fungsi yang rusak ini seluruhnya. Menjatuhkan implementasi m68k strcmp() yang rusak digabungkan hari ini untuk Linux 6.2.

Itulah berita seputar Ups: strcmp Linuxs () Untuk m68k Selalu Rusak, semoga bermanfaat. Disadur dari Phoronix.com.