On Fri, 06 Sep 2019 01:12:39 -0700, M.M. wrote:
> A uzasadnienia i tak i tak nie będzie.

AK to mistrz krytyki, ale na tym jego talent zdaje się kończyć... nie
widziałem by kiedykolwiek sam cokolwiek mądrego napisał. Niemniej (a
raczej tym bardziej) jestem pod wrażeniem cierpliwości którą kolega
wykazuje.

> Pora na kawał. Rozmawia dwóch informatyków. Jeden pyta:
> - dlaczego tak myślisz kolego?
> Drugi odpowiada:
> - co cie to obchodzi!

Tutaj bardziej adekwatny byłby taki wariant:
- dlaczego tak myślisz kolego?
- BO TY GUPI JESTEŚ, WIEM LEPIEJ!!!
- ależ kolego, proszę wyjaśnić
- SPIERDALAJ!!!

Ale nie żeby to był ewenement jakiś - to niestety częsty przypadek w
ogólno-pojętym IT. :)

Mateusz

do góry

On Friday, September 6, 2019 at 10:33:01 AM UTC+2, Mateusz Viste wrote:
> On Fri, 06 Sep 2019 01:12:39 -0700, M.M. wrote:
> > A uzasadnienia i tak i tak nie będzie.
>
> AK to mistrz krytyki, ale na tym jego talent zdaje się kończyć... nie
> widziałem by kiedykolwiek sam cokolwiek mądrego napisał. Niemniej (a
> raczej tym bardziej) jestem pod wrażeniem cierpliwości którą kolega
> wykazuje.

Rozmowa, a przynajmniej któryś post, wydała się bardzo ciekawa i, nawet
nie byłem cierpliwy, tylko zwyczajnie chciałem się dowiedzieć jaka
jest (najlepiej kompletna) lista argumentów za tym, że C++ nie nadaje
się do tworzenia niezawodnych systemów. I, rzecz jasna, jaka jest
alternatywa dla C++, bo jak C++ ma wady, a nie ma nic wyraźnie lepszego,
to żadne argumenty mnie nie przekonają.

Warto zobaczyć ile błędów było w różnych kompilatorach w różnych językach.
Do C/C++ jest dużo niezależnych kompilatorów, można więc łatwo zrobić
testy krzyżowe - to już jest mocny argument za użyciem C++. Ja często
bym wolał coś w okolicach języka D, ale D nie ma takiego wsparcia jak C++,
więc używam C++.

Potem koszty, ciekawe ile kosztuje dobry programista w niszowym-dedykowanym
języku? Może dwóch programistów w C++ napisze bezpieczniejszy kod, niż
jeden (za te same pieniądze) w niszowym-dedykowanym języku?

Potem mnogość bibliotek. Do C++ jest całkiem sporo, często biblioteki są
pisane natywnie w C/C++, a dopiero później robi się port do innych języków.
Robienie portu to dodatkowa okazja do popełnienia błędów, więc bezpieczniej
jest w natywnej. A jeśli do dedykowanego języka nie ma bibliotek, to ciekawe
ile błędów narobią, albo ile czasu stracą na tworzenie/portowanie swojej biblioteki?
Może w tym czasie poprawili by właściwy kod aplikacji w C++?

Kolejna sprawa, napisałem w C/C++ sporo, w tym też kilka pewnych aplikacji.
Defakto były to malutkie aplikacje, ale wcale nie były trywialne obliczeniowo.
Z powodu agresywnej optymalizacji są zaprzeczeniem bezpiecznego stylu
programowania. Mimo to, działają do dziś, od wielu lat nie miałem zgłoszenia
błędu. Jeśli aplikacja nie musi być super zoptymalizowana (mowa o optymalizacji
na jeden procesor, bo w zamian za to, aplikację nadal można optymalizować na
klastry i/albo GPU) to można w C++ stworzyć aplikację składającą się np. w 98% z
czytelnego i bezpiecznego kodu. Pozostałe 2% nie jest kulą u nogi, lecz pomaga
utrzymać jeszcze większy porządek w tych 98%, stanowi dobrze wydzielone
procedury wielokrotnie użyte (a więc dobrze przetestowane) w kodzie.


