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ć!".