Użytkownik "Sebastian Biały" <h...@p...onet.pl> napisał:

> On 4/1/2017 11:02 AM, AK wrote:
>> To nie ma nic wspolnego z "hackowaniem".
>> Takie konflikty sa czyms normalnym/zdarzaja sie czesto.
>> np. w przypadku laczenia bibliotek czystego C do C++ w ktorych
>> nie przewidziano wykorzystania ich w C++.
>
> Czyli hackowanie jednak.

Zadne hackowanie.
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++.
Fakt ze to wymaga niekiedy "hackingu" w przypadku mix-u
kompilatorow (nie polecam).

AK

do góry

Użytkownik "Andyy" <n...@s...tego> napisał:
> W przypadku VC dodaje podkreślenia do nazw funkcji i jest dobrze ale GCC nie
dodaje.

Owszem. Dodaje. W C zawsze stabdardowo dodaje.
Kazdy kompilator C tak robi.

Probllemy z mixem kompilatorow sa inne i tycza
'internalsow' bibliotek.
Datego trzeba wiedziec co i jak sie robi, aby
uniknac (nei zawsze sie da) np. unresolved externals.

AK

do góry

On 4/1/2017 2:47 PM, AK wrote:
>> Czyli hackowanie jednak.
> Zadne hackowanie.

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.

> 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?

> Fakt ze to wymaga niekiedy "hackingu" w przypadku mix-u
> kompilatorow (nie polecam).

No wreszcie.

Pamietam jak kilkanascie lat temu w jednej z firm w okolicy która pisała
skomplikowany kod pod Sparka, wylatywał u userów, ale nie wylatywał na
testowaniu produkcji [1]. Winien był jeden hacker w firmie który zgodnie
z zasadą "będzie Pan zadowolony" stosował niedozwolone sztuczki podczas
linkowania aby zmusić stary kod do dzialania z nowym [2]. Wliczając w to
edycję plików binarnych hex edytorem i automatyczną podmianę prologów
funkcji żeby ABI się zgadzało.

Dzisiaj już wiem że jesli ktoś mówi ze coś da się to obejśc taką mała
sztuczką to nalezy spierd.. jak najdalej od takich hackerów.

Firmy juz nie ma, choć nie z tej przyczyny.

[1] Bo na produkcji inny hacker (managerowaty) założył że nie ma sensu
testować wersji z optymalizacjami bo wtedy jest mniej kodu testowane (!).

[2] "Bo przepisanie tego to minimum tydzień, a ja w 2 dni mogę to
zhackować!".

do góry

Użytkownik "Sebastian Biały" <h...@p...onet.pl> napisał:

> On 4/1/2017 2:47 PM, AK wrote:
>>> Czyli hackowanie jednak.
>> Zadne hackowanie.
>
> 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.
Zarowno w samym C jak i w laczeniu go (czystego C) z C++
(czy innymi jezykami programowania).
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).

>> 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).
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.
PS: Natomiast "niezdefiniowany" to _jest_ dokladny opis.

>> Fakt ze to wymaga niekiedy "hackingu" w przypadku mix-u
>> kompilatorow (nie polecam).
>
> No wreszcie.

Co "no wreszcie"?
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) ?
Jelsi znalibysmy ta nazwe to spokojnie mozlinbysmy takigo symbolu/funkcji uzyc
(gdyz wolanie z dll-ki jest systempowo usystematyzowane - czylio ponad
kompilatorowe/jezykowe)?
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()).
Jedyny problem jest tym ze mangling jest per-compiler-specyfic
i dlatego 1.trzeba wiedziec jakim kompilatorem dll-ka jest uskuteczniona
2. uzyc mangkera z tego wlasnie kompilatora.
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.
To jest _jedyna_ roznica - ale daleka od jakiegokolwiek hackerstwa.

> Pamietam jak kilkanascie lat temu w jednej z firm w okolicy która pisała
skomplikowany kod pod
> Sparka, wylatywał u userów, ale nie wylatywał na testowaniu produkcji [1]. Winien
był jeden hacker
> w firmie który zgodnie z zasadą "będzie Pan zadowolony" stosował niedozwolone
sztuczki podczas
> linkowania aby zmusić stary kod do dzialania z nowym [2]. Wliczając w to edycję
plików binarnych
> hex edytorem i automatyczną podmianę prologów funkcji żeby ABI się zgadzało.