Co tu by jeszcze dorzucić na korzyść C/C++... Może to, że jeśli aplikację
jednak trzeba trochę zopytmalizować na jeden procesor, to do C/C++ są
bardzo dobre optymalizatory. Więc w takich przypadkach w C++ można sobie
napisać czytelnie, a martwi się optymalizator. W innych językach które
nie mają takiego wsparcia może trzeba jakieś haki czasami w kodzie robić,
żeby procesor/ram nadążył.

Oczywiście C++ ma wady, ale te wady wynikają ani z języka, ani z narzędzi,
ani z bibliotek, lecz z ogromnej swobody programowania jaką daje język
C++. Jeśli, szczególnie mniej doświadczony, programista dostanie wiele
swobody, to niewykluczone że użyje jej przeciwko bezpieczeństwu systemu.
W C++ np. nie ma obowiązku inicjowania zmiennych przy deklaracji, a domyślnie
są inicjowane tylko w określonych sytuacjach. Jeśli ktoś w krytycznych
systemach zbagatelizuje ten problem, uzna np. że jego kod jest na tyle
dobry, że nie będzie odczytów przed inicjacją, to cóż... można przenieść
rozmowę na grunt czy to wina programisty, czy języka, narzędzi i bibliotek.
Moim zdaniem to wina programisty, a kompilatory w C++ dają sporo ostrzeżeń
przy ryzykownych konstrukcjach.

Nie chce mi się dalej ciągnąć, bo autor nie powiedział co jest takiego
złego w C++.

Pozdrawiam

do góry

On Fri, 06 Sep 2019 03:06:02 -0700, M.M. wrote:
> Oczywiście C++ ma wady, ale te wady wynikają ani z języka, ani z
> narzędzi, ani z bibliotek, lecz z ogromnej swobody programowania jaką
> daje język C++. Jeśli, szczególnie mniej doświadczony, programista
> dostanie wiele swobody, to niewykluczone że użyje jej przeciwko
> bezpieczeństwu systemu.

W zupełności się zgadzam, dodam od siebie tylko to: język C++ rośnie cały
czas. To bogactwo językowe, postrzegane przez wielu jako zaleta,
faktycznie pozwala w wielu przypadkach nieco ułatwić pracę. Problem w
tym, że w praktyce mało który programista panuje nad całością języka -
pewnych rzeczy nie wie, albo myśli że wie i kod działa mu z przypadku,
albo kiedyś wiedział ale zapomniał bo mało używał. No i oczywiście zbiór
wiadomości które programista A posiada, mało kiedy nakłada się na to, co
wie programista B. W jakiejkolwiek pracy zespołowej to może szybko być
poważnym problemem, bo zamiast rozwiązywać biznesowe problemy,
programiści głowią się nad tym, "co kolega miał na myśli".

To jest główny powód, dla którego ja sam staram ograniczać się do C89.
Czasem zdarzy mi się sięgnąć po C99 albo jakieś rozszerzenie GNU, ale
bardzo niechętnie i wyłącznie w przypadkach kiedy w oczywisty sposób
pozwoli to ograniczyć koszty.

Oczywiście można spierać się, czy taki ogranicznik jest rolą języka, czy
może reguł projektowych, czy też innych wewnętrznych dyrektyw.

> W C++ np. nie ma obowiązku inicjowania zmiennych przy deklaracji, a
> domyślnie są inicjowane tylko w określonych sytuacjach. Jeśli ktoś w
> krytycznych systemach zbagatelizuje ten problem, uzna np. że jego kod
> jest na tyle dobry, że nie będzie odczytów przed inicjacją, to cóż...

Akurat ten przykład jest może nie do końca trafiony, bo błąd o którym
piszesz zostanie wykryty przez każdą statyczną analizę (nie potrzeba
nawet do tego specjalnego analizatora - zarówno gcc jak i clang
ostrzegają o tym). No chyba, że ktoś kompiluje bez żadnej diagnostyki...
No ale to już mówimy o ostro patologicznych przypadkach.

