Wpis z mikrobloga

@groman43: Niby nie rozwiazuje, ale wywolywanie unwrap() bez sprawdzenia wczesniej, co siedzi w optionalu to proszenie sie o klopoty i w podstawowych tutorialach ucza, zeby uzywac innych metod ¯\(ツ)/¯
  • Odpowiedz
@groman43: no właśnie z komentarzy wynika że jednak rozwiązuje. Unwrap na null (a dokładniej None) nie jest undefined behavior, w przeciwieństwie do dereferencji złego pointera w c++. Leci wyjątek, normalnie go łapiesz, sterta i stos całe, nic się nie stało, logujemy i jedziemy dalej.

Inna rzecz że można w Rust pisać wygodnie bez unwrap, a zabronienie unwrapów to kwestia konfiguracji CI.
  • Odpowiedz
@Krolik podejście "loguje i lecę dalej" nie sprawdza się w sterownikach. Prawidłową metodą jest zfailowanie wszystkiego. Tak samo jak w tej sytuacji robi Windows. Sterownik który jest wymagany mu się nie załadował więc nie to że wpis do loga i dalej tylko zatrzymanie systemu.
  • Odpowiedz
@zrakiep: to zależy co w sterowniku zrobiło tego nulla. Tak czy siak, gdyby to był Rust to tego błędu najprawdopodobniej by nie było bo nikt nie używa unwrap do odpakowywania czegoś co może być None. Serio nie pamiętam czy w ciągu ostatnich 5 lat miałem jakikolwiek błąd typu unwrap na None.
  • Odpowiedz
@Krolik: a tak przy okazji, masz jakieś sugestie jak złapać trochę profesjonalnego doświadczenia w rust? Moje korpo raczej się nie kwapi do przesiadki z .net, więc muszę szukać gdzie indziej.
  • Odpowiedz
@Krolik: no właśnie: zależy co. Tak czy siak ktoś musi pomyśleć, kod napisać, nic za darmo nie ma. Nie możesz po prostu logować - no bo dajmy na to, ktoś zrobi jakiegoś pendrive co wywraca Crowdstrike. No lepiej jest jak komp z takim pendrive się nie bootuje niż gdyby pendrive potrafił jailbrake zrobić.

A co do null - też nie pamiętam kiedy ostatni raz takie coś mi się zdarzyło. Use
  • Odpowiedz
@zrakiep: jak się wczytasz głębiej w backtrace to jednak tu nie był null, tylko 0x9c, więc w safe rust tego nie zrobisz nawet unwrapem. Oczywiście zgadzam się z tym co piszesz. Nie da się zapobiec wszystkim błędom. Jednak spośród tych czterech: C++, Java, Python, Rust, w Rust mam najmniej błędów, a szczególnie najczęściej mam takie sytuacje, że napisałem coś i po kompilacji od razu działa jak trzeba.
  • Odpowiedz
@Krolik: te 0x9C to pewnie offset w strukturze, ktoś zrobił ptr->jakies_pole i taki efekt. Jak najbardziej dokładnie to samo zrobisz w Rust i problem dalej jest ten sam: brak logiki do obsługi tego błędu. Nie ma języka co by sobie z tym poradził, jedyne sensowne rozwiązanie to ubicie procesu.
  • Odpowiedz
@zrakiep: w Rust ktoś by napisał ref.jakies_pole i teraz mamy takie scenariusze:
1. Nic się nie dzieje, kod się kompiluje, ale ref nie może być nigdy nullem - sytuacja gdy ktoś zapomni zainicjować / wstawi tam null wcześniej jest błędem kompilacji
2. Dostaje po głowie błędem kompilacji, że ref nie ma takiego pola bo jest opcjonalne. Zastanowi się i przepisze to na idiomatyczne match / if let i obsłuży ten
  • Odpowiedz
@zrakiep: no i chodzą słuchy że ta dereferencja nulla była spowodowana albo wyjściem poza tablicę albo wrzuceniem nulla do tablicy, która nulli mieć nie powinna:

https://x.com/patrickwardle/status/1814343502886477857?s=46

Znowu, pisząc idiomatyczne w Rust, bardzo trudno taki błąd zrobić, bo tu się używa iteratorów a nie dostępu do tablic przez indeks. A indeks dostępu do tablicy jest sprawdzany w runtime, więc nawet jak ktoś pisze kod bez sensu to przynajmniej ma gwarancję wywalenia
  • Odpowiedz
@NieBendePrasowac: reverse engineering kodu sterownika + dane z samego BSODa (Windows zapisuje dość dużo ważnych informacji o procesie, który uległ awarii, np. wiesz w którym miejscu kodu nastąpiło odwołanie do pamięci, do jakiego adresu, co było wtedy na stosie itp)
  • Odpowiedz