On Friday, September 6, 2019 at 7:14:31 PM UTC+2, ...@...c wrote:
> 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?

Są to prawdziwe asercje, ładne, standard nie powinien nałożyć ekskomuniki, bo
są zgodne ze standardem, można dorzucić dwa oczywiste fakty:
1) Pisanie czegoś samemu jest bardziej ryzykowne niż używanie
dobrze przetestowanych bibliotek.
2) Taki prosty asert (bez pisania czegoś samemu) z biblioteki ma za mało
funkcjonalności do której się przyzwyczaiłem.

Więc niech każdy, zgodnie z ideą elastyczności C++, wybierze co dla niego
lepsze. Albo używaj skąpych gotowców, albo zaryzykuj napisanie bardziej
rozbudowanych asercji.

Pozdrawiam

do góry

> Oj ale to chyba nieco naiwne - że niby przetestowanie wynikowego kodu
> zagwarantuje brak bugów.

Nie zagwarantuje, tylko potwierdzi. Bo niby jak inaczej?

> Nie zagwarantuje, bo nie ma opcji by dało się
> przetestować wynikowy program w 100%

Witamy w branży systemów krytycznych. To nie jest opcja, tylko poziom oczekiwany.
I dlaczego miałoby się nie dać?

> (wliczając w to np. ładowanie
> relokowalnego kodu

Nie ma relokowalnego kodu. Właśnie dlatego.

> To nie znaczy oczywiście, że nie należy do tego dążyć,
> jeśli ekonomia projektu na to pozwala.

Ekonomia jest taka, że ma być 100%.

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

Ale to nie zależy od niszowości języka, tylko od podaży i popytu. Jeżeli język X jest
niszowy, to i tak jedyny programista w Polsce będzie tanim hobbystą, jeśli będzie dla
niego 0 projektów. Niszowość mu nie pomoże.
Problemem na rynku pracy jest brak programistów w ogóle a nie to, czy coś jest
niszowe, czy nie.

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

Tak. W sumie i tak nie ma tam nic ciekawego z punktu widzenia jakiegokolwiek systemu
krytycznego.

> "nie używa się"
> uważam za nieco zbyt kategoryczny obraz...

Nie używa się, bo obcy (!) kod jest bardziej kosztowny w weryfikacji, niż własny.
Obowiązek zapewnienia 100% pokrycia istnieje dla *całego* kodu a nie tylko dla
jakiegoś drobnego kawałka, który napisałeś sam, a pokrywanie kodu jakiejś obcej
biblioteki albo wykazywanie jej zgodności z wymaganiami projektu to jest coś, czego
nikt nie chciałby robić.

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

do góry

On Fri, 06 Sep 2019 12:03:02 -0700, Maciej Sobczak wrote:
> Obowiązek zapewnienia 100% pokrycia istnieje dla *całego*
> kodu a nie tylko dla jakiegoś drobnego kawałka, który napisałeś sam, a
> pokrywanie kodu jakiejś obcej biblioteki albo wykazywanie jej zgodności
> z wymaganiami projektu to jest coś, czego nikt nie chciałby robić.

W tym momencie zdałem sobie sprawę, że myślimy o całkiem innych rzeczach
- tzn. ty piszesz o tworze dużo bardziej ekstremalnym niż założyłem (co
jest zupełnie zgodne z pierwotnym tematem "NASA").

No i faktycznie - jeśli przyjąć, że piszemy logikę kontrolera stacji
orbitalnej Jowisza, to "normalne" programowanie odpada. Zostaje pisanie
pod "bare metal", gdzie program musi być wrzucony pod ściśle określony
adres, każda zmienna ma ściśle określone miejsce w pamięci, a sam program
jest sprawdzony za pomocą wszystkich możliwych kombinacji danych.

Mateusz

do góry

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

Powinno być statycznie.
Natomiast komentarze pozwalają "rozszerzyć" język bez ingerowania w kompilator.

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

Tak. Tak właśnie jest.
Język C jest słaby, więc używa się jego rozszerzeń w komentarzach, żeby wesprzeć jego
weryfikację. Zaletą takiego działania jest transparentność względem kompilatora.

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

Ale dryfujesz. Napisałem już kilka razy, dlaczego asercji się nie używa a Ty
grzebiesz w SJP, żeby... no właśnie nie wiem po co.

> możesz zdefiniować symbol NDEBUG przed załączeniem assert.h.

I w czym mi to pomoże?
Kod, który załaduję na produkcyjne urządzenie musi być *tym samym* kodem, który
przetestowałem, co do bitu. Nie ma opcji, żebym zrobił inaczej. Więc ten NDEBUG
musiałbym mieć zdefiniowany również w czasie testów.
To na cholerę mi takie asercje?

> Albo możesz np. zdefiniować
>
> #define certainly(x) do{}while(0)
>
> Wyjdzie w sumie na to samo.

Mógłbym. Ale po co miałbym definiować makro, któro nic nie robi?

> Asercje nie stanowią martwego kodu.

One są martwe z założenia. Nigdy się nie wykonują, więc są martwe.

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

Dalej nie kumasz. Asercji nie używa się, bo stoją w konflikcie z innymi celami
procesów krytycznych. Twoje własne asercje też takie będą, nawet jeśli je będziesz
pisał na podstawie SJP.

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

Jeśli masz takie narzędzie, to sprawdzi.
Czego tu nie rozumiesz?

Przewiń sobie tą stronę i popatrz na komentarze w przykładach:

https://frama-c.com/acsl_tutorial_index.html

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

Wniosek jest taki, że czytaliśmy różne standardy.

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

do góry

W dniu piątek, 6 września 2019 21:25:18 UTC+2 użytkownik Maciej Sobczak napisał:
> > > 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?
>
> Powinno być statycznie.
> Natomiast komentarze pozwalają "rozszerzyć" język bez ingerowania w kompilator.

Dla ścisłości, formalne wyrażenia zaszyte w komentarzach.
Czyli drugi 'język programowania'. Tylko pewnie z gorszym wsparciem narzędzi.

> > 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.
>
> Tak. Tak właśnie jest.
> Język C jest słaby, więc używa się jego rozszerzeń w komentarzach, żeby wesprzeć
jego weryfikację. Zaletą takiego działania jest transparentność względem kompilatora.
>
> > Słowo "asercja" można nawet znaleźć w Słowniku Języka Polskiego, jeśli komuś chce
się szukać.
>
> Ale dryfujesz. Napisałem już kilka razy, dlaczego asercji się nie używa a Ty
grzebiesz w SJP, żeby... no właśnie nie wiem po co.

No bo błędnie napisałeś.

> > możesz zdefiniować symbol NDEBUG przed załączeniem assert.h.
>
> I w czym mi to pomoże?
> Kod, który załaduję na produkcyjne urządzenie musi być *tym samym* kodem, który
przetestowałem, co do bitu. Nie ma opcji, żebym zrobił inaczej. Więc ten NDEBUG
musiałbym mieć zdefiniowany również w czasie testów.
> To na cholerę mi takie asercje?

Bo po pierwsze, możesz je inaczej interpretować poza swoim procesem.
Po drugie, możesz pewne rzeczy wyrazić w tym samym języku, w którym piszesz program.
Po trzecie, na cholerę Ci komentarze? Po czwarte, tak jak masz narzędzia, które
parsują formalny język w komentarzach, to mogłyby też tak samo parsować i statycznie
weryfikować asercje - bo czemu nie?

> > Albo możesz np. zdefiniować
> >
> > #define certainly(x) do{}while(0)
> >
> > Wyjdzie w sumie na to samo.
>
> Mógłbym. Ale po co miałbym definiować makro, któro nic nie robi?

Po co pisać komentarz, który nic nie robi?

> > Asercje nie stanowią martwego kodu.
>
> One są martwe z założenia. Nigdy się nie wykonują, więc są martwe.
>
> > 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".
>
> Dalej nie kumasz. Asercji nie używa się, bo stoją w konflikcie z innymi celami
procesów krytycznych. Twoje własne asercje też takie będą, nawet jeśli je będziesz
pisał na podstawie SJP.
>
> > 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?
>
> Jeśli masz takie narzędzie, to sprawdzi.

Nie mam takiego narzędzia.

> Czego tu nie rozumiesz?

Nie rozumiem w jaki sposób magiczne narzędzia mają nagle czytać moje komentarze ze
zrozumieniem. W komentarzach mogę pisać cokolwiek. Jak narzędzie mi sprawdzi, że nie
kłamię?

> Przewiń sobie tą stronę i popatrz na komentarze w przykładach:
>
> https://frama-c.com/acsl_tutorial_index.html

No to wygląda mi na takie rzeczy, które mogę wyrazić w asercjach.

> > 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.
>
> Wniosek jest taki, że czytaliśmy różne standardy.

No to dajesz cytaty.

do góry

W dniu piątek, 6 września 2019 20:28:58 UTC+2 użytkownik M.M. napisał:

> > 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?
>
> Są to prawdziwe asercje, ładne, standard nie powinien nałożyć ekskomuniki, bo
> są zgodne ze standardem,

Moje prywatne "domowe robótki" też są zgodne ze standardem - są napisane w C (czy
raczej makrach preprocesora).
Ale też uważam, że są ok.
Jednak interesuje mnie w tej kwestii zdanie Pierdolisza Głupotego, bo to on wydaje
się mieć jakieś obiekcje.

można dorzucić dwa oczywiste fakty:
> 1) Pisanie czegoś samemu jest bardziej ryzykowne niż używanie
> dobrze przetestowanych bibliotek.