Wracając do tematu bezpieczeństwa C/C++, to z pewnością istnieją znacznie
bezpieczniejsze języki (np. w PHP ciężko wykonać SEGFAULT...). Problem w
tym, że ktoś piszący w C/C++ z reguły poszukuje nie tylko rozwiązania
danego problemu, ale oczekuje także osiągów - gdyby liczyło się wyłącznie
"bezpieczeństwo", to pisalibyśmy w jakiejś ewolucji QuickBasica :)
Jeśli wymagamy by nasz kod działał możliwie najszybciej, to trzeba godzić
się z tym, że pracujemy niejako na otwartym sercu. Jedyne co możemy
zrobić, to starać się hamować "kreatywność" młodych programistów i
ograniczać kod aby był jak najłatwiejszy do zrozumienia dla każdego, a
wynik intensywnie testować.

Mateusz
--
"There are only two kinds of programming languages: those people always
bitch about and those nobody uses." -- Bjarne Stroustrup

do góry

Wątek zaczął się od NASA, więc będę się trzymał tematu i zakładam, że chodzi o
naprawdę krytyczny soft a nie np. o przeglądarkę internetową, której "bezpieczeństwo"
ma inny wymiar.

> I, rzecz jasna, jaka jest
> alternatywa dla C++, bo jak C++ ma wady, a nie ma nic wyraźnie lepszego,
> to żadne argumenty mnie nie przekonają.

Otóż C++ ma prawie same wady (jest bardzo błędogenny) i prawie wszystkie odziedziczył
po C, ale *nie ma* nic wyraźnie lepszego.

Jest cała masa języków obiektywnie lepszych z punktu widzenia projektowania języków,
ale albo w ogóle nie mają szans w branży krytycznej z racji polegania na
nieweryfikowalnym run-time, albo nie wpływają na wysiłek weryfikacyjny, czyli na
ostateczny koszt projektu. Tzn. co z tego, że Ada jest lepsza od C, skoro klepanie
kodu to kilka procent wysiłku a pozostałe >90% to tyle samo roboczogodzin, bo one
wynikają z procesów a nie z wyboru takiego czy innego języka.

Przykładowo, co z tego, że Ada jest lepsza, skoro nie redukuje wysiłku potrzebnego na
uzyskanie 100% pokrycia testami. Testów do napisania będzie dokładnie tyle samo, co
do sztuki. Dlatego użycie Ady nic nie wnosi. To są tego typu argumenty.

> Warto zobaczyć ile błędów było w różnych kompilatorach w różnych językach.

To akurat nie ma znaczenia. Kompilator może sobie mieć bugi, bo i tak weryfikuje się
kod wykonywalny. Dlatego też jest mitem, że w branży krytycznej potrzebne są jakieś
"certyfikowane" kompilatory. Otóż nie są (niespodzianka!).

> Potem koszty, ciekawe ile kosztuje dobry programista w niszowym-dedykowanym
> języku?

To kolejny mit. Wszyscy programiści kosztują z grubsza tyle samo, bo ich koszt i tak
już dawno nie zależy od ich kompetencji. Albo wręcz dochodzi do takich lokalnych
anomalii rynkowych, że np. JavaScript kosztuje więcej, niż C++.
Większym problemem jest to, że programistów niszowych języków po prostu nie ma a nie
to, ile kosztują.

> Może dwóch programistów w C++ napisze bezpieczniejszy kod, niż
> jeden (za te same pieniądze) w niszowym-dedykowanym języku?

Nie. W obu przypadkach muszą napisać tak samo bezpieczny.

> Potem mnogość bibliotek.

Nie używa się bibliotek. Szkoda na to nerwów, znacznie szybciej jest napisać i
zweryfikować coś od zera samemu.

(przypominam, że do tego miejsca wątek był o systemach krytycznych)

