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.