On 05/10/2019 22:12, Maciej Sobczak wrote:
> No więc - skoro już poprawiliśmy tą naszą funkcję, to jaka jest wartość dodana z
użycia kilku kolejnych kompilatorów?

Bardzo prosta. Twój kompilator w poprawnej funkcji dodawania przypadkiem
zrobił mnożenie kiedy x=15 i y=90. Shit happens. Czasem to tylko mignie
szybciej diodą a czasem wyśle samolot w kierunku gruntowym.

> Bo tego cały czas nie pokazałeś.

No więc wyobraź sobie sytuację w któej unit testy posiadają
asymptotycznie pokrycie w 100% zgodne z testplanem.

A kod działa przypadkiem tylko dlatego że kompilator w jakimś miejscu
zamiast referencji użył wartości. W kodzie produkcyjnym użyje referencji
bo tak wyszło kompliatorowi. I wykryje buga na produkcji załączając
odwracacz ciągu w powietrzu.

Dodając dodatkowe narzędzia weryfikacyjne (tak, w tym wypadku kompilator
jest takim narzędziem) możesz zrealizować nastepne poziomy weryfikacji
kodu które wynikają z wymogów bezpieczeństwa. I może, dzięki szczęściu,
błąd wykryjesz. Bo w pewnym momencie niestety kończą się środki formalne
a zaczynają statystyczne.

> Wiemy tylko, że "w dużych firmach", czy jakoś tam. Ale tak konkretnie, po co?

Aby zweryfikować narzędzia do weryfikacji. Ponieważ nie potrafimy tego
robić formalnie ani pewnie, pozostaje weryfikacja statystyczna.
Najprościej poprzez użycie podobnych bądź identycznych narzędzi kilku
róznych firm w celu analizy różnicowej.

>> Kiedy już te i masę innych etapów weryfikacji przejdziezsz po drodze
>> ktos zapyta czy dajesz wiarę w kompilator.
> I tu jest cały trick. Kompilator nie jest celem ani centrum tego ćwiczenia.

Jest narzędziem które odpowiada na pytanie czy kod działa czy nie. Jesli
odpowie źle to możesz sobie całe to unit testowanie wsadzić w dupę.
Czasami odpowiada źle.

> Celem (i ostatecznym produktem) jest kod wynikowy - a jego poprawność właśnie
wykazaliśmy wszystkimi tymi metodami, o których wspomniałeś.

Nie. Wykazałeś że w jakiś warunkach Twój kod działa. A czy to te same
warunki kiedy będzie używany produkcyjnie?

Nie da się tego stwierdzić. Dlatego używa się croos-checków. To jest
BARDZO powszechna praktyka w symulacjach HDL i spotykana praktyka w
programowaniu tradycyjnym.

> Czyli mamy poprawny kod wynikowy.

Nie, testy tego nie wykazują. Testy wykazują że mamy poprawnie
działający kod pod testami. To może być wystarczające jeśli wymogi
bezpieczeństwa są przeciętne i może to być za mało jeśli są wysokie.

Może wyjaśnie na przykładzie. Znam człowieka pracujacego dla poważnej
instytucji związanej z lotnictwem. Aby ich kod przeszedł certyfikat
pozwalający na stosowanie w samolotach musieli, poza wykazaniem
testowania we wszystkich odmianach, zarządzania jakością, weryfikacji
formalnej również to czy zweryfikowali narzędzia. Ponieważ smutni
panowie od certyfikowania nie są z kosmosu i znają realia to zapytali w
ILU różnych symulatorach potwierdzono działanie kodu i czy ich
producenci sami są certyfikowani do użycia w takiej branży.

Z punktu widzenia przeciętnego misaczka programującego pierdoły to jest
bez sensu.

Z punktu widzenia dopuszczeń do zastosowań krytycznych jest kluczowe.
Zarządzanie ryzykiem może prowadzić do czasem pozornie absuralnych akcji.

> Więc po co kolejne kompilatory?

Aby metodami statystycznymi podnieść pewność że to co testujesz nie jest
związane z błędem kompilatora.

>> Istnieją ryzyka gdzie nie można zaufa kompilatorowi.
> Ależ ja mu ani przez chwilę nie ufałem. Ani przez mikrosekundę.
> Ale też nie on jest w centrum uwagi. Więc?

Ale to on napisał na koniec na ekranie "100% testów przeszło".

Możesz mu nie ufać. Cerytyfikator też nie będzie jesli ma się podpisać
pod czymś montowanym jako rozrusznik serca.

PS. A zupałnie na marginesie wszelkiej certyfikacji. Odpalam mój kod pod
trzema kompilatorami. clang, gcc i vc oraz dodatkowo okresowo pod
valgrindem. Codziennie, głównie w celu łownienia różnic składniowych, na
ciągłej integracji. Po kilka razy na co najmniej dwóch z nich. Zgadnij
ile bugów znalazło się w kodzie na jednym z nich który to kod wykazywał
brak błedów na innym? Nie, nie składniowych. 100% testów przeszło na
unit i integracji. A pod innym GPF. Życie.