Te wszystkie rozważania wyglądają zupełnie inaczej w "normalnym" programowaniu, gdzie
*najistotniejszy* jest dostęp do bogatego ekosystemu gotowych rozwiązań - biblioteki,
frameworki, itd. Na tym polu, w embedded wygrywa C/C++ i w zasadzie z niczym nie
konkuruje, na serwerach C++ konkuruje z Javą, na desktopie C++ konkuruje z .NETem i
Javą, w przeglądarce króluje JavaScript a w zastosowaniach specjalistycznych i
okołonaukowych (wliczając w to jakiś data science, AI i takie tam) na przód wybiega
Python, który w jakimś stopniu jest też obecny wszędzie indziej jako scyzoryk do
wszystkiego i niczego. Pozostałe języki to albo zamknięte technicznie i nieużyteczne
w inny sposób ekosystemy (SQL, MATLAB, itd.) albo po prostu domena hobbystów.
Szczerze - *wszystko* jest do bani. Ale podobnie jest we wszystkich innych
dziedzinach życia (muzyka, film, jedzenie, itd.), więc chyba tak po prostu mamy jako
cywilizacja.
I tak z grubsza to wygląda. Chyba że komuś wygląda inaczej, chętnie zobaczę.

--
Maciej Sobczak * http://www.inspirel.com

do góry

On Fri, 06 Sep 2019 06:42:36 -0700, Maciej Sobczak wrote:
>> Warto zobaczyć ile błędów było w różnych kompilatorach w różnych
>> językach.
>
> To akurat nie ma znaczenia. Kompilator może sobie mieć bugi, bo i tak
> weryfikuje się kod wykonywalny. Dlatego też jest mitem, że w branży
> krytycznej potrzebne są jakieś "certyfikowane" kompilatory. Otóż nie są
> (niespodzianka!).

Oj ale to chyba nieco naiwne - że niby przetestowanie wynikowego kodu
zagwarantuje brak bugów. Nie zagwarantuje, bo nie ma opcji by dało się
przetestować wynikowy program w 100% (wliczając w to np. ładowanie
relokowalnego kodu pod najróżniejsze adresy, coby wykryć jakiś egzotyczny
bug kompilatora). To nie znaczy oczywiście, że nie należy do tego dążyć,
jeśli ekonomia projektu na to pozwala.

> To kolejny mit. Wszyscy programiści kosztują z grubsza tyle samo, bo ich
> koszt i tak już dawno nie zależy od ich kompetencji.

Ja tam jednak obserwuję duże różnice w zależności od języka. Im więcej
towaru na rynku, tym bardziej jego wartość spada.

> Nie używa się bibliotek. Szkoda na to nerwów, znacznie szybciej jest
> napisać i zweryfikować coś od zera samemu.

Wliczając w to libc? Co do zasady, że lepiej samemu wyrzeźbić aby
wpasowało się idealnie w dany projekt to się zgodzę, ale to tylko
generalna zasada, i jak zawsze istnieje milion wyjątków. "nie używa się"
uważam za nieco zbyt kategoryczny obraz...

> Szczerze - *wszystko* jest do bani. Ale podobnie jest we wszystkich
> innych dziedzinach życia (muzyka, film, jedzenie, itd.), więc chyba tak
> po prostu mamy jako cywilizacja.

I to faktycznie ma sens :)
"kiedyś było lepiej"

Mateusz

do góry

On 2019-09-06 10:33, Mateusz Viste wrote:
> On Fri, 06 Sep 2019 01:12:39 -0700, M.M. wrote:
>> A uzasadnienia i tak i tak nie będzie.
>
> AK to mistrz krytyki, ale na tym jego talent zdaje się kończyć... nie
> widziałem by kiedykolwiek sam cokolwiek mądrego napisał.

Piszę same mądre (czyli prawdziwe) rzeczy :).
Nie moja wina, że głupcy ich nie dostrzegają.

AK

do góry

On 2019-09-06 10:12, M.M. wrote:
>> AK
>
> A uzasadnienia i tak i tak nie będzie.