No, przykłady mamy na każdym kroku - takie jak np. Heartbleed.

> 2) Taki prosty asert (bez pisania czegoś samemu) z biblioteki ma za mało
> funkcjonalności do której się przyzwyczaiłem.
>
> Więc niech każdy, zgodnie z ideą elastyczności C++, wybierze co dla niego
> lepsze. Albo używaj skąpych gotowców, albo zaryzykuj napisanie bardziej
> rozbudowanych asercji.

Jeżeli idzie o nagłówek assert.h, to myślę, że nawet jeśli by powierzyć jego analizę
Pierdoliszowi Głupotemu, to by sobie poradził.

do góry

W dniu piątek, 6 września 2019 17:06:15 UTC+2 użytkownik AK napisał:
> 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ą.

A może jednak Twoja, Pierdoliszu.
Może gdybyś był prawdziwie mądry, umiałbyś pisać swoje rzeczy w taki sposób, żeby ci
biedni głupcy potrafili ujrzeć blask Twej mądrości.

Może jestem głupcem, ale niestety nie umiem dostrzec w Twoich wypowiedziach niczego
więcej poza banalnymi płytkimi opiniami.

Opiniami, których nie raczysz uzasadnić nam, maluczkim, tylko serwujesz je ex
cathedra jak wyrocznia. Opiniami, których rzeczowości nie ma nawet jak sprawdzić.

