On 06/10/2019 23:21, Maciej Sobczak wrote:
>> Bardzo prosta. Twój kompilator w poprawnej funkcji dodawania przypadkiem
>> zrobił mnożenie kiedy x=15 i y=90.
> To wychodzi w pokryciu kodu obiektowego.

Najpierw musisz znaleźć metodę testowania która zawiera dostatecznie
dużo przypadków.

>> Shit happens.
> Nie, nie happens.

Ależ happens. Na ten przykład popularną metodą testowania kodu
krytycznego, ale naprawdę krytycznego, jest psucie go w czasie
rzeczywistym i patrzenie gdzie i co wybuchnie analizując czy jest czy
nie podatny na uszkodzenia.

Nawet krzemowi się nie wierzy.

> Tzn. może są firmy, gdzie happens i się nie bada pokrycia (tak, tak, teraz ja sobie
dorabiam, dla równowagi do Twoich teorii, że w Ariane 5 nie było testów), ale tam
gdzie widzę, bada się i nie happens.

No ale jednak happens. Jesli nie to masz kompilator zewryfikowany
funkcjonalnie. Nie język, kompilator. Gratuluje.

W HDL jest jeszcze ciekawiej: co prawda można testować kod ale podczas
syntezy zamienia się on w graść tranzysotrów i tak ląduje w krzemie. Tam
jest dopiero zabawnie bo metody testowania software nie chcą pasować.

>> Czasem to tylko mignie
>> szybciej diodą a czasem wyśle samolot w kierunku gruntowym.
> Nie było przypadku, żeby samolot poleciał w kierunku gruntowym przez to, że użyto
jednego kompilatora a nie trzech.

Inaczej: akurat w tej branży testuje się kilkoma innymi metodami
również. Albo inaczej: z faktu że internet działa nie wynika że admini
są zbędni.

> Dlatego ten pomysł byłby potraktowany jako koszt bez wartości dodanej.

Nie "byłby" tylko jest stosowany. Może bardziej w HDLu ale w normalnym
programowaniu też.

>> A kod działa przypadkiem tylko dlatego że kompilator w jakimś miejscu
>> zamiast referencji użył wartości. W kodzie produkcyjnym użyje referencji
> Zaraz, zaraz... Testowałeś nieprodukcyjny kod a produkcyjny były jakiś inny?

Kod źródłowy ten sam. Kod wynikowy już niekoniecznie. Kompilator to jest
dość nietrywialny produkt.

> Tyle mądrości na temat weryfikacji a tu taki klops. Skup się.

No właśnie skup się, potwierdzenie kodu źródłowego, nawet metodami
formalnymi, nie oznacza że wynikowy jest poprawny. Potwierdzenie kodu
wynikowego unittestami czy innymi testami nie odpowiada na pytanie czy
będzie poprawnie się zachowywał na produkcji, to tylko przybliżenie do
ideału.

>> Aby zweryfikować narzędzia do weryfikacji.
> O, tu, widzisz, poruszyłeś ciekawe zagadnienie.
> Ale kwalifikację narzędzia robi się przed projektem, bo projekt zaczyna się mając
już zatwierdzone narzędzia.

Różnie bywa. Taka ciekawostka: weryfikację narzędzia robi się czasem na
słowo honoru: "działa od dziesięciu lat i nie ma problemu". Serio mówie.
Zarządzanie ryzykiem z braku środków pewnych opiera się o statystykę i
szczęście.

> I jeśli do tej kwalifikacji chcesz sobie użyć materiału testowego pochodzącego z
różnych kompilatorów, to właściwie może to mieć sens (ale nie musi).

Musisz zagwarantować że twój pewny kompilator jest pewny dla kodu
którego jeszcze nie ma. Dasz radę to udowodnić na etapie wyobu
narzędzia? Niektórzy stosują dupchrony w postaci wybierania narzędzi
certyfikowanych. Ale certyfikacja to nie jest brak bugów. To jest tylko
takie zapewnienie że tamci się też starali.

> Tylko że nadal nie ma sensu używać więcej niż jednego kompilatora do robienia tego
właściwego projektu.

Do robienia nie. Do weryfikacji musisz użyć środków adekwatnych do
ryzyka zdefiniowanego w planie. To może oznaczać np. rozbieranie na
pojedyncze bramki CPU na którym ten kod będzie działać aby wykluczyć
wątpliwości czy hardware jest pewne. Nie, nie wyssałem tego z palca.

>> Jest narzędziem które odpowiada na pytanie czy kod działa czy nie.>
> Kompilator? Nie, nie odpowiada na takie pytanie.

Oczywiśćie że odpowiada. Jesli masz tak w wyniku błedu kompialtora:

bool runUnitTesting()
{
return true;
....
}

To własnie wylądowałeś w dupie. Twój kompilator stwierdził że coś jest
okay choć nie jest.

> Właściwie to mogłoby nie być żadnego kompilatora, można posadzić człowieka z
zapasem kawy i herbatników i niech "kompiluje". I to nawet nie jest fikcja.

Tylko że to nie działa w praktyce ponieważ dodałeś dodatkową wartwę
błedów. Ktoś o nią zapyta.

>> Czasami odpowiada źle.
> Nie pokazałeś niczego takiego.

Mam masę uni testów które przechodzą mimo błednego kodu. Tylko dlatego
że urawło referencję ale obiekt dalej ma dobre dane, wyskoczyłem poza
tablicę a tam akurat dobre 0 itd itp. Mówie o błedach *KOMPILATORA* a
nie kodu. Fakt, to gówniany C++ ale nie zmienia to koncpecji ogólnej.
Testy nie mówią czy kod jest poprawny. Co najwyżej mówią że kod pod
testami daje spodziewane wyniki.

>> Nie. Wykazałeś że w jakiś warunkach Twój kod działa. A czy to te same
>> warunki kiedy będzie używany produkcyjnie?
> I w jaki sposób trzy kompilatory mają coś tu zmienić?

Zwiększają asymptotycznie pewność kodu. Kiedy w końcu coś spadnie z
białkiem w środku zapytają: a czy użyliście wszystkich osiąglanych metod
weryfikacji poprawniści kodu a jeśli nie to dlaczego? A ty im będziesz
bredził że postawiłeś kogoś z herbatnikami i kompilował na kartce bo to
żadna różnica skoro kod poprawny. BO TAK BYŁO W SPECYFIKACJI.

> Ilość kompilatorów wpływa na to, jak bardzo zmieniają się warunki w użyciu
produkcyjnym?

Pozwalają zminimalizować nieszczęscie związane z błedami w kompilatorze
lub z UB, z tym drugim nawet bardziej.

>> 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.
> Wszystko się zgadza.
> Ale nie ma tu ani słowa o użyciu wielu kompilatorów.

Symulator. HDL. Niczym to się nie różni od kompilatora "normalnego", też
kompilator i w dodatku Ady + pierdoły.

> I jeśli jesteśmy w temacie samolotów i smutnych panów - standardy lotnicze są tak
napisane, że użycie wielu kompilatorów do kompilowania tego samego kodu w projekcie
nie jest podstawą do dodatkowego uznania (tzw. certification credit) w czasie audytu
certyfikacyjnego a weryfikacji kodu wynikowego nie robi się garścią kompilatorów, bo
kod ma być jeden. Ten sam w testach, co na produkcji.

To jest to samo źródło, ale nie ten sam kod który będzie pracował na
testach. Kompilatory nie są proste, a już na pewno nie są pewne. Dlatego
robi się corss-checki na róznych. Wiesz, ja piszę głównie o EDA i
głównie o HDL gdzie tego typu zabawy to codzienność.

Uzycie kilku narzędzi zwiększa pewność weryfikacji. Kila firm solidnie w
ostatnich latach robiło w gacie i kupiło (bardzo) drogie narzędzia
testując wszystko na wszystkim. "Dla pewności".

> Dlatego ten pomysł nie ma zastosowania w projektach krytycznych, w szczególności w
lotniczych. Prawie byłeś blisko w temacie
> kwalifikacji narzędzi (np. narzędzie do badania pokrycia kodu testami można
próbować kwalifikować przy użyciu materiału testowego z jakiegoś zestawu
kompilatorów, ale to i tak niewiele wnosi w konteście danego projektu, gdzie jest
jeden kompilator), ale generalnie mylisz pojęcia.

Albo z miejsca gdzie siedzę widać coś innego niż z Twojego. Siedzimy
gdzie indziej.

> No i fajnie, że znasz "człowieka pracujacego dla poważnej instytucji związanej z
lotnictwem".

Nie, to nie jest fajnie. Dowiadujesz się raczej jak ciężko pracuje się
nad trudnymi projektami. Na ten przykład dokumentowanie kodu trwa
znacząco dłużej niż jego pisanie. Trudno mieć pretensje ale nie każdy by
potrafił.

>> PS. A zupałnie na marginesie wszelkiej certyfikacji. Odpalam mój kod pod
>> trzema kompilatorami.
> Ja też - wtedy, gdy piszę biblioteki.
> Ale w projekcie krytycznym używa się jednego kompilatora. I testuje się kod
produkcyjny.

Super. Być może certyfikujesz używając róznych innych metod weryfikacji.
Nikt nie naciska na kilka kompilatorów. Ale kilku wielkich graczy
zdecydowało się na to. Widzisz, lista bugów w kompilatorach jest długa i
raczej nie zamknięta. W tych certyfikowanych też.