Gadał stary do ślepego....
<cycat>Tak. Ten kapłan zwie się Standard Języka C.<cycat/>

Tera juz ślepy widzi czy trzeba wieksza czcionka?
_To są asercje_ w C, a nie "domowe robotki na drutach" jakiegos
fanatycznego Lispiarza..

Paniał juz? Czy dla slepego to wystarczajace uzasadnienie?

AK

do góry

On Friday, September 6, 2019 at 5:12:00 PM UTC+2, AK wrote:
> On 2019-09-06 10:12, M.M. wrote:
> >> AK
> >
> > A uzasadnienia i tak i tak nie będzie.
>
> Gadał stary do ślepego....
> <cycat>Tak. Ten kapłan zwie się Standard Języka C.<cycat/>
>
> Tera juz ślepy widzi czy trzeba wieksza czcionka?
> _To są asercje_ w C, a nie "domowe robotki na drutach" jakiegos
> fanatycznego Lispiarza..
>
> Paniał juz? Czy dla slepego to wystarczajace uzasadnienie?
>

Nie, nie zrozumiałem. Rozwiń jeśli możesz.
Pozdrawiam

do góry

W dniu środa, 4 września 2019 23:49:50 UTC+2 użytkownik Maciej Sobczak napisał:
> > Asercje są formą komentarza, który dodatkowo można zweryfikować.
>
> Kupa różnych narzędzi weryfikuje adnotacje zaszyte w komentarzach. Statycznie. I
tak powinno być.

Dlaczego? Bo właśnie do tego służą komentarze?
Jeżeli tak jest, to to wynika co najwyżej z tego, że macierzysty język jest zbyt
słaby, żeby wyrazić te rzeczy, które są istotne (i które weryfikują narzędzia, o
których mówisz). I dlatego używa się komentarzy jako takiego "haka" na wyrażanie tych
rzeczy.
Bo, jak wskazuje nazwa, komentarze służą do komentowania.

A do stwierdzania faktów służą... stwierdzenia.
(Możesz też poszukać synonimów tego słowa. Wśród nich znajdziesz ...)

> > Asercja to postawa propozycjonalna.
>
> Możliwe, że pomyliłeś grupy.

Hmm. Nazwa grupy zaczyna się od "pl". Jestem raczej przekonany, że to skrót od
"polski" i że sugeruje, że używamy tu znaczeń słów takich, jakie mają w języku
polskim.

Słowo "asercja" można nawet znaleźć w Słowniku Języka Polskiego, jeśli komuś chce się
szukać.

> > Możesz sobie napisać
> > #define assert(x) do {} while(0)
>
> Nie, nie mogę. Zabrania tego zarówno MISRA-C jak i AUTOSAR.
> Byłoby łatwiej, gdybyś nie spekulował.

Zabawne to, co mówisz. Zamiast powiedzieć, na przykład:

"nie mogę, bo MISRA C zabrania używania identyfikatorów, które pojawiają się w
bibliotece standardowej języka C"

wolisz powiedzieć:

"byłoby łatwiej, gdybyś nie spekulował"

Jakby to faktycznie mogło przybliżyć do rozwiązania jakiegokolwiek problemu.

I otóż, jak napisał powyżej kolega, który przedstawił mi się jako "Pier..lisz
Głupoty" (śmieszne nazwisko, swoją drogą), możesz zdefiniować symbol NDEBUG przed
załączeniem assert.h.

Albo możesz np. zdefiniować

#define certainly(x) do{}while(0)

Wyjdzie w sumie na to samo.

> > Asercje też są istotne dla czytelności.
>
> Oczywiście. Ale stanowią dead-code, którego się unika z innych powodów.

Asercje nie stanowią martwego kodu.
Być może strategia obsługi fałszywych asercji, którą przyjmuje biblioteka C (bez
NDEBUG) generuje w jakichś okolicznościach martwy kod.