A kiedy ja, kaleka umysłowy, próbuję sformułować myśl, to Ty, Pierdoliszu, zamiast
próbować ją jakoś zinterpretować, zamiast pomóc mi sformułować ją tak, żeby miała
sens dla nas obu, stwierdzasz, że "pieprzę 3po3", w czym mój pożałowania godny
zawistny umysł doszukuje się takiej ewentualności, że może dlatego wydaje Ci się, że
"pieprzę 3po3", że sam nie jesteś w stanie moich słów zinterpretować, i dlatego
wolisz je zdyskredytować.

do góry

On Friday, September 6, 2019 at 9:12:39 PM UTC+2, Mateusz Viste wrote:
> On Fri, 06 Sep 2019 12:03:02 -0700, Maciej Sobczak wrote:
> > Obowiązek zapewnienia 100% pokrycia istnieje dla *całego*
> > kodu a nie tylko dla jakiegoś drobnego kawałka, który napisałeś sam, a
> > pokrywanie kodu jakiejś obcej biblioteki albo wykazywanie jej zgodności
> > z wymaganiami projektu to jest coś, czego nikt nie chciałby robić.
>
> W tym momencie zdałem sobie sprawę, że myślimy o całkiem innych rzeczach
> - tzn. ty piszesz o tworze dużo bardziej ekstremalnym niż założyłem (co
> jest zupełnie zgodne z pierwotnym tematem "NASA").
>
> No i faktycznie - jeśli przyjąć, że piszemy logikę kontrolera stacji
> orbitalnej Jowisza, to "normalne" programowanie odpada.

