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