Path: csiph.com!feeder.erje.net!1.eu.feeder.erje.net!ecngs!feeder2.ecngs.de!81.171.118.63.MISMATCH!peer03.fr7!futter-mich.highwinds-media.com!news.highwinds-media.com!newsfeed.neostrada.pl!unt-exc-02.news.neostrada.pl!newsfeed2.atman.pl!newsfeed.atman.pl!.POSTED!not-for-mail From: =?UTF-8?Q?Sebastian_Bia=c5=82y?= Newsgroups: pl.comp.programming Subject: =?UTF-8?Q?Re:_Czego_nie_lubicie_jako_programi=c5=9bci=3f?= Date: Sat, 1 Apr 2017 20:31:23 +0200 Organization: ATMAN - ATM S.A. Lines: 129 Message-ID: References: <1jTdcmbuhI9c8Nv8%gof@news.chmurka.net> <1sTdcpiakI9c8Nv8%gof@news.chmurka.net> <48893a76-3fd1-4a3d-bb14-279c5fb4ccfa@googlegroups.com> NNTP-Posting-Host: 176.115.85.233 Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Trace: node2.news.atman.pl 1491071485 697 176.115.85.233 (1 Apr 2017 18:31:25 GMT) X-Complaints-To: usenet@atman.pl NNTP-Posting-Date: Sat, 1 Apr 2017 18:31:25 +0000 (UTC) User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 In-Reply-To: X-Received-Bytes: 6566 X-Received-Body-CRC: 2712243939 Xref: csiph.com pl.comp.programming:29578 On 4/1/2017 7:48 PM, AK wrote: >> Jesli zmuszasz biblitekę aby pracowala w warunkach w której jej nie >> testowano/projektowano i w tym celu musisz poznać internalne działanie >> kompilatora i linkera, a bywa że i nieudokumentowane i/lub niestabilne >> jego elementy - to jest *czyste* hackerstwo. > Doucz Cie C. Mangling w C jest _scisle zdefiniowany_ w standardzie > i niczego nie musze "internalnie" poznawac. I co z tego skoro mangling w C++ jest ścisle niezdefiniowany? Nie mów "doucz się". Nie masz pojęcia o wiedzy kogokolwiek na podstawie paru linijek. > Zarowno w samym C jak i w laczeniu go (czystego C) z C++ > (czy innymi jezykami programowania). Serio? To skad te kłopoty kilka postów wyżej o podkresleniach? Czyżby dlatego że ktoś probował hackować bibliotekę nie przeznaczoną do C++? > PS: Zreszta to jest technika ktora zecydownie preferuje niz mixowanie > kodu w C z kodem C++ w jednym przebiegu kompilacji/w jednym lib-ie > (nawet jesli mam pelny dostep do zrodel). Jak się ma pelny dostęp do źródeł to nie da się wytlumaczyć tych kłopotów inaczej jak psychiatrycznie. >>> Wsio dokaldnie opisane zarowno w raporcie C jak i C++. >>> Problemem jest co innego. >>> Proiblemem jest nieustandaryzowane (w przeciwienstwie do C) >>> manglowanie nazw w "nowoiczesnym" C++. >> Czyli jednak wsio nie jest dokładnie opisane? Czyli hackerstwo? > Jakie hackerstwo? > Po prostu "tak sie nie robi" poniewaz mangling w C++ zwyczajnie > nieustandaryzowany (czytaj C++ jest spieprzony). To po co się tak robi skoro się tak nie robi? > Dlatego takie mixowanie interkompilatorowe C++ robi sie > np.wlasnie za posrednictwem C a w C++ robi sie lekkie owijki > obiektowe (same *.h) (to niestety pracochlonne, ale to nie moja wina > ze C++ "tak ma"), albo za posrednictwem dll/so. A, czyli hackerstwo. > PS: Natomiast "niezdefiniowany" to _jest_ dokladny opis. Tak, oczywiście. "Nie wiadomo jak wygląda krowa" jest niezwykle precyzyjnym opisem krowy. Moving on. >> No wreszcie. > Co "no wreszcie"? Dostrzegasz hackerstwo. > Jakie jest niebezpieczenstwo w tym ze chcemy sie dobrac > do np. symbolu w DLLce (a wiec ustandarysowanej systemowo > biblioteki) ktorego mangling jest "nieznany" (czylli nazwa w DLLce jest > niewiadoma) ? A ABI jest wiadome skoro takiego detalu jak mangling nie znamy? A unwinding stosu jest kompatybilny? A sposob instancjacji templates jest znany? Wiadomo jak się robia funkcjie inline? Wiadomo co się stanie jak trafimy ponownie na ten sam symbol przy linkowaniu? Etc. > Jelsi znalibysmy ta nazwe to spokojnie mozlinbysmy takigo > symbolu/funkcji uzyc > (gdyz wolanie z dll-ki jest systempowo usystematyzowane - czylio ponad > kompilatorowe/jezykowe)? Serio jest ustandaryzowane? No no. To się developerzy Delphi zdziwią po co im te wszystkie _fastcall i _stdcall. Wychodzi że po nic. Biedacy. A .so jest ustandaryzowane? Sugeruje dla sportu zerknąć co to za dziwne SYSV pokazuje mc kiedy sie zrobi F3 na pliku .so. I dlaczego czasem tam pisza Linux. Moża też zerknąc co to jest arm-[e]abi i na przykład jakieś ciekawostki jak thumb mieszany z arm w jednym .so. > Problemm polega tylko na tymze my tej nazwy nie znamy. > Trzeba ja wiec poznac i w tym celu nalezy zmanglowac nazwa C++wa > i uzyc tej zmanglowanej np w dynamicznym pobraniu adresu z dll-ki > (GetProcAddress()/dlsym()). Aha. Dziękujemy kapitanie Obvious. > Jedyny problem jest tym ze mangling jest per-compiler-specyfic No przeciez o tym mowa od poczatku. Ja nawet niegrzecznie zauważę że jest równiez version-specyfic co było swego czasu bardzo bolesne w egozytycznych kompiltorach uC bo niedzielni hackerzy w embedded nie raz sobie zęby wybili po upgrade. > i dlatego Hack on my mark in 1 ... > 1.trzeba wiedziec jakim kompilatorem dll-ka jest uskuteczniona 2... > 2. uzyc mangkera z tego wlasnie kompilatora. 3... > Gdy DLL-a jest w czystym ten nazwa (bez wzledu na kompilator C > ktorym jest tworzona) jest _zawsze_ zgodny z nazwa w zrodle > (a w przypadku obj/lib-ow: _ + nazwa_w_zrodle_C) > wiec problemow 1. i 2. w C zwyczjnie nie ma. Fail. > Tymczasem to nie zaden hacker ale zwykly niedouczony palant :(. > Tymczasem mozna prosto i latwo i zgodnie ze standardami. > Trzeba "tylko" wiedziec co to jest *.obj, *.lib, *.dll/*.so i co tak > naprawde C++ nic nie mówi co to jest .so i .dll a ludzie piszacy kod jednoczesnie na 5 róznych platform mają w nosie hackowanie każdej z nich osobno. > PS: Nie moge "wyjsc z podziwu" jak Wy mlodzi dzis piszecie w C/C++ > nie znajac tak podstawowych systemowych rzeczy :( Ponieważ jak każdy bardzo stary programista jestes już sterowany lokalną ideologią i widzisz tylko swoje urojenia. Na przykład takie urojenie że ktoś nie ma pojęcia jak to działa mimo że wie wystarczająco dokładnie jak to działa. Sugeruje więc pozbyć się tych "Wy" i jeszcze raz dokładnie się zastanowić po co z taki uporem tlumaczysz rzeczy oczywiste ktore i tak sprowadzają się do tego że generujesz kiepskiej jakości kod i mechanizmy rodem z podrecznika dla hackerow.