Nie odpada. Oprogramowanie do kontroli stacji kosmicznej na której
miałoby przebywać choćby milion ludzi, też ma elementy bardziej i mniej
krytyczne. Błędy w tych mniej krytycznych czasami można skorygować w
trakcie działania. Ale 'jądro' takich systemów i niektóre jego
części faktycznie najlepiej zrobić od zera, obłożyć testami, dać
matematykom do analizy, itd...


> Zostaje pisanie
> pod "bare metal", gdzie program musi być wrzucony pod ściśle określony
> adres, każda zmienna ma ściśle określone miejsce w pamięci,

To ma zaletę i wadę. Po pierwsze jest zaleta, bo jeśli w fazie testów
zmienne były pod danym adresem, to i w fazie działania będą pod tym
samym adresem. Z drugiej strony jeśli kompilator do każdego testu
przetasuje adresy przed każdym uruchomieniem, to mogą wyjść ukryte
błędy.

> a sam program
> jest sprawdzony za pomocą wszystkich możliwych kombinacji danych.

Jeśli procedura działa 1 mikro-sekundę, i pobiera na wejście 32
bity danych, to czas uruchomienia dla wszystkich kombinacji zajmuje
ponad godzinę. Jeśli wyjście procedury zajmuje też 32 bity, to
do kompletnego sprawdzenia potrzebujemy plik o rozmiarze 16GB
który nie zawiera błędów. Dla procedury która trwa mili-sekundę i
pobiera 64 bity danych, taki proces uruchamiania trwa pół miliona
lat przy użyciu 1000 komputerów!

Z tego co słyszałem testuje się na wyrywki. Napisanie oprogramowanie
do sterowania rakietą zlecano ośmiu kompletnie niezależnym zespołom.
Każda wersja procedury jest uruchamiana na tych samych danych
wejściowych. Oczywiście to wszystko nie wystarcza, próbuje się 
udowodnić że kod nie ma błędów, a w trakcie działania jest robione
głosowanie, jeśli 7 wersji danej procedury dało odpowiedź 0, a jedna
odpowiedź 1, to używa się odpowiedzi 0, a ta procedura która dała
odpowiedź 1 dostaje mniejszą wagę w do obliczania 'średniej ważonej'.

Pozdrawiam

do góry

> Z tego co słyszałem testuje się na wyrywki.

Można, ale to słaba metoda. "Wyrywki" zakładają, że jakiś zbiór jest jednakowo czuły
w swoich różnych punktach, co właściwie nigdy nie jest prawdą. Dotyczy to dowolnej
konstrukcji inżynierskiej, nie tylko w programowaniu.
Dlatego testuje się równoważne klasy i ich brzegi. Jeśli np. coś ma zakres od 10 do
100, to zamiast zrobić 20 testów na wyrywki lepiej jest zrobić testy np. dla 9, 10,
11, 50, 99, 100, 101.

