Czas na Windows 10

Ale każda która chce *produkować* sprzet komputerowy inny niż zabawki musi być bardzo bogata i spora. Z powodu troli patentowych, głównie.

Jednak nie rozumiesz czyim jest open source, a raczej dla kogo jest.

Nie.

Więc może wyjaśnijmy: null pointer dereference *zazwyczaj* kończy się sygnałem zabijającym aplikację (ogólnie to undefined behavior). Nie znam przyczyny dla której ktoś mógłby to zrobić świadomie poza zwykłym bugiem w kodzie. Zaryzykuje że taka nie istnieje.

A konkretnie w jakim języku? W jakim programie?

Od około 20 lat powszechnie używa się mechanizmów takich jak obsługa wyjątków. Jakiś tam null pointer (użyty do czegoś, bo nie użyty to zupełnie nieszkodliwe jest), czy dzielenie przez zero itd itp. wcale nie muszą (i nie kończą się) "zabijaniem aplikacji". Oczywiście możesz sprawdzać co instrukcję if ( ptr != NULL ) etc., ale po co?

Seba, ja wiem że tobie się wydaje że umiesz programować.

C++ w programie na linuxa.

To jest wyjatek systemowy lub sprzetowy, nie języka. Można go przejąc tylko co zrobisz dalej? Program zrobil dereferencję nulla. Cala reszta algorytmu nie ma sensu. Masz śmiecia zamiast danej.

*dereferencja* jest użyciem. Powoduje odczyt z adresu 0. Generuje to wyjątek na poziomie sprzętowym jeśli CPU to wspiera (a wspiera każdy współaczesny z MMU czyliz grubsza również każdy Linux, Windows, Android, Solaris itd).

Oczywiście że się kończą. Aby to sprawdzić możesz poświęcić 4 minuty.

Interesujące teorie przed nami otwierasz. Po co sprawdzać nullowośc wskaźnika? Bo ja wiem, żeby nie zakończyć bus errorem albo SIGSEGV?

Czyli w/g Ciebie zrobienie:

char *a = 0; chat x = *a;

Powinno zakończyć się czymś niegroźnym :) ? Faktycznie, istnieją architekury na których tak można, ba nawet istnieje sensowna pamięć pod adresem 0. Ale tutaj mowa o linuxie. Tam kończy się to sygnałem. Z premedytacją zastawiona pułapka na niedzielnych programistów.

Może zanim zaczniesz opowiadać bzdury ktore ktoś przeczyta, sprawdź:

Mi się nie tylko wydaje. Nie brnij dalej. Szkoda się kompromitować publicznie.

Czyli języku bez GC i bez maszyny wirtualnej. W którym błąd "null pointer" wywołuje panikę programistów.

Owszem. Tyle że - jak już misiu nauczysz się jak wygląda obsługa wyjątków w Javie/C#/Delphi a nawet C++ - wytegolenie się połowy programu nie oznacza że program musi przestać działać. Zwłaszcza jeżeli jest event driven. Dla przykładu: null pointer bo nie ma drukarki, ale przecież nie musisz drukować jak nie ma drukarki. Ważne aby dało się dane zapisać. I gdy już podłączysz drukarkę dostaniesz drugą szansę... śliczny pointer nie null. I to bez przerwy w działaniu całego programu.

A to porozmawiaj o tym z moim programem, który przez dwa dni liczył sobie na inf'ach i nan'ach. Nie kończył się... Ale może to wina Fortranu? Bo procesor całkiem zwyczajny I7.

Rozumiem że miało być char?

W czym problem? Pierwsza linijka to niechlujstwo, ale w C++ może przejść. Druga linijka powinna wywołać wyjątek. I jak ten wyjątek olejesz, to faktycznie program zwyczajowo się kończy. Ale cały myk że możesz nie olewać, tylko zrobić coś mądrego. No wiem że akurat tobie będzie trudno zrobić coś mądrego.

Nie bądź zdziwiony. Tutaj jest o tym mowa. Zaryzykuje również że jeśli mowa o Linuxie to 95% softu takie jest. Zastanawiające że próbujesz zachowac twarz uciekając w jezyki z GC skoro była jasno mowa o Linuxie. Za chwile się okaże że wzrocowa jest maszyna wirtualna javy bo przecież wątek jest o Javie. A jest, nie?

Wyjątki w C++ znam w szczegółach, czesto debuguje cieżkie przypadki i bywa że robie to na poziomie asm. Jako misio nie zauważyłem aby C++ łapał try catch wyjątki dereferencji nulla. Być może w paralernym wszechświecie w którym istniejesz. Tak, są implementacje C++ które pozwalają łapać wyjątki systemowe przez niestandardowe rozszerzenia. Nie mają za dużego związku z C++ i nie powodują że algorytm z automatu da się popchnąc dalej. W zasadzie są dośc katastrofalne w skutkach ponieważ zazwyczaj byle jak lub zupełnie nie zwijają stosu zostawiając stos w stanie niestabilnym. RAII idzie do piachu.