Jak sie ktos nie douczyl, to sobie napisze "hacker" i robi takie i inne glupoty.
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
robi linker czy loader dllki ("kiedys" linker byl osobnym programem.
Ba!. Byl programem "ponadjezykowym".)

PS: Nie moge "wyjsc z podziwu" jak Wy mlodzi dzis piszecie w C/C++
nie znajac tak podstawowych systemowych rzeczy :(

AK

do góry

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.

do góry

Błędów. Tych co sam je zrobiłem. Na szczęście informatyk to nie saper.

do góry

Użytkownik "Sebastian Biały" <h...@p...onet.pl> napisał:
> On 4/1/2017 7:48 PM, AK wrote:

> Nie mów "doucz się". Nie masz pojęcia o wiedzy kogokolwiek na podstawie paru
linijek.

Po 30 latach "siedzenia" w C/C++ wystarczy mi kilka linijek/slow do
oceny czyichs kompetencji. Zapewniam :)

>> 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++?

Jesli jakis programista nie potrafi sobie poradzic z podkresleniami w externalach C
to lepiej niech przekresli swoje "programistyczne" dokonania i zajmie sie rymarstwem.
_KAZDA_ biblioteka w C da sie wykorzystac w C++ i to bez znaczenia czy
*lib czy nie dll.

>> 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.

Pachniesz mi przedszkolem programistycznym.
Tak wlasnie powstaje bajzel w sofcie gdzie kazdy sobie lokalnie
skompiluje/statycznjie zlinkuje jakas biblioteke i pozniej jakakolwiek zmiana
w niej skutkuje potrzeba rekompilacji zrodel i u kazdego (a co jesli ktos bedzie na
L4:)?
zamiast zwyczajnie skorzystac z jedenj slusznej boiblioteki a w przypadku
neizmieniana
interface nawet po porstupodmienc dllke/so.
Jesli w dakszym ciagu nie rozumiesz dlaczego (ze nie wspomne latwosci z jaka
biblioteka dll/so w C moze byc wykorzystana w innych jezykach priogramowania),
to raczej Tobie przydalby sie psychatra,

>> 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.

Napisanie prostego inlineowego wrappera to hankertswo?
Hehe.
Zwykle takie rzeczy robi sie o wile lepiej/latwiej/pewniej przez
*.dll/*so

>
>> PS: Natomiast "niezdefiniowany" to _jest_ dokladny opis.
>
> Tak, oczywiście. "Nie wiadomo jak wygląda krowa" jest niezwykle precyzyjnym opisem
krowy. Moving
> on.

Ale owszem.
Wtedy trzeba dzialac "per compiler" - jak np w przyoadku manglingu.
O UB w raportach C/C++ nie slyszales ?


>>> 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?

Co ma ABI wspolnego z manglingiem ?
Jesli ABI jest wspolne (a jest) to moza miec rozne manglingi (od roznych
kompilatorow C) i spokojnie da sie to wszystko bezpiecznie pozenic.

> A unwinding stosu jest kompatybilny?

A nie?

> A sposob instancjacji templates jest znany? Wiadomo jak się robia funkcjie inline?

A co mnie to obchodzi co sie dzieje w srodku dll-ki jesli mam pewne/dobrze
zdefiniowane
jej API publiczne i zachowuje pewne oczywiste zasady tyuczace bibliotek dzielonych
i programownai w srodowisku wielokompilatorowym (np ze ta sama dll-ka powinna
obslugiwac i zwalnic zasoby przez siebie przydzielone/utworzone . Np pamiec,
otwierane pliki
itp)?

> Wiadomo co się stanie jak trafimy ponownie na ten sam symbol przy linkowaniu? Etc.

W "moich czasach" take cos bylo zawsze traktowane jako blad.
Do dzisaj zawsze staram sie miec mam wlaczona opcje traktowani tego jako bledu
a nie (zwykle przez mlodych) ignorowanego ostrzezenia.
No ale to abc przecie, a nie zadne hackerstwo :)

>> 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.

No jelsi ktos nie chce standardowo tylko specyficzne dla swego env.
to wiadomo ze moze korzystac tylko lokalnie, ale przeciez zawsze jest mozliwosc
"otwarcia" sie na swiat :)

> 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.

Blele ble o wszytskim czyli klasyczne meiszanko i sciema :).

>> 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.

A tak. To jest zupelnie 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.

No cos.. Jelsi kompiler sam sie nie wspiera to nic na to nie poradze :)
/z tym tez sobie mozna poradzic - robiac wrapping ze starego mnglingu na nowy/.


>
>> 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.

Co 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

Ale OS mowi. I to bardziej szzczegolowo niz kompilatory
Kazdy kompilator musi sie do tegi dostosowac (bo inaczej
nic byz niczym nie wspolpracowalo) a nie odwrotnie.

> a ludzie piszacy kod jednoczesnie na 5 róznych platform mają
> w nosie hackowanie każdej z nich osobno.

Mangling jest (poza pomijalnymi wyjatkami) per-compiler
a nie per-system. Tych kompilatorow C++ nie ma za duzo
(raptem 4-6 na wszytskie platformy) wiec jest to mniejszy
problem niz w przypadku per-os.

>
>> 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.

Potwierdzam. Nie masz _zielonego_ pojecia ani i *.obj/*.o ani
kwestiach linkowania, a juz szczegolnie nie masz zielonego pojecia o *.dll/*.so.

Jestes typowym niedoukiem co to tylko potrafi byc glosny/szpanuje na
fachowca a nie zna podstawowych rzeczy systemowych zwiazanych z C/C++
i stad wszedzie widzi koniecznosc "hanckowania" miast normalnego
(bezpiecznego) poruszania sie w temacie.

AK

do góry

On 4/1/2017 11:44 PM, AK wrote:
>> Nie mów "doucz się". Nie masz pojęcia o wiedzy kogokolwiek na
>> podstawie paru linijek.
> Po 30 latach "siedzenia" w C/C++ wystarczy mi kilka linijek/slow do
> oceny czyichs kompetencji. Zapewniam :)

Przykro mi że tak płytko oceniasz ludzi.

>> 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++?
> Jesli jakis programista nie potrafi sobie poradzic z podkresleniami w
> externalach C
> to lepiej niech przekresli swoje "programistyczne" dokonania i zajmie
> sie rymarstwem.
> _KAZDA_ biblioteka w C da sie wykorzystac w C++ i to bez znaczenia czy
> *lib czy nie dll.

Wiadomo. Tylko po ch ?

>>> 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.
> Pachniesz mi przedszkolem programistycznym.

Jak widzisz twoje kilka linijek lub słów do oceny kompetencji okazuje
się być picem na wodę.

> Tak wlasnie powstaje bajzel w sofcie gdzie kazdy sobie lokalnie
> skompiluje/statycznjie zlinkuje jakas biblioteke i pozniej jakakolwiek
> zmiana
> w niej skutkuje potrzeba rekompilacji zrodel i u kazdego (a co jesli
> ktos bedzie na L4:)?

Ktoś idzie na L4 i pada firma. Gratuluję.

Ktoś dostarcza skompilowane elementy na produkcję. Gratuluję.

Ciekawe, że zazwyczaj "programisci z dużym stażem" nigdy nie słyszeli o
takich wynalazkach jak np. ciągla intergracja. I zawsze ten sam argument
bez sensu: bo trzeba kompilować. Ojej. To lepiej faktycznie nie.

> zamiast zwyczajnie skorzystac z jedenj slusznej boiblioteki a w
> przypadku neizmieniana
> interface nawet po porstupodmienc dllke/so.

Znam taką jedną firmę. Mieli problem bo chcieli zmienić dllki i
interfejsy ale nie kompilować pozostałych bo szkoda bitów i cykli.
Wymyslili więc fantastyczny mechanizm "statycznych interfejsów" który
polegał że do każdej funkcji przekazywano zamiast listy argumentów jeden
argument: mapę "nazwa argumentu<->wartość". Oczywiscie wartości
zserializowane. Czy to nie wspaniałe osiągnięcie? W ciagu roku ze
stabilnego jezyka silnie typowanego zrobiono pistolet na wodę. Bo każda
nadmierna kompilacja dllki u sasiada jest szkodliwa i lewacka!

No dobra, to troche odbiega od tematu, ale dalej blisko tematu hackowania.

Mówisz że wystarczy podmienić dll jak się interfejsy nie zmieniły? No i
co z tego? Wszyscy to wiedza. Choć ... jesli pisza coś większego niż
hello worldy to może być dośc interesująco, szczególnie w okolicy templates.

> Jesli w dakszym ciagu nie rozumiesz dlaczego (ze nie wspomne latwosci z
> jaka
> biblioteka dll/so w C moze byc wykorzystana w innych jezykach
> priogramowania),
> to raczej Tobie przydalby sie psychatra,

Oczywiscie że przydałby się każdemu. Odbiegłeś jednak daleko od problemu
o którym jest ten nedzny trolling.

Ktoś ma problem z podkresleniami. I ktoś ma z tym problem mimo dostepu
do źrodeł. Nie, nie zmieniam zdania. To się nadaje do psychiatry.

Wymiana dllki na inna o identycznym interfejsie nie ma sie nijak do tego
problemu, ale doceniam twoje trudy lania wody w celu zastraszenia
przeciwnika.

Na marginesie: możesz pokazac z jaką latwością mozna uzyć dllki
napisanej w C w takiej Javie? Spodziewam się max 1 linijki overheat
skoro to taka łatwość.

Tak wiem jak to się robi w Javie. Nie, to nie jest łatwe, choć
oczywiscie można pokazać na przykładzie void foo(void){} że prawie łatwe.

>> A, czyli hackerstwo.
> Napisanie prostego inlineowego wrappera to hankertswo?

Czasem tak.

> Hehe.
> Zwykle takie rzeczy robi sie o wile lepiej/latwiej/pewniej przez
> *.dll/*so

Czasem nie.

>> Tak, oczywiście. "Nie wiadomo jak wygląda krowa" jest niezwykle
>> precyzyjnym opisem krowy. Moving on.
> Ale owszem.
> Wtedy trzeba dzialac "per compiler" - jak np w przyoadku manglingu.
> O UB w raportach C/C++ nie slyszales ?

A skąd wniosek że nie słyszalem i w jaki sposób UB ma pomagac w temacie
podkreśleń?

>>> 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?
> Co ma ABI wspolnego z manglingiem ?

"Jakie jest niebezpieczenstwo w tym ze chcemy sie dobrac do np. symbolu
w DLLce". Ano takie że może sie ABI nie zgadzać. Bum.

> Jesli ABI jest wspolne (a jest) to moza miec rozne manglingi (od roznych
> kompilatorow C) i spokojnie da sie to wszystko bezpiecznie pozenic.

Jeśli ktoś by nie hackowal to by nie mial problemu z podkresleniami.

Jeśli.

I jeszcze jeśli ABI jest wspólne. Bo przecież w rzeczywistym świecie
jest tylko jeden kompilator wszystkich dllek.

>> A unwinding stosu jest kompatybilny?
> A nie?

Czasem nie.

>> A sposob instancjacji templates jest znany? Wiadomo jak się robia
>> funkcjie inline?
> A co mnie to obchodzi co sie dzieje w srodku dll-ki

Czasem się to dzieje na zewnątrz. Ty sobie instacjonujesz gdzieś
foo<long int> a ktoś inny spodziewa się foo< long > i nagle jest jakiś
zabawny problem z bugami w kompilatorze.

> jesli mam
> pewne/dobrze zdefiniowane
> jej API publiczne i zachowuje pewne oczywiste zasady tyuczace bibliotek
> dzielonych
> i programownai w srodowisku wielokompilatorowym (np ze ta sama dll-ka
> powinna
> obslugiwac i zwalnic zasoby przez siebie przydzielone/utworzone . Np
> pamiec, otwierane pliki
> itp)?

API masz zdefiniowane, wszystko działa i nie ma problemu. Życ nie
umierać. A tymczasem w sąsiedniej rzeczywistości ktoś ma .so od
producenta który nie wie czym kompilował, ma dziwne manglowanie i
brakuje częsci symboli bo się inaczej inlineowały, a templates nie
pasują do nazw. I jeszcze jakis miszczu zhackowal podkreslenia. Co
robić, pozostało więcej hackowania.

>> Wiadomo co się stanie jak trafimy ponownie na ten sam symbol przy
>> linkowaniu? Etc.
> W "moich czasach" take cos bylo zawsze traktowane jako blad.

W tutejszej rzeczywistosci już niekoniecznie.

> Do dzisaj zawsze staram sie miec mam wlaczona opcje traktowani tego jako
> bledu
> a nie (zwykle przez mlodych) ignorowanego ostrzezenia.
> No ale to abc przecie, a nie zadne hackerstwo :)

Wiadomo. Szczególnie jak dwóch idiotów zrobi "GetFactory" bez namespaces
i to sa dwie rózne firmy komercyjne. Przypadek z większego banku.
Workaroundem okazało się ukrywanie symboli recznie w .so poprzez
robienie so warppera. Problem hacked. Wczesniej mieli ręcznie edytowane
pliki binarne. Trudno się nie zgodzić że oba rozwiązania działają więc
sa dobre. Tak, sa dobre...

>>> 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.
> No jelsi ktos nie chce standardowo tylko specyficzne dla swego env.
> to wiadomo ze moze korzystac tylko lokalnie, ale przeciez zawsze jest
> mozliwosc
> "otwarcia" sie na swiat :)

No to jak w końcu, mozna użyć czy nie? dllki mają ustandaryzowane cośtam
czy nie?

>> 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.
> Blele ble o wszytskim czyli klasyczne meiszanko i sciema :).

Nie ma tu mieszanka. To sa problemy z zycia wzięte. Mojego rownież. To
jest rzeczywistość spotykana na codzień w kodzie embedded.

>> 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.
> No cos.. Jelsi kompiler sam sie nie wspiera to nic na to nie poradze :)
> /z tym tez sobie mozna poradzic - robiac wrapping ze starego mnglingu na
> nowy/.

Otóż to. Wrapper na wrapper i jedziemy dalej.

>>> 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.
> Co fail?

Miało byc coś o cięzkim przypadku a na koniec okazało się że jeśli
załozyć że nie będzie huraganu to ten płot da radę. Czyli problemu nie
ma. Moving on.

>>> 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
> Ale OS mowi.

Mało mowi. W .so i w .dll wolno wsadzić w miejsce kodu dowolny film
porno w kodeku Indeo i nikt nie będzie marudził że dllka jest zla, choc
może bedzie marudził że kiepska jakość.

> Kazdy kompilator musi sie do tegi dostosowac (bo inaczej
> nic byz niczym nie wspolpracowalo) a nie odwrotnie.

Borland o tym nie widzial i zrobił inne ABI. Albo inaczej: wiedzial i z
premedytacją zrobił inne ABI. Pech.

>> a ludzie piszacy kod jednoczesnie na 5 róznych platform mają
>> w nosie hackowanie każdej z nich osobno.
> Mangling jest (poza pomijalnymi wyjatkami) per-compiler
> a nie per-system. Tych kompilatorow C++ nie ma za duzo
> (raptem 4-6 na wszytskie platformy) wiec jest to mniejszy
> problem niz w przypadku per-os.

Są kompilatory do embedded. Ich jest jak mrówków. Są rózne ABI co mnozy
ilośc kompilatorów. Są różne libc, wersje API, widzimisie konwencji
wołania, rozwijania templates, architektur kodu maszynowego, podejscia
do allokacji pamięci itp itd. Mało tego nie jest.

C++ jest bardzo bogaty w koncepcje jak skopilować a + 2 na różnych
maszynach i w ramach tej samej maszyny. Zakladanie ze dllki sa stabilne
jest niebezpieczne.

>> 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.
> Potwierdzam. Nie masz _zielonego_ pojecia ani i *.obj/*.o ani
> kwestiach linkowania, a juz szczegolnie nie masz zielonego pojecia o
> *.dll/*.so.

Ziew.

> Jestes typowym niedoukiem co to tylko potrafi byc glosny/szpanuje na
> fachowca a nie zna podstawowych rzeczy systemowych zwiazanych z C/C++
> i stad wszedzie widzi koniecznosc "hanckowania" miast normalnego
> (bezpiecznego) poruszania sie w temacie.

Nie. Nie masz absolutnie racji. Ale doskonale widzę jak bardzo mało
wiesz o innych pomimo "wystarczy mi kilka linijek/slow". Nie, nie
wystarczy. Oceniasz ludzi na podstawie swoich skostniałych poglądow.
Każdy może mieć jakieś poglądy, nie ma problemu, nawet skostniałe. Warto
jednak sobie zdawać sprawę że sie nie jest jasnowidzem. A juz na pewno
nie okazywać idiotyzmu twierdząc że mozna kogoś prześwietlić po paru
słowach. Jest to o tyle niebezpieczne że podczas takiego prześwietlania
może sie okazać że sam bedziesz prześwietlony - jak tutaj.

do góry

W dniu piątek, 31 marca 2017 19:37:08 UTC+2 użytkownik s...@g...com napisał:
> > czym zostałem
> > ostatnio zjebany...
>
> Widać ty też jesteś jednym z owych bezimiennych "zjebanych" którzy uprzykrzają mi
życie. Jeden z nich siedzi w Micro$oft i wymyśla prawa dostępu, automatyczne akcje
systemu po włożeniu nośnika, małe okna wprowadzania ustawień w zmiennych systemowych,
wymyśla manifesty i podpisy cyfrowe, zbieranie wszelkich wprowadzanych danych
(szpiegostwo!!!). Drugi zjebany siedzi w Google i pisze w Java system operacyjny na
urządzenia zasilane bateryjnie (no comment), wymyślił, że niedokładne wyszukiwanie w
Google jest lepsze od dokładnego, no bo przecież w sumie to Google wie lepiej niż Ty
co chcesz znaleźć. Inny zjebany ciągle otwiera okno w pracowniczym kiblu, choć tam
praktycznie nie śmierdzi. Inny zjebany (tym razem domowy) łaja mnie za wszystko i
nazywa pasożytem (mimo, że łącznie z dojazdami do pracy nie ma mnie w domu 11h). I
mimo, że zjebanemu pomagałem więcej niż ktokolwiek inny twierdzi, że w niczym mu
jeszcze nie pomogłem. Jeszcze inny zjebany wymyślił, że w zasadzie chleb nie musi być
wypieczony, bo wystarczy, że jest upieczony - skutek jest taki, że chrupiącego chleba
czy chrupiącej bułki już dziś w normalnym sklepie nie kupisz (przynajmniej w mojej
okolicy). Wielkie kariery zjebani robią w dziale architektury krajobrazu urzędów
miejskich - np u nas zrobili ścieżkę rowerową do której nie prowadzi żadna inna droga
tylko z jej drugiego końca, bo jej wjazd jest ogrodzony barierą jak na autostradzie i
kanałem z drugiej strony (teraz rozpoczęli budowę kładki na drugą stronę tego kanału,
tak, że już będzie można wjechać na tą ścieżkę). Zjebani zawsze lepiej wiedzą jak
poprowadzić chodnik od tych co chodzą po tych ścieżkach i idą zwykle "na skróty...
>
> Pewnie Wy znacie nie jedno dzieło "zjebanego", tyle że nie nazywaliście go do tej
pory w ten sposób...

(troche meta uwag - takich ktore dosyc lubie i sa w moim stylu, bo to zawsze troche
pomaga zblizyc sie do sedna)

ciekawe jest w sumie to ze w zyciu mozna przyjmowac cale zestawy roznych postaw
(wobec ms, androida itd itd) i te
postawy poniekad okreslaja rzeczywistosc /sytuacje ..

kiedys jak bylem mlodszy pamietam zawsze zalezalo mi by te postawy byly dosyc zlozone
inteligentne i wyrafinowane (co wymaga wysilku ale jest dobre dla inteligencji,
rownoczesnie tez jednak pewnie przeszkadza - bo duzym jest wydatkiem energii )

dzis jestem ogolnie rozwalony/ skorumpowany psychicznie
(chyba ogladam/czytam za duzo glupoty i powierzchownosc mnie strasznie pozarazala)
[[do tego in fact jestem ciagle strasznie obolaly (nie wiem czemu ale praktycznie
wiekszosc zycia w ostatnich latach spedzam w ciaglym bolu
fizycznym, moze coz z watroba bo ogolnie zle wyniki krwii, co tez istatnie
przeszkadza i komplikuje sytuacje]] i jestem sklonny przyjmowac te postawy bardziej
powierzchowne

postawy powierzchowne sa glupsze ale praktycznie
latwiejsze - nie nalezy chyba jednak ich zbytnio pochwalac - z drugiej strony sam nie
wiem czy jak dla
mnie warto by na dzis is w kierunku by budowac te
postawy o bardzo wysokim stopniu zaawansowania ;c (na przyklad jak ktos klekocze w
internecie czy starac sie odniesc do tego w bardziej skomplikowany sposob
czy prosty (glownie reaguje nieststy w proste tj
wpieniam sie ze trace czas) - mozna by niby budowac,
ale wydaje sie ze nieststy mam tyle bardziej pilnych
priorytetow (np zdrowie) ze ten temat na dzis wydaje
sie poboczny

z drugiej strony odejscie od intelektualnej prostoty
i siepaniny jest w pewnym sensie obowiazkowe

do góry

s...@g...com pisze:
>>> wyszukiwanie w Google jest lepsze od dokładnego, no bo przecież w sumie
>>> to Google wie lepiej niż Ty co chcesz znaleźć.
>> Niech wie - byle dało się to wyłączyć.
>
> Może ktoś wie jak przywrócić w Google dokładne wyniki wyszukiwania?!?
> Bo teraz jest to spieprzone i tylko denerwuje. Bing wyszukuje podobnie. Więc chyba
alternatywy brak...
Yandex ? Nie piszę, że alternatywa, ale spróbować możesz ...

do góry