> Napisanie oprogramowanie
> do sterowania rakietą zlecano ośmiu kompletnie niezależnym zespołom.

Był kiedyś taki pomysł, ale odchodzi się od niego, bo okazało się, że problemem wcale
nie jest poprawność oprogramowania, tylko kompletność wymagań. Po co robić 8 tak samo
złych programów? Stosuje się oczywiście redundancję, ale po to, żeby uchronić się
przed zjawiskami sprzętowymi. Czyli zobaczysz np. dwa identyczne komputery z
*identycznym* oprogramowaniem (czyli jest 1 projekt a nie 8), ale umieszczone w
*różnych miejscach* rakiety albo samolotu i to np. pozwala rozwiązać problemy
powodowane przez przypadkowe promieniowanie albo zpełnie normalne awarie sprzętu.
Ale pomysł na różne wersje oprogramowania okazał się być nieużyteczny i niepotrzebnie
kosztowny.

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

do góry

> > Napisałem już kilka razy, dlaczego asercji się nie używa a Ty grzebiesz w SJP,
żeby... no właśnie nie wiem po co.
>
> No bo błędnie napisałeś.

W jakim sensie błędnie? W takim, że się ich używa?

> > To na cholerę mi takie asercje?
>
> Bo po pierwsze, możesz je inaczej interpretować poza swoim procesem.

Nie rozumiesz. Nie ma rzeczy poza moim procesem. I nawet nie chodzi o to, że nikt mi
za nie nie zapłaci. Chodzi wręcz o to, że ze względów zrozumiałych bardziej dla
prawników, niż inżynierów, rzeczy poza procesem są zabronione.

> Po co pisać komentarz, który nic nie robi?

Komentarz nie jest dead-codem. To właśnie ten aspekt sprawia, że asercji się nie
używa.

> > > I teraz, czy narzędzie sprawdzi mi, czy wartości tego enuma służą jako indeksy
do tablicy TABLICA?
> >
> > Jeśli masz takie narzędzie, to sprawdzi.
>
> Nie mam takiego narzędzia.

Spodziewałem się. Ale powinieneś rozumieć, że takie narzędzie można mieć. I ten fakt
sprawia, że z takimi argumentami oddalasz się od jakkolwiek rozumianego sukcesu w tej
dyskusji.

> W komentarzach mogę pisać cokolwiek.

Dalej nie rozumiesz. Za pisanie czegokolwiek wylatuje się z pracy.
Ale jak napiszesz coś mądrego, to co innego.

> Jak narzędzie mi sprawdzi, że nie kłamię?

Czyli nie zajrzałeś do tego linka, którego podałem do Frama-C. Szkoda.

> > https://frama-c.com/acsl_tutorial_index.html
>
> No to wygląda mi na takie rzeczy, które mogę wyrazić w asercjach.

Jednak zajrzałeś. Ale nie zrozumiałeś. Tych rzeczy nie da się wyrazić w asercjach
języka C - stąd pomysł na taki produkt. Ktoś tego nawet używa.
Być może w innym (hipotetycznym?) języku można by było to mieć w asercjach i bez
dodatkowego narzędzia, ale jakoś ten język nie robi furory w tej branży. Więc jest
tak, jak pokazałem.

> > Wniosek jest taki, że czytaliśmy różne standardy.
>
> No to dajesz cytaty.

Czyli nawet w tej warstwie nic nie rozumiesz.
Cytowanie tych standardów jest zabronione. Prawa autorskie i takie tam.

Mógłbym ewentualnie podać numer paragrafu, to jest dozwolone. Ale wtedy musiałbyś sam
sobie to otworzyć i przeczytać. No, ale skoro możesz sam otworzyć i przeczytać, to po
co mam dawać cytaty? Ctrl-F, "assert", Enter.

No i serio - o co teraz walczysz, tak konkretnie?

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

do góry