Fascynujące. Opisujesz wysokopoziomowy projekt jakiegos mechanizmu i jednoczesnie zarzucasz mi brak rozumienia co to jest null pointer dereference? No weź przestań. Chyba nie chcesz tego mechanizmu implementowac przechwytując wyjatki SIGSERV? No no, szacun. To jakiś nowy wzorzec projektowy, null pointer oriented programming może by go nazwać?

Dzielenie przez zero powoduje wyjatek sprzetowy. Używanie do obliczeń Nan *może* powodować wyjątek jesli chcesz, albo nie. To cecha wielu FPU. I mozna tym sterowac z poziomu kodu. Mozna tez sobie dodać ifa w kodzie wynikowymj przy kompilacji a przed dzieleniem i samodzielnie w runtime wygenerować exception jak chcesz a potem mówić że dzielenie przez zero nie zatrzymuje aplikacji.

Tu masz wyjasnione:

Nie ma się co dziwic że istnieją *jakieś* niepopularne języki programowania gdzie bugi są suppresowane na poziomie kompilatora i runtime używając spacjalnego bitu w liczbie nan. A może wystarczy flaga do kompilatora aby to zachowanie zmienić.

Nie, to dzień jak codzień. Inicjowanie pointera na null jest bezpieczne. I częste.

Moze. Nie musi. To jest UB. Może rownie dobrze odkręcić kran w piwnicy albo zajodłować.

Wiele OSów aby silnie zdefiniować to UB stawia pułapkę sprzętową na tym adresie (0) i zabija aplikację. Natychmiast o ile nie przechwycisz

*specjalnego* wyjątku systemowego. Tylko że w złozonym programie po jego przechwyceniu niewiele da się zrobić poza poskładaniem tego co się da *ewentualnie* poskładać i wyjściem z racji faktu że ten wyjątek systemowy ma głeboko w d... RAII.

Co?

Więc pokaz jak zrobić coś madrego w tej sytuacji w C++. Jeśli nie znasz skladni możesz to opisać słowami. W C++, prosze.

Skoro postanowiłes się kompromitować to ciągnijmy to dalej, niechaj będzie troche pośmiewiska.

Pytałem jaki język? Pytałem. Nota bene jakiś czas temu zauważyłem wzrost popularności Pythona w Linuksie. Może Stalmann tego nie wie, może ty tego nie wiesz, ale na C bez plusów świat się nie kończy. I nawet C++ obsługuje wyjątki, choć bez GC jest to średnio wygodne.

A istotne jest, że wyjątek można przechwycić aby program mógł dalej działać. Więc patologiczna sytuacja, taka jak null pointer itp., da się wyleczyć, nie trzeba zabijać procesu.

Z drugiej strony... obsługa wyjątków w C++ jakoś nie bardzo wydaje się pasować do małych mikrokontrolerów. Ale tu mogę się mylić.

Dlaczego nowy? Tworzysz sobie obiekty. One tam sobie tworzą inne obiekty. Jak czegoś tam nie ma, lub nie wyszło, to gdzieś jest null. Jak ten null przeszkadza, to jest wyjatek. Zamiast nasycać program if'ami masz parę try/except/finally. Prościej, łatwiej,przyjemniej.

Oczywiście system/język musi na to pozwalać.

Fortran jest jak widać czymś bardzo tajemniczym dla ciebie. Warto zapamiętać.

Prawidłowo robi się w C++

char * ptr = nullptr;

natomiast w C

char * ptr = NULL;

Postawienie ptr = 0 ujdzie, ale szczytem elegancji nie jest.

C++ nie obsługuje wyjątków null pointer dereference.

Na szczególna uwagę zasługuje słowo anti-pattern.

I oczywiście dostarczać bezkosztową implementację wyjątków.

Jest niepoplularny. Dla reszty świata też.

A więc zamiast odnosić się do meritum idziesz w kierunku detali. No no :D Ale szybka ucieczka...

W C. Ale na C świat się nie kończy i dlatego pytałem w jakim języku ten program.

Wyobraź sobie, że masz zjeść śniadanie: usmażyć jajecznicę, zaparzyć herbatę itd. Okazuje się że w temacie mania jaj wystąpił u ciebie null pointer. Nie masz jaj. I jajecznicy nie zrobisz.

Według twojej logiki ta wyjątkowa sytuacja prowadzi do niemożliwości zjedzenia śniadania. A być może śmierci głodowej: wszak jak nie udało ci się zrealizować kroku n, to nie możesz przejść do n+1, a więc nie wolno ci zjeść obiadu itd.

Tymczasem przeciętny człowiek bezproblemowo przechwyci wyjątek. Jeżeli nie może zrobić X to zrobi Y. Nie może usmażyć jajecznicy? To zrobi kanapki z wędliną. Nie da się? To zje coś na mieście, albo zamówi pizzę przez Internet. Po prostu celem dla niego nie jest fiksacja na realizacji czegoś czego zrealizować się nie da.

Wyjątki w programowaniu to realizacja planu B wtedy gdy plan A zawiódł. Nie oznacza to że z planem A było wszystko ok. Ale jeżeli plan B wykonany został to znaczy że cały program jako taki działa zadowalająco.

A jakieś konkretne dane masz?