> Być może te powody nie są istotne jak się pisze coś innego gdzieś indziej, ale
jeśli mówimy o systemach krytycznych (taki wątek się zrobił), to obowiązują pewne
reguły. Dużo reguł. Więcej, niż gdzie indziej. W sumie właśnie od tego spostrzeżenia
się ta dyskusja wzięła.
>
> > Asercja nie jest pojęciem wprowadzonym przez standard C.
>
> Standard C definiuje dokładnie, co to pojęcie oznacza w języku C. Może gdzieś
indziej oznacza coś innego, albo nawet wcześniej. Nie ma to znaczenia.

Standard C mówi wyłącznie, w jaki sposób jest zdefiniowane makro "assert".
Nie mówi nic o tym, co oznacza słowo "asercja".

> > > Oczywiście możesz sobie wyobrazić (albo nawet mieć) narzędzie, któro statycznie
skanuje kod i sprawdza asercje (efektywnie traktując je jako static_assert), ale
takie narzędzie potrafi też wyłuskać adnotacje z komentarzy.
> >
> > ?
>
> Ale czego nie rozumiesz? Której części?

Dajmy na to, że mam taki komentarz:

/* wartośc poniższego enuma służą jako indeksy do tablicy TABLICA */

po którym następuje enum.

I teraz, czy narzędzie sprawdzi mi, czy wartości tego enuma służą jako indeksy do
tablicy TABLICA?

> > No to nie dość, że sam błędnie rozumiesz, to jeszcze próbujesz to swoje błędne
rozumienie promować.
>
> Dopóki moje rozumienie opiera się na standardach (i to kilku), to będę je promował.
Nie do mnie pretensje, nie ja te standardy pisałem.

Nie wiem, jakie standardy czytałeś, ale jeżeli idzie o te, z którymi ja miałem
styczność, to żadna nie rościła sobie pretensji do bycia normatywną w kwestii pojęcia
asercji.

do góry

W dniu piątek, 6 września 2019 07:31:09 UTC+2 użytkownik AK napisał:

>
> >>>> Naprawde w C/C++ wystarczy, ze skompilujesz bez (N)DEBUG-a :(
> >>>
> >>> Można z -DNDEBUG, jak się bierze asercje z "assert.h".
> >>> Ja zazwyczaj nie biorę,
> >>
> >> To nie pierdziel juz wiecej o assercjach w C.
> >> Asercje w C bierze sie _tylko i wylacznie_ z assert.h
> >> Twoje prywatne "robotki domowe"to nie asercje w C.
> >
> > A co sprawia, że te z assert.h to "prawdziwe asercje", a te "moje prywatne
robótki domowe" - "nieprawdziwe"?
> >
> > Jakieś namaszczenie wysokiego kapłana?
>
> Tak. Ten kapłan zwie się Standard Języka C.

A jeżeli ktoś zdefiniuje sobie, dajmy na to, w C89, makro do statycznych asercji,
takie np. jak sugeruje ten gość:
https://stackoverflow.com/a/3385694
czyli dla tych, którym nie chce się klikać
#define STATIC_ASSERT(COND,MSG) typedef char static_assertion_##MSG[(COND)?1:-1]

i będzie używał tego makra do wyrażania różnych zależności, które zakłada, że muszą
być spełnione w swoim programie, np.

STATIC_ASSERT(sizeof(mytype) <= sizeof(int), mytype_fits_machine_word)

to czy to są prawdziwe asercje, czy nieprawdziwe?

Czy Standard Języka C powinien nałożyć ekskomunikę na tego gościa?

> >>> To jednak nie zmienia istoty tego, czym jest asercja.
> >>
> >> Pieprzysz 3po3.
> >
> > ?
>
> Pier..lisz głupoty.

To Twoje prawdziwe imię i nazwisko, czy tylko ksywka?

Ale dobrze, jeśli sobie życzysz, mogę tak do Ciebie mówić, Pierdoliszu.

Nawet ładnie to brzmi.

Ciekaw tylko jestem, jak się odmienia nazwisko.

"Wdałem się w dyskusję z Pierdoliszem Głupotym"? Hmm

do góry