From Newsgroup: comp.lang.c++

[[This message is automatic translation (with my corrections) from
polish to english. Original message I wrote in polish and publish on the Usenet in groups pl.comp.lang.c and pl.comp.os.linux.programowanie.
Bellow of the translation I paste my original message it in the case you
want use better translator than https://translate.google.pl/ in future.]]

Dzień dobry!

Below is a response to the appeal of the author of C++ language Bjarne Stroustrup from Denmark, in which he calls on the C++ community to
defend this language. I learned about his appeal from an article on the
WWW page https://ithardware.pl/aktualnosci/tworca_c_jezyk_zagrozony_usa_rust-39456.html .

In my opinion, there is no "miracle method" to eliminate errors in
programming codes written by people. However, we can indicate ways to
detect and correct them.

The most important tools for a programmer that help in programming high-quality code are: technical specification and automated tests. In
my opinion, any problems with "buffer-overflow" attacks result either
from imprecise technical specification or from too weak automated tests.
And it has nothing to do with any language. Simply, sloppy programs
without their refinement will still be sloppy and full of holes. The
only thing that may be necessary is to extend the software documentation design and testing process. In order to give it high quality. All
formats and protocols used in the Internet should definitely be refined. Perhaps for automatic-testing, artificial intelligence should be used,
which would brute-force test: 1) typical functions values, 2) extreme
values ​​that are permissible, and 3) values ​​that are not permissible
in the technical specification.

I would not use artificial intelligence for designing network protocols
and data formats and for coding because it poses a risk of people losing
their competence in these areas.

In relation to the above article. text like, quote:

"Pressure from regulators
Regulatory changes are also important. The American CISA published a
report in October last year recommending that manufacturers have a plan
to eliminate memory gaps or switch to memory-safe languages ​​by January 1, 2026. Stroustrup considered this a "real threat" to C++.

The US government proposes the following languages:
Rust
Go
C#
Java
Swift
JavaScript
Ruby"

is nonsensical because only Rust and Go are programming languages ​​on this list, and the rest are scripting languages. Both groups of
languages ​​are incomparable and have different applications.

