On Thu, 26 Jan 2017 19:28:45 +0100, Sebastian
Biały<h...@p...onet.pl> wrote:
> > A bo jeszcze dużo zależy: czy null pointer może tam być
> Żartujesz, prawda?

Nie.

do góry

On 2017-01-27 06:35, slawek wrote:
> On Thu, 26 Jan 2017 19:28:45 +0100, Sebastian Biały<h...@p...onet.pl>
> wrote:
>> > A bo jeszcze dużo zależy: czy null pointer może tam być
>> Żartujesz, prawda?
> 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.

do góry

On Fri, 27 Jan 2017 07:24:11 +0100, Sebastian
Biały<h...@p...onet.pl> wrote:
> Więc może wyjaśnijmy: null pointer dereference *zazwyczaj* kończy
się
> sygnałem zabijającym aplikację

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ć.

do góry

On 2017-01-27 18:26, slawek wrote:
>> Więc może wyjaśnijmy: null pointer dereference *zazwyczaj* kończy
> się
>> sygnałem zabijającym aplikację
> A konkretnie w jakim języku? W jakim programie?

C++ w programie na linuxa.

> Od około 20 lat powszechnie używa się mechanizmów takich jak obsługa
> wyjątków.

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.

> Jakiś tam null pointer (użyty do czegoś, bo nie użyty to
> zupełnie nieszkodliwe jest)

*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).

>, czy dzielenie przez zero itd itp. wcale nie
> muszą (i nie kończą się) "zabijaniem aplikacji".

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

> Oczywiście możesz
> sprawdzać co instrukcję if ( ptr != NULL ) etc., ale po co?

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ź:

https://pl.wikipedia.org/wiki/Naruszenie_ochrony_pam
i%C4%99ci#Odwo.C5.82anie_do_zerowego_adresu_pami.C4.
99ci

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

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

do góry

On Fri, 27 Jan 2017 21:21:18 +0100, Sebastian
Biały<h...@p...onet.pl> wrote:
> C++ w programie na linuxa.

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

> 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.

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.

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

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.

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

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.

do góry

On 2017-01-27 22:55, slawek wrote:
>> C++ w programie na linuxa.
> Czyli języku bez GC i bez maszyny wirtualnej. W którym błąd "null
> pointer" wywołuje panikę programistów.

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?

> 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ć.

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.

> 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.

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ć?

>> Oczywiście że się kończą. Aby to sprawdzić możesz poświęcić 4
> minuty.
> 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.

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:

http://stackoverflow.com/questions/18118408/what-is-
difference-between-quiet-nan-and-signaling-nan

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ć.

>> char *a = 0;
>> chat x = *a;
>
> Rozumiem że miało być char?
>
> W czym problem? Pierwsza linijka to niechlujstwo, ale w C++ może
> przejść.

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

> Druga linijka powinna wywołać wyjątek.

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.

> 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.

Co?

> No wiem że akurat tobie
> będzie trudno zrobić coś mądrego.

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.

do góry

On Fri, 27 Jan 2017 23:40:42 +0100, Sebastian
Biały<h...@p...onet.pl> wrote:
> 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.

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ć.

do góry

On Fri, 27 Jan 2017 23:40:42 +0100, Sebastian
Biały<h...@p...onet.pl> wrote:
> nowy wzorzec projektowy, null pointer oriented programming może by
go

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ć.

do góry

On Fri, 27 Jan 2017 23:40:42 +0100, Sebastian
Biały<h...@p...onet.pl> wrote:
> Nie ma się co dziwic że istnieją *jakieś* niepopularne języki

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

do góry

On Fri, 27 Jan 2017 23:40:42 +0100, Sebastian
Biały<h...@p...onet.pl> wrote:
> >> char *a = 0;
> >> chat x = *a;


> > W czym problem? Pierwsza linijka to niechlujstwo, ale w C++ może
> > przejść.


> Nie, to dzień jak codzień. Inicjowanie pointera na null jest
bezpieczne.

Prawidłowo robi się w C++

char * ptr = nullptr;

natomiast w C

char * ptr = NULL;

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

do góry