On 10/05/2019 08:03, Maciej Sobczak wrote:
>> Nie, tu padło jakieś hasło "C++ zachęca do pisania w stylu "write
>> once, debug endlessly"". Problem w tym że to jest walidne w każdym
>> języku a w c++ z roku na rok o dziwo coraz mniej.
> Tak. Oczywiście potrzeba, żeby programiści z roku na rok też robili postępy w tym,
jak korzystają z tego języka.

O tym piszę od początku jako elemencie niezbędnym obok bezpiecznego języka.

>>> Niezupełnie. W takich systemach może być wymaganie na pokrycie testami każdej
ścieżki.
>> Nie. W typowym systemie nie wymaga się pokrycia *każdej* ścieżki, wymaga
>> się pokrycia określonego procentu.
> Co to jest "typowy system"?

Taki który jest na tyle typowy że produkuje się do niego bardzo, ale to
bardzo drogie narzędzia do kontrolowania procesu produkcji. Zacznij od
pojęcia "test plan".

https://en.wikipedia.org/wiki/Test_plan

> Bo w konteście całej ludzkiej aktywności programistycznej, w ogóle wymaganie
weryfikacji czegokolwiek jest niszowe.

Jeśli to coś miga diodą to masz rację. Ale jak już steruje czymkolwiek
to przegapiłeś rewolucję. Nie wejdziesz na rynek aplikacji krytycznych
bez bardzo rozbudowanego mechanizmu weryfikacji który sam podlega
regorystycznej weryfikacji.

> A jak jesteśmy w niszach, to trudno mówić o "typowym systemie".

Typowy system critical safe. Nikt tu nie mówi o pisaniu migania diodą i
narzekania że wyjątki są do tego kiepskie.

> W niszach są standardy i procesy. Nie spotkałem wymagań w procentach pokrycia.

Poczytaj o testplanach w okolicy pojęcia IpCore i programowania hardware.

>> Ba, wymaga się pokrycia nie tylko
>> ściezki wykonywania kodu, ale np. zbioru wartości danych zmiennych.
> Też w procentach?

Tak. Np. ze wszystkich 2^32 adresów IP przetestowaliśmy 5% i wydają się
działać w duperelowatym kawałku kodu do migania diodą jak przyjdzie
pakiet broadcast.

>> Jeśli masz kilkaset tyś lini kodu to nie jest mozliwe pokrycie go w 100%
> No to może za dużo jest tych linii? Albo ktoś je napisał a dopiero potem
zorientował się, że warto by zrobić jakąś weryfikację. To niedobrze.

Nie, weryfikacja powstaje *zanim* napiszesz kod. Tylko że ludzie piszący
wymagania wiedzą że coś jest nierealne do osiągnięcia jak 100% pokrycia
itd itp. Zarządza się ryzykiem.

> Trochę się motasz. Przedsionek serca to system krytyczny. Miganie diodą też nim
może być, zależy co to za dioda.
> A jeśli masz system, w którym ktoś napisał kilkaset tyś. linii a potem się
zorientował, że nie może ich pokryć

Zorientował się przed napisaniem kodu. Oszacował ryzyko, w każdym
punkcie systemu inaczej. Ryzyko mikrokernela jest wysokie i tam stopień
pokrycia i wymagania co do jakosci są wyższe. Dla sterownika wentylatora
nie są tak wyśrubowane a do sterownika poświetlenia klawiatury są niskie.

>, to może jednak ten system od samego początku nie był tak bardzo krytyczny i tylko
ludzie sobie dodają fasonu twierdząc, że jest.

Nie dalej nie czaisz. Obecnie pisanie systemów krytycznych podlega pod
bardzo restrykcyjne zasady. W nich samego pisania jest mało, znacznie
więcej jest dokumentowania wymagań, śledzenia zmian, akceptacji,
odpowiedzialności itp itd tylko że w przeciwieństwie do banków tutaj
całosć procesu jest automatyzowana w miarę możliwości w całości.

>> Do testowania pokrycia stosuje się automatykę.
>> Ona widzi wyjątki tak samo jak logjmp.
> Nie. Nie widzi.
> Cytat ze standardu do F-35 (bo tam zaczęliśmy):
> "
> AV Rule 208:
> C++ exceptions shall not be used (i.e. throw, catch and try shall not be used.)
> Rationale: Tool support is not adequate at this time.

To trzeba zmienić tool.

> Problem w tym, że nadal jest "not adequate". I bardzo możliwe, że zawsze tak
będzie.

Mało porawdopodobne. Standardy tego typu powstają kiedy obecni
użytkownicy szczali jeszcze w pieluchy. Wystarczy zauważyć że w ciągu 10
lat projkekt LLVM z pomysłu stał się praktycznie kombajnem do
weryfikacji i to zaskakującej jakości jak na projekt "akademicki".

> Zmartwię Cię. Wymaganie pokrycia dotyczy kodu obiektowego a nie źródłowego. Na tym
poziome nie ma już wiedzy o tym, który kawałek kodu był generyczny a który nie.

I źródłowego, i wynikowego i każdego innego który ma wpływ na
bezpieczeństwo.

Przykładowo narzędzia do weryfikacji potrafią powiązać dowolną linijkę
kodu źródłowego z wymaganiem formalnym i śledzić zmiany.

>> Znowu Cie zmartwie: możesz pokryć tą generyczną funkcję testami w 100% a
>> i tak ktoś rzuci wyjątkiem
> Nie rzuci, bo jest zakaz. Właśnie po to.

Przypuszczam że Ariane miała zakaz przepełniania zmiennych. Nawet może
ktoś pogroził paluszkiem.

>> w przemyśle
>> nawet w aplikacjach do latania stosuje się śmiesze liczby w rodzaju 99%
> A dlaczego nie dało się pokryć tego brakującego 1%?

Bo wymaga to 99% czasu więcej? Szacujący ryzyko ocenia na ile chce mieć
system działający vs system w wiecznej fazie produkcji.

>> System w którym lata milion wyjątków jest do dupy. Ale narzekanie że
>> funkcja generyczna jest do dupy bo może przez nią przelecieć wyjątek
>> jest absurdalne.
> A kod obiektowy, w którym jest milion nieprzetestowanych rozgałęzień jest OK?

Ale co to ma wspólnego z fukcją generyczną?

Kod obiektowy w którym jest milion nieprzetestowancyh rozgałęzień ma
milion miejsc do poprawienia na weryfikacji. Zakasujesz rękawy i
pokrywasz albo masz w zespole człowieka który nie dopuści do takiego
dziadostwa. Ale spokojnie, autoamty do weryfikacji też nie odpuszczą a
na samym końcu ktoś się pod tym podpisuje i to jego złapią za jaja w
razie wypadku.