My final thought is that it looks like my earlier predictions, which I published in https://energokod.pl/komentarze-do-ksiazek/2025-01-19%20F-35%20-%20Zasady%20Kodownia%20-%20komentarz.pdf,
are accurate and that the SZAP/USONA government actually wants to
withdraw C++ from the civilian market and that they want to make it a
"black project". Because, contrary to the propaganda, SZAP/USONA is
launching new military projects based on the programs coded in C++ (see
the mention of rewriting the software of new versions of long-range
cruise missiles from ADA to C++. Nowa Technika Wojskowa, no. 11/2024
article "JASSM has more than one name, or AGM-158B-2, B-3, D and LRASM
and JASSM-XR", author Michał Gajzler).

We know this from the past: earlier it was like this, for example, with
the Plan9 ops system, which was created by the creators of the Unix ops system. The Plan9 ops system was brilliant and groundbreaking, but
abandoned. What was the next project of the creators of the UNIX ops
system? It remains a mystery without an answer. However, I know this:
the successor to the Plan9 ops system was one of the "black projects,"
and secret and forever.

Problems with negligent programs coded in C and C++ can become a pretext
for keeping the next versions of C and/or C++ in secret.

Miłego dnia!
--
Jacek Marcin Jaworski
Moja s. WWW to https://energokod.pl .
Mój pub. klucz GNU gpg to: EBFD1A464130993FBBC230FE221740E87CE10580 .
Tu jest instrukcja jak szyfrować listy el.: https://emailselfdefense.fsf.org/pl .

[[Below I paste polish version]]

Dzień dobry!

Poniżej odp. na apel autora j. C++ Bjarne Stroustrup z Danii, w którym
wzywa społeczność C++ do obrony tego j. prog. O jego apelu dowiedziałem się z art. na s. WWW https://ithardware.pl/aktualnosci/tworca_c_jezyk_zagrozony_usa_rust-39456.html .

Moim zdaniem nie ma "cudownego sposobu" na eliminację błędów w kodach prog. pisanych przez ludzi. Można za to wskazać sposoby ich wykrywania i poprawiania.

Najważniejszymi narzędziami programisty pomocnymi w prog. wysokiej
jakości kodu są: specyfikacja techniczna i testy automatyczne. Moim
zdaniem wszelkie problemy z atakami typu "buffer-overflow" wynikają albo
z nieprecyzyjnej specyfikacji technicznej, albo ze zbyt słabych testów
aut. I nie ma to związku z żadnym j. prog. Po prostu niedbałe prog. bez
ich dopracowania i tak będą niedbałe i dziurawe. Jedyne co może się okazać konieczne to wydłużenie procesu projektowania i testowania oprogramowania. Tak by nadać mu wysoką jakość. Na pewno należy dopracowywać wszelkie formaty i protokoły stosowane w sieci Internet.
Być może do testów aut. należało by używać sztucznej inteligencji, która
metodami siłowymi testowała by wart. typowe oraz w kol. etapach testów wart. skrajne jakie są dopuszczalne, a w kol. testach wart. które nie są dopuszczalne w specyfikacji technicznej.

Do projektowania protokołów sieciowych i formatów danych oraz do
kodowania nie używał bym sztucznej inteligencji z tego powodu, że to sprawia zagrożenie utraty przez ludzi kompetencji w tych dziedzinach.

W odniesieniu do pow. art. tekst taki jak, cytat:

"Presja ze strony regulatorów
Nie bez znaczenia są także zmiany regulacyjne. Amerykańska CISA opublikowała w październiku ubiegłego roku raport zalecający, by do 1 stycznia 2026 r. producenci mieli plan eliminacji luk pamięciowych lub przeszli na języki bezpieczne dla pamięci. Stroustrup uznał to za
"realne zagrożenie" dla C++.

Rząd USA proponuje następujące języki:
Rust
Go
C#
Java
Swift
JavaScript
Ruby"

jest nonsensowny z tego powodu, że na tej liście tylko Rust i Go są j. prog. a reszta to j. skryptowe. Obie grupy j. są nieporównywalne i mają inne zastosowania.

Moja końcowa myśl jest taka, że wygląda na to że trafne są moje wcześniejsze przewidywania, które opublikowałem w https://energokod.pl/komentarze-do-ksiazek/2025-01-19%20F-35%20-%20Zasady%20Kodownia%20-%20komentarz.pdf
i że faktycznie rząd SZAP/USONA chce wycofać z rynku cywilnego j. C++ i
że chcą zrobić z niego kol. "czarny proj.". Bo na przekór pow. propagandzie SZAP/USONA uruchamia kol. proj. militarne oparte o prog.
kodowane w j. C++ (patrz wzmiankę o przepisaniu z j. ADA na j. C++ oprogramowania nowych wer. rakiet samosterujących dalekiego zasięgu w
mieś. Nowa Technika Wojskowa, nr 11/2024 art. "JASSM niejedno ma imię,
czyli AGM-158B-2, B-3, D oraz LRASM i JASSM-XR", aut. Michała Gajzlera).
Znamy to z przeszłości: wcześniej tak było np. z sys. op. Plan9, który był stworzony przez twórców sys. op. Unix. Sys. op. Plan9 był genialny i przełomowy, jednak porzucony. Co było kol. proj. twórców sys. op. UNIX? Pozostaje tajemnicą bez odp. Jednak ja to wiem: następca sys. op. Plan9 należał do "czarnych proj." czyli tajnych i to na zawsze.
Problemy z niedbałymi prog. kodowanymi w j. C i C++ mogą stać się pretekstem do utajnienia kol. wer. tych j. prog.

Miłego dnia!
--
Jacek Marcin Jaworski
Moja s. WWW to https://energokod.pl .
Mój pub. klucz GNU gpg to: EBFD1A464130993FBBC230FE221740E87CE10580 .
Tu jest instrukcja jak szyfrować listy el.: https://emailselfdefense.fsf.org/pl .
--- Synchronet 3.20c-Linux NewsLink 1.2