Co sądzicie o zagrożeniu jakie niesie ze sobą swoboda w zarządzaniu pamięcia w C/C++ ?
I o rekomendowanych przez USA językach zamiennych:
-Rust
-Java
-C#
-JavaScript
-Go
-Swift
-Ruby
-Python
-Delphi/Object Pascal
-Ada
https://www.whitehouse.gov/oncd/briefing-room/2024/02/26/press-release-technical-report/
Proponuję wprowadzić licencję na zarządzanie pamięcią. Bez niej nie możesz programować w C i C++.
Co sądzicie o zagrożeniu jakie niesie ze sobą swoboda w zarządzaniu pamięcia w C/C++ ?
Sam fakt tej swobody jest zaletą, bo programista może w pełni kontrolować tworzenie i niszczenie obiektu, szczególnie, gdy to drugie to nie tylko zwolnienie pamięci, ale też wykonanie określonych czynności (procedura destruktora). Zawsze jest coś kosztem czegoś, czyli próba odwołania do przypadkowego miejsca, zgubienie wskaźnika i wielokrotne niszczenie tego samego wskaźnika.
W C trzeba pilnować jest to realizowane niskopoziomowo (tylko malloc, calloc, i free), ale w C++, po zastąpieniu zwykłych wskaźników inteligentnymi wskaźnikami od C++14, ryzyko popełniania podstawowych błędów jest wyeliminowane, a przynajmniej znacznie zmniejszone. Struktura takiego wskaźnika sama pilnuje, żeby obiekt zniknął wraz z ostatnim istniejącym wskaźnikiem.
W C, ryzyko nieprzewidzianego zwrotu akcji też jest mniejsze, bo nie ma rzucania i łapania wyjątków. Nieprzewidziane rzucenie wyjątku w C++ może spowodować zgubienie zwykłego wskaźnika.
andrzejlisek napisał(a):
Co sądzicie o zagrożeniu jakie niesie ze sobą swoboda w zarządzaniu pamięcia w C/C++ ?
Sam fakt tej swobody jest zaletą, bo programista może w pełni kontrolować tworzenie i niszczenie obiektu, szczególnie, gdy to drugie to nie tylko zwolnienie pamięci, ale też wykonanie określonych czynności (procedura destruktora). Zawsze jest coś kosztem czegoś, czyli próba odwołania do przypadkowego miejsca, zgubienie wskaźnika i wielokrotne niszczenie tego samego wskaźnika.
W C trzeba pilnować jest to realizowane niskopoziomowo (tylko malloc, calloc, i free), ale w C++, po zastąpieniu zwykłych wskaźników inteligentnymi wskaźnikami od C++14, ryzyko popełniania podstawowych błędów jest wyeliminowane, a przynajmniej znacznie zmniejszone. Struktura takiego wskaźnika sama pilnuje, żeby obiekt zniknął wraz z ostatnim istniejącym wskaźnikiem.
No jakby nie patrzeć najprostszym sposobem na wyeliminowanie jakiegoś ryzyka jakie niesie ze sobą dany język jest nie używanie go, jednakże koszty ryzyka jakie niesie ze sobą taka swoboda w alokacji pamięci, trzeba opłacać kompetentnymi programistami i architektami a zwraca się on niesamowitą wydajnością.
Powiem tak, ostatnio interesuję się trochę tematami security w C++ i to bardzo niebezpieczny język. Dokonać ataku hakerskiego można właściwie przez każde Undefined Behaviour, a sposobów na wywołanie go są setki. I część dość nieoczywista tak, że nawet niezły mid podczas review tego nie wyłapie.
C++ ma swoje niewątpliwe zalety, ale w dobie gdzie z roku na rok rośnie liczba ataków hakerskich oraz spowodowane w ten sposób straty firm dołączam do grupy, która uważa, że trzeba będzie zrezygnować z C++. Lubię ten język, ale statystycznie na milion linii kodu zawsze się trafi parę nieoczywistych błędów.
Ciekawe bo JVM, .NET, Python, Ruby i JavaScript są napisane w C lub C++...
Rust jest zbyt skomplikowany dla przeciętnego programisty, podobnie jak FP.
Ada to bardzo wąskie i specyficzny sektor zastosowań (awiacja / aeronautyka).
O Swift nie wiem nic poza tym że jest od Apple.
Delphi ma swoje lata i nie wiem w sumie co robi na tej liście bo tam też zarządza się pamięcią częściowo ręcznie (https://stackoverflow.com/questions/4440841/garbage-collection-in-delphi)
Pozostaje nam zwycięzca: język Go! (choć jego runtime zawiera wstawki w ASM).
Ciekawe bo JVM, .NET, Python, Ruby i JavaScript są napisane w C lub C++...
Java powoli zmierza do tego zeby miec zarowno kompilator jak vm napisane w javie. Polecam hasla Java graal i Java graalvm
Pythong na PyPy, ktory jest napisany w RPythonie, czyli statycznie typowanym podzbiorze Pythona
KamilAdam napisał(a):
Java powoli zmierza do tego zeby miec zarowno kompilator jak vm napisane w javie. Polecam hasla Java graal i Java graalvm
Czy to oznacza że pełna refleksja w końcu będzie możliwa aż do poziomu bajtkodu?
loza_prowizoryczna napisał(a):
KamilAdam napisał(a):
Java powoli zmierza do tego zeby miec zarowno kompilator jak vm napisane w javie. Polecam hasla Java graal i Java graalvm
Czy to oznacza że pełna refleksja w końcu będzie możliwa aż do poziomu bajtkodu?
Nie wiem co masz na mysli. Jak uzywasz gaalvm to refleksja dziala tak samo a jak kompilujesz to kodu natywnego zapomoca a graal to jest ograniczona. Ale najlepiej to by pytac jakiegos eksperta od graal i grallvm
loza_prowizoryczna napisał(a):
KamilAdam napisał(a):
Java powoli zmierza do tego zeby miec zarowno kompilator jak vm napisane w javie. Polecam hasla Java graal i Java graalvm
Czy to oznacza że pełna refleksja w końcu będzie możliwa aż do poziomu bajtkodu?
co ma piernik do wiatraka?
już dzisiaj możesz sobie wczytać plik *.class z classpatha w runtime, załadować do jakiejś biblioteki i obrabiać.
trwają prace nad rozszerzeniem samej javy o możliwość refleksji na bajtkodzie: https://openjdk.org/projects/babylon/ . jak widać, jest to częścią openjdk, który jest mieszanką c++a i javy i projekt babylon także będzie mieszanką c++a i javy.
0xmarcin napisał(a):
Ciekawe bo JVM, .NET, Python, Ruby i JavaScript są napisane w C lub C++...
każde ze środowisk uruchomieniowych tych języków to mieszanka języków. w zależności od platformy, ta mieszanka ma różne proporcje. dla przykładu, kolekcje wbudowane w pythona są napisane w czystym c, kolekcje wbudowane w jsa są zaimplementowane w tym co przeglądarka, ale kolekcje javowe czy c#owe są napisane (odpowiednio) w javie i c#.
Wibowit napisał(a):
co ma piernik do wiatraka?
Makę ;) A tak w temacie to fajnie byłoby mieć JVM kompilowalny przez JVM i modyfikowalny w runtimie, oczywiście nie musi mieć to praktycznych zastosowań. Ot po prostu zatarłoby bezsensowną granicę między danymi o programem.
loza_prowizoryczna napisał(a):
Wibowit napisał(a):
co ma piernik do wiatraka?
Makę ;) A tak w temacie to fajnie byłoby mieć JVM kompilowalny przez JVM i modyfikowalny w runtimie, oczywiście nie musi mieć to praktycznych zastosowań. Ot po prostu zatarłoby bezsensowną granicę między danymi o programem.
myślę, że https://github.com/oracle/graal/tree/master/espresso przynajmniej częściowo pasuje do tego opisu. co do modyfikowalności w runtime to trudno mi tu cokolwiek wyrokować, bo nie grzebałem mocno w tym espresso. obstawiam, że pewne rzeczy by się dało podmieniać w locie.
podmiana rzeczy w locie to mi się bardziej kojarzy z historiami o smalltalku, np: https://gbracha.blogspot.com/2009/07/miracle-of-become.html
Ciekawy sytuacja. Rząd chce ukrócić wlność i swobodę a wszyscy klaszczą.
A tak bardziej poważnie, to język taki jak rust, czyli kompilowany do natywnej binarki i z wysokimi gwarancjami w kontekście bezpieczeństwa pamięci powinien być w rozwoju od wczesnych lat dwutysięcznych. To jest niemal niewiarygodne, że niemal do połowy drugiego dziesięciolecia dwudziestego pierwszego wieku żyliśmy w baśniowym świecie wiecznego optymizmu, chociaż jak patrzę na fakt, że jakiś podmiot nadal zaleca używanie javascriptu to widzę, że wciąż czeka nas długa droga.
Dokonać ataku hakerskiego można właściwie przez każde Undefined Behaviour
No nie, nie każde, trochę odleciałeś, albo nie doceniasz ilości UB w standardzie. Choć nie robiłem nigdy takie ćwiczenia, to jednak składaniałbym się ku opinii, że mało które UB nadaje się do użycie do "ataku hakerskiego". Undefined Behaviour to pojęcie używane przez standard, tym nie mniej na prawie każde UB w standardzie przypada "defined behaviour" w kompilatorze. Poza tym, niektóre UB są traktowane prawie jak ficzery i są nie exploitowalne wg. mojej wiedzy, np. anonimowe struktury wewnątrz unii używane w niemal każdym silniku graficznym w którymś momencie swojego istnienia. Jaki był tego skutek? Ano żaden, działało na milionach maszyn. Także UB != podatność.
Poza tym, tak jak ogólnie jestem zadowolony z inwestycji w technologie natywne tak nie podzielam jakiegoś hurra optymizmu środowiska. Ciężko w rust wyeksploitować buffer/integer overflow, ale to jest wciąż możliwe PRZYKŁAD. Przykład może i adademicki, no i jest unsafe ale też nie kojarzę żadnego dużego produkcyjnego systemu stworzonego w samym rust, żeby móc wskazać jakiś "złoty wzorzec". Da się w ogóle stworzyć coś funkcjonalnego bez unsafe? Ktoś mnie oświeci? Race condition i memory corruption również są jak najbardziej możliwe https://zed.dev/blog/120fps.
Powoli również przestaję uznawać młody wiek rusta jako wymówkę na to, że nie widzimy nic poważnego zrobionego z jego użyciem. Taki Odin, który nie doczekał się jeszcze wersji 1.0 został użyty do stworzenia EmberGen https://odin-lang.org/showcase/embergen/. Język nie ma nawet połowy hype'u jaki ma rust a tworzymy w nim produkcyjne narzędzie do tworzenia efektów specjalnych dla gier i filmów a w rust dostający miliony dofinansowania robimy ćwierć używalne edytorki i konsole.
several napisał(a):
(...) a w rust dostający miliony dofinansowania robimy ćwierć używalne edytorki i konsole.
już chyba kilka lat temu pisałem, że owczy pęd rewrite everything in rust to ślepa uliczka. zamiast 'rust kontra reszta świata', rustowcy powinni od razu skupiać się na 'rust vs c/c++' i wygryzać c i c++ z ich niszy, zamiast np. próbować konkurować z javą tworząc frameworki do aplikacji biznesowych.
mimo wszystko, rust sobie chyba dobrze radzi i jestem zadowolony, że powoli zastępuje c i c++ np. w linuksie i linuksowych programach.
Reflekcja na bytecode w Java była od zawsze za sprawą biblioteki ASM (https://asm.ow2.io/)
Strasznie się tego używało ale działało w 2 strony (odczytać bytecode, wypluć bytecode i potem załadować do pamięci).
andrzejlisek napisał(a):
Co sądzicie o zagrożeniu jakie niesie ze sobą swoboda w zarządzaniu pamięcia w C/C++ ?
Sam fakt tej swobody jest zaletą, bo programista może w pełni kontrolować tworzenie i niszczenie obiektu, szczególnie, gdy to drugie to nie tylko zwolnienie pamięci, ale też wykonanie określonych czynności (procedura destruktora). Zawsze jest coś kosztem czegoś, czyli próba odwołania do przypadkowego miejsca, zgubienie wskaźnika i wielokrotne niszczenie tego samego wskaźnika.
To nie jest coś za coś, bo można mieć język który ma deterministyczna destrukcję i RAII jak C++ a równocześnie chroni przed problemami które opisałeś na końcu cytatu: Rust.
Wibowit napisał(a):
several napisał(a):
(...) a w rust dostający miliony dofinansowania robimy ćwierć używalne edytorki i konsole.
już chyba kilka lat temu pisałem, że owczy pęd
rewrite everything in rustto ślepa uliczka. zamiast 'rust kontra reszta świata', rustowcy powinni od razu skupiać się na 'rust vs c/c++' i wygryzaćcic++z ich niszy, zamiast np. próbować konkurować z javą tworząc frameworki do aplikacji biznesowych.
Nie no, bo Rust nie ma w ogóle żadnych zalet nad Javą. Żadnych. /s
Co do tematu poruszonego w pierwszym poście, to troche zabawna jest obecność Go na liście języków bezpiecznych pamięciowo, kiedy on nie jest bezpieczny pamięciowo (i nie chodzi mi o jakieś rozszerzenia w C wywołujące kod natywny tylko że można zrobić UB/segfault w czystym Go bez wykorzystywania błędów w kompilatorze czy innych nieładnych sztuczek).
są miejsca, w których C na ten moment nie da się zastąpić, ale z C++ tak nie jest(wyjątkiem są zabetonowane głowy wyznawców tego języka, którzy potrafią krytykować Rusta nawet za brak takiego badziewia jak dziedziczenie)
Także słuszny postulat, wybieranie C++ do nowych projektów nie ma już za bardzo sensu.
several napisał(a):
a w rust dostający miliony dofinansowania robimy ćwierć używalne edytorki i konsole.
normalnie np. we wrocławiu trzaskają projekty w Rust zamiast C++, dla niektórych klientów których udało się przekonać. Projekty są tylko to nie żadne spektakularne systemy jak w C++ bo one po prostu już są. Z resztą część firm nie widzi snesu w przepisywankach na c++. Np. takia nokia. Olbrzymi code base po co? Ani hajsu z tego nie będzie ani wartości dodanej w krótkim czy śrendim czasie. A czy w długim średnio też. Nie wspomnę o istniejących stosach przechodzacych na nowsze platformy np. STB(chociaż tu mocna walka z andkiem).
Adopcja Rust napotyka podstawowy problem. C++ jest i działa. Inne języki latami wygryzały go też z innych rejonów.
normalnie np. we wrocławiu trzaskają projekty w Rust zamiast C++
No taki argument na zasadzie trust me bro. Bevy można by uznać za ambitny projekt, tym nie mniej nie wiem czy jest to już faktycznie produkcyjne rozwiązanie?
Projekty są tylko to nie żadne spektakularne systemy jak w C++
Toteż nie porównywałem go do C++ a do Odin, który też jest świeżutkim językiem i ma już swój pierwszy "spektakularny" system.
No taki argument na zasadzie trust me bro
ale jaki argument trust me bro. np thaumatec który wspiera inicjatywy rust we wro. To są produkcyjne rozwiązania. Nie bardzo wiem co ci mam więcej napisać. Gadałem z ludźmi z firmy tamtej i z ich obserwacji wynika że jak by ten sam projekt robili w c++ mieli by więcej bugów. 90% załogi danego projektu uczyło się rust w trakcie.
To że nie wiesz że takie projekty sa m.in w polsce to nie znaczy że ich nie ma.
z resztą Microsoft szuka ludzi do teamów m.in office 365
https://mspoweruser.com/microsoft-forms-new-team-to-help-rewrite-core-windows-components-into-rust-from-c-c/
Z tego co wyczytałem na reddicie albo jakimś forum amerykańskim, pracownik MS mówił że będą przepisywać high perfomance fragmenty i będzie to miało wpływ na usługę na całej planecie. Czy to jest poważny system?
Sorry stary ale to ty uprawiasz trust me bro "Nie ma projektów w rust.". Przytoczyłem nie bez powodu wrocław a nawet zarzuciłem microsoft. Ba ms się na razie chwali ze część libek już migruje do rust(z samego windows),
Menecki napisał(a):
Co sądzicie o zagrożeniu jakie niesie ze sobą swoboda w zarządzaniu pamięcia w C/C++ ?
I o rekomendowanych przez USA językach zamiennych:
Let's go Brandon. MAGA
Sorry stary ale to ty uprawiasz trust me bro "Nie ma projektów w rust."
Ja nic nie uprawiam, sam przecież podałem przykład takiego dużego projektu czyż nie? Ja tylko sie dopytuje bo zazwyczaj jest problem z konkretami. Każdy coś słyszał, każdy coś widział, każdy zna kogoś, gdzieś na reddicie było a jak daję przykład jako punkt odniesienia to jestem ignorowany. A tutaj do tego starałem sie być ekstra fair i nie porównywać do języków kilkudziesięcioletnich.
Przytoczyłem nie bez powodu wrocław
W jaki sposób przytoczenie nazwy miast ma coś tłumaczyć? Zakładasz, że każdy programista w Polsce mieszka w tym mieście?
a nawet zarzuciłem microsoft
O nie nie nie, nie pisałeś o MS w poście do którego się odnosiłem. Nie napisałeś też nic konkretnego o Wrocławiu. MS to ogólnie dobry przykład, tym nie mniej z tego wpisu co podlinkowałeś to widzę, że chcą zastępować C# bo jest za wolny. Trochę to wygląda podobnie do przypadku discorda gdzie przepisali niektóre fragmenty klienta, żeby nie mulił za bardzo.
Oh nie, czyżbym wspomniał discorda? A wcześniej wspomniałem bevy? Czyżbym jako sceptyk był lepszy w bronieniu rusta niż jego entuzjaści? No ale jeśli się nie doczekam konkretów to nie ma sensu drążyć.
0xmarcin napisał(a):
Ciekawe bo JVM, .NET, Python, Ruby i JavaScript są napisane w C lub C++...
Co do .NET, to tak średnio bym powiedział.
I to statystyki dla runtime, w SDKach czy innych narzędziach C/C++ nie ma.
several napisał(a):
Ciekawy sytuacja. Rząd chce ukrócić wlność i swobodę a wszyscy klaszczą.
Straszny rząd zabrał wolność i nakazał wszystkim jazdę po prawej stronie drogi. Jak on mógł!
Powoli również przestaję uznawać młody wiek rusta jako wymówkę na to, że nie widzimy nic poważnego zrobionego z jego użyciem.
Jak system operacyjny Android nie jest wystarczająco poważny to nie wiem co jest.
Co musiałoby być pisane w Rust abyś uznał że ma popularność adekwatną do swojego wieku?
Widać wyraźnie Go dzięki wsparciu Google wybił się i obecnie liczba PRów zrównała się z C++.
Rust co prawa powoli zyskuje poparcie ale nie przegonił nawet starego C.
Czego brakuje co jest nie tak?
Go ma darmowe IDE - VSCode + official Go plugin.
Go jest proste, banalnie proste łamane na prymitywne.
Za Go stoi Google które postanowiło napisać w nim trochę kluczowych usług (k8s) w ten sposób poświadczając że język jest "battle tested" i "ready for production".
Gdyby Mozzila nagle przepisała Firefox'a w Rust'cie a nie jak teraz gdzie ma marne 15% (https://4e6.github.io/firefox-lang-stats/) i gdyby ten nowy Firefox pobił Chrome to z pewnością język zyskał by wielu zwolenników.
Wibowit napisał(a):
podmiana rzeczy w locie to mi się bardziej kojarzy z historiami o smalltalku, np: https://gbracha.blogspot.com/2009/07/miracle-of-become.html
Tak, wszyscy wtedy jarali się meta przez małe m. A tak czysto koncepcyjnie to mając JVM w Javie to cóż przeszkadza załadować libce zoptymalizowaną pod siebie wersję JVMa, skompilować ją w locie z użyciem obecnej i odpalić się na niej? Mocna incepcja.
0xmarcin napisał(a):
Reflekcja na bytecode w Java była od zawsze za sprawą biblioteki ASM (https://asm.ow2.io/)
Strasznie się tego używało ale działało w 2 strony (odczytać bytecode, wypluć bytecode i potem załadować do pamięci).
Ciekawe jak się to miało do sprawdzania poprawności i bezpieczeństwa odpalanego kodu w locie ;)
Krolik napisał(a):
Powoli również przestaję uznawać młody wiek rusta jako wymówkę na to, że nie widzimy nic poważnego zrobionego z jego użyciem.
Jak system operacyjny Android nie jest wystarczająco poważny to nie wiem co jest.
Co musiałoby być pisane w Rust abyś uznał że ma popularność adekwatną do swojego wieku?
Bo błędnie zakładasz, że wiem o tym fakcie. Jak się pewnie domyślasz, nie śledzę rusta zbyt wiernie, dlatego czasem się pytam po forach i ludzie zaczynają się irytować. Android nie pojawił się w tej dyskusji wcześniej niż w cytowanym tekście.
Tylko, że wg. https://source.android.com/docs/security/test/memory-safety Last updated 2024-02-07 UTC. i cytując Native code, written in memory unsafe languages like C, C++, and Assembly represent over 70% także jak na razie to trzeba by być precyzyjnym i napisać Rust jest użyty w android a nie android jest napisany w rust. 30% to nie mała liczba trzeba jednak przyznać, szybciej go integrują niż w jądrze linuksa. Wg tego dokumentu błędy pamięciowe to wciąż 51% wszystkich błędów.
Ale ja nie twierdzę, że Android został NAPISANY w Rust, a że obecnie jest PISANY w Rust.
Obecnie więcej nowego kodu w Android powstaje w Rust niż w C. Wiadomo, że Android istniał zanim Rust wyjrzał poza Mozillę, wiec oczywiste jest że stary kod jest napisany głównie w C i C++. W Androidzie niektóre bardzo istotne z punktu widzenia bezpieczeństwa komponenty zostały przepisane w Rust, np. stos Bluetooth.
Android 13 is the first Android release where a majority of new code added to the release is in a memory safe language
...
2022 is the first year where memory safety vulnerabilities do not represent a majority of Android’s vulnerabilities
Z innych poważnych projektów to również Amazon i Cloudflare dość mocno używają Rust. W Amazon dużo usług sieciowych napisano w Rust. A Cloudflare nawet zastąpił Nginx przez jakieś rozwiązanie które sami napisali w Rust.
Polski rynek jest specyficzny bo my tu dostajemy głównie projekty aplikacyjne, a nie systemowe. Więc jako język systemowy, Rust ma tutaj mniej zastosowań bo Java/C# są "wystarczająco dobre".
loza_prowizoryczna napisał(a):
Wibowit napisał(a):
podmiana rzeczy w locie to mi się bardziej kojarzy z historiami o smalltalku, np: https://gbracha.blogspot.com/2009/07/miracle-of-become.html
Tak, wszyscy wtedy jarali się meta przez małe m. A tak czysto koncepcyjnie to mając JVM w Javie to cóż przeszkadza załadować libce zoptymalizowaną pod siebie wersję JVMa, skompilować ją w locie z użyciem obecnej i odpalić się na niej? Mocna incepcja.
jak na razie to https://github.com/oracle/graal/tree/master/espresso jest raczej powolne i mocno ograniczone, więc jeśli lubisz optymalizować tak, żeby mieć gorzej, to możesz to zrobić już dzisiaj :)
0xmarcin napisał(a):
Reflekcja na bytecode w Java była od zawsze za sprawą biblioteki ASM (https://asm.ow2.io/)
Strasznie się tego używało ale działało w 2 strony (odczytać bytecode, wypluć bytecode i potem załadować do pamięci).Ciekawe jak się to miało do sprawdzania poprawności i bezpieczeństwa odpalanego kodu w locie ;)
w javie cały bajtkod (no może oprócz małego wycinka wbudowanej biblioteki standardowej, bo coś tam chyba musi być specjalnie traktowane) jest ładowany, parsowany, linkowany, optymalizowany, etc dynamicznie, więc z punktu widzenia jvma nie ma znaczenia czy ładujesz bajtkod z pliku *.jar na dysku, z torrentów, z kosmosu, czy generujesz sobie coś na bieżąco. cały bajtkod podany do jvma jest weryfikowany, obojętne skąd pochodzi. nawet jak była afera z https://en.wikipedia.org/wiki/Log4Shell to ten złośliwy bajtkod ładowany z internetu też był weryfikowany. weryfikacja polega na sprawdzeniu czy bajtkod jest poprawny, a nie czy jest złośliwy.