Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > pl.comp.programming > #29537 > unrolled thread

Czego nie lubicie jako programiści?

Back to article view | Back to pl.comp.programming

Contents

  Czego nie lubicie jako programiści? gof@somewhere.invalid (Adam Wysocki) - 2017-03-30 19:48 +0000
    Re: Czego nie lubicie jako programiści? szykcech@gmail.com - 2017-03-30 21:14 -0700
      Re: Czego nie lubicie jako programiści? niepełnosprawny intelektualnie 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-03-31 18:08 +0200
        Re: Czego nie lubicie jako programiści? szykcech@gmail.com - 2017-03-31 10:37 -0700
          Re: Czego nie lubicie jako programiści? niepełnosprawny intelektualnie 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-03-31 19:46 +0200
            Re: Czego nie lubicie jako programiści? Andrzej S <asta@evbox.pl> - 2017-04-03 08:18 +0200
              Re: Czego nie lubicie jako programiści? niepełnosprawny intelektualnie 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-04-04 17:22 +0200
          Re: Czego nie lubicie jako programiści? t-1 <t-1@todlaspamu.pl> - 2017-03-31 21:03 +0200
          Re: Czego nie lubicie jako programiści? gof@somewhere.invalid (Adam Wysocki) - 2017-04-01 00:37 +0000
            Re: Czego nie lubicie jako programiści? szykcech@gmail.com - 2017-04-01 01:52 -0700
              Re: Czego nie lubicie jako programiści? "PawelS cbrbob(at)wbcd(dot)pl" <fake@email.org> - 2017-04-02 12:08 +0200
                Re: Czego nie lubicie jako programiści? szykcech@gmail.com - 2017-04-02 09:10 -0700
                  Re: Czego nie lubicie jako programiści? Andyy <nie@spamowac.tego> - 2017-04-02 18:22 +0200
                  Re: Czego nie lubicie jako programiści? slawek <fake@fakeemail.com> - 2017-04-03 17:25 +0200
                    Re: Czego nie lubicie jako programiści? Andyy <nie@spamowac.tego> - 2017-04-03 18:12 +0200
          Re: Czego nie lubicie jako programiści? fir <profesor.fir@gmail.com> - 2017-04-02 01:00 -0700
            Re: Czego nie lubicie jako programiści? niepełnosprawny intelektualnie 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-04-05 17:39 +0200
    Re: Czego nie lubicie jako programiści? godek.maciek@gmail.com - 2017-03-30 22:55 -0700
      Re: Czego nie lubicie jako programiści? fir <profesor.fir@gmail.com> - 2017-03-31 00:20 -0700
        Re: Czego nie lubicie jako programiści? fir <profesor.fir@gmail.com> - 2017-03-31 00:32 -0700
          Re: Czego nie lubicie jako programiści? fir <profesor.fir@gmail.com> - 2017-03-31 00:47 -0700
    Re: Czego nie lubicie jako programiści? Andyy <nie@spamowac.tego> - 2017-03-31 08:45 +0200
      Re: Czego nie lubicie jako programiści? gof@somewhere.invalid (Adam Wysocki) - 2017-04-01 00:49 +0000
        Re: Czego nie lubicie jako programiści? szykcech@gmail.com - 2017-03-31 23:46 -0700
          Re: Czego nie lubicie jako programiści? Andyy <nie@spamowac.tego> - 2017-04-01 09:13 +0200
            Re: Czego nie lubicie jako programiści? Sebastian Biały <heby@poczta.onet.pl> - 2017-04-01 10:19 +0200
              Re: Czego nie lubicie jako programiści? "AK" <nobody@nowhere.net> - 2017-04-01 11:02 +0200
                Re: Czego nie lubicie jako programiści? Sebastian Biały <heby@poczta.onet.pl> - 2017-04-01 11:20 +0200
                  Re: Czego nie lubicie jako programiści? "AK" <nobody@nowhere.net> - 2017-04-01 14:47 +0200
                    Re: Czego nie lubicie jako programiści? Sebastian Biały <heby@poczta.onet.pl> - 2017-04-01 17:50 +0200
                      Re: Czego nie lubicie jako programiści? "AK" <nobody@nowhere.net> - 2017-04-01 19:48 +0200
                        Re: Czego nie lubicie jako programiści? Sebastian Biały <heby@poczta.onet.pl> - 2017-04-01 20:31 +0200
                          Re: Czego nie lubicie jako programiści? "AK" <nobody@nowhere.net> - 2017-04-01 23:44 +0200
                            Re: Czego nie lubicie jako programiści? Sebastian Biały <heby@poczta.onet.pl> - 2017-04-02 00:36 +0200
            Re: Czego nie lubicie jako programiści? "AK" <nobody@nowhere.net> - 2017-04-01 10:55 +0200
          Re: Czego nie lubicie jako programiści? gof@somewhere.invalid (Adam Wysocki) - 2017-04-01 10:47 +0000
            Re: Czego nie lubicie jako programiści? Andyy <nie@spamowac.tego> - 2017-04-01 14:40 +0200
              Re: Czego nie lubicie jako programiści? "AK" <nobody@nowhere.net> - 2017-04-01 14:51 +0200
                Re: Czego nie lubicie jako programi?ci? antispam@math.uni.wroc.pl - 2017-04-06 05:04 +0000
    Re: Czego nie lubicie jako programiści? Roman Tyczka <noemail@because.no> - 2017-03-31 09:08 +0200
      Re: Czego nie lubicie jako programiści? gof@somewhere.invalid (Adam Wysocki) - 2017-04-01 00:39 +0000
    Re: Czego nie lubicie jako programiści? Sebastian Biały <heby@poczta.onet.pl> - 2017-03-31 20:17 +0200
      Re: Czego nie lubicie jako programiści? niepełnosprawny intelektualnie 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-03-31 20:57 +0200
      Re: Czego nie lubicie jako programiści? fir <profesor.fir@gmail.com> - 2017-03-31 13:04 -0700
        Re: Czego nie lubicie jako programiści? gof@somewhere.invalid (Adam Wysocki) - 2017-04-01 00:42 +0000
      Re: Czego nie lubicie jako programiści? gof@somewhere.invalid (Adam Wysocki) - 2017-04-01 00:29 +0000
        Re: Czego nie lubicie jako programiści? Sebastian Biały <heby@poczta.onet.pl> - 2017-04-01 10:16 +0200
        Re: Czego nie lubicie jako programiści? slawek <fake@fakeemail.com> - 2017-04-01 21:27 +0200
    [OT] Czego nie lubicie jako programiści? niepełnosprawny intelektualnie 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-04-02 18:32 +0200
      Re: [OT] Czego nie lubicie jako programiści? niepełnosprawny intelektualnie 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-04-02 18:33 +0200
        Re: [OT] Czego nie lubicie jako programiści? Sebastian Biały <heby@poczta.onet.pl> - 2017-04-02 18:41 +0200
          Re: [OT] Czego nie lubicie jako programiści? niepełnosprawny intelektualnie 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-04-02 18:52 +0200
            Re: [OT] Czego nie lubicie jako programiści? szykcech@gmail.com - 2017-04-02 11:38 -0700
              Re: [OT] Czego nie lubicie jako programiści? niepełnosprawny intelektualnie 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-04-05 18:49 +0200
    Re: Czego nie lubicie jako programiści? Wojciech Muła <wojtek.mula@gmail.com> - 2017-04-02 22:04 -0700
    Re: Czego nie lubicie jako programiści? "Netteria.NET" <slawek@netteria.net> - 2017-04-08 23:48 +0200
      Re: Czego nie lubicie jako programiści? szykcech@gmail.com - 2017-04-09 21:17 -0700
        Re: Czego nie lubicie jako programiści? Roman Tyczka <noemail@because.no> - 2017-04-10 08:40 +0200
          Re: Czego nie lubicie jako programiści? szykcech@gmail.com - 2017-04-10 10:42 -0700
            Re: Czego nie lubicie jako programiści? szykcech@gmail.com - 2017-04-11 12:38 -0700
              Re: Czego nie lubicie jako programiści? slawek <fake@fakeemail.com> - 2017-04-12 10:06 +0200
                Re: Czego nie lubicie jako programiści? Tomasz Kaczanowski <kaczus@poczta.onet.pl> - 2017-04-12 10:24 +0200
                  Re: Czego nie lubicie jako programiści? slawek <fake@fakeemail.com> - 2017-04-12 13:09 +0200
                    Re: Czego nie lubicie jako programiści? Roman Tyczka <noemail@because.no> - 2017-04-12 13:30 +0200
                      Re: Czego nie lubicie jako programiści? slawek <fake@fakeemail.com> - 2017-04-12 15:10 +0200
    [OT] Czego nie lubicie jako programiści? niepełnosprawny intelektualnie 'POPIS/EU <NOSPAMtestowanije@go2.pl> - 2017-04-10 20:11 +0200
    Re: Czego nie lubicie jako programiści? Jivanmukta <jivanmukta@poczta.onet.pl> - 2017-04-14 10:34 +0200
    Re: Czego nie lubicie jako programiści? gof@somewhere.invalid (Adam Wysocki) - 2017-04-20 10:36 +0000

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#29546

W dniu piątek, 31 marca 2017 09:32:09 UTC+2 użytkownik fir napisał:
> W dniu piątek, 31 marca 2017 09:20:13 UTC+2 użytkownik fir napisał:
> > > Ja nie lubię przede wszystkim tego, że wzrok się strasznie męczy od wślepiania
> > > w monitor.
> > > No i narzekactwa ;], bo uważam, że to ogólnie strasznie fajna praca,
> > > a co do takich rzeczy, jak bezsensowne spotkania czy praca w openspejsie,
> > > to moim zdaniem "jak sobie pościelisz, tak się wyśpisz" -- z tego wszystkiego
> > > można się łatwo wykręcić [jak komuś zależy to, może nawet pracować w 100%
> > > zdalnie].
> > 
> > dla mnie najgorsze jest (jak w sumie ostatnio pisalem) moje wlasne zmeczenie, swoisty rodzaj 'wyczerpania' 
> > 
> > jak ostatnio zauwazylem jak jestem w pelni wypoczety 
> > to koduje bardzo ladnie i okolo 5-10 razy sztbciej
> > (moze nawet blizej 10 niz 5, statystycznie mozna by przyjac 7-8)  niz wtedy gdy jestem juz wyczerpany i czuje sie znudzony (gdy jestem BAARDZO zmeczony ta energia jeszcze spada ze dwa trzy razy ale to przypadki juz raczej patologiczne)
> > 
> > (z tego wynika ze mozna matematycznie policzyc ze
> > o wiele bardziej oplacalne jest kodowanie z duza iloscia
> > odpoczywania niz bez niego - gdy caly czas koduje na 15% mocy - dokladny wzór niestaty zalezy jednak od czasu potrzebnego do pelnego wypoczęcia i od czasu na ktorym
> > mam sustain owej 100% mocy - nieststy nie znam dokladnie tych czasow, ten pierwszy jest nieststy dosyc dlugi 
> > na 100% wiecej niz tydzien a byc moze nawet sporo 
> > dluzej.. drugi czas (sustain na 100%) moze byc byc moze rozny, ostatnio bylo to 10-12 dni
> > 
> 
> nawet nie znajac tego czasu odpoczywania mozna w kazdym razie wyliczyc ze o ile pracowanie na wypocz4eciu daje 7 razy tyle co na zmeczeniu to 7*10 dni na wypoczeciu = 70 dni na zmeczeniu czyli ciegle paracowanie na zmeczeniu rowna sie 10 dni na wypoczeciu + 60 dni urlopu
> 
> z tego moim zdaniem wynika ze nie nalezy sie bronic przed
> wypoczywaniem.. nalezaloby tylko odnalezc wlasciwy najkorzystniejszy rytm: pelne (acz racjonalne) odpoczywanie + pelny okres roboty na wypoczeciu i tak w kolko - czlowiek ma tendencje do gubienia tego rytmu, tj albo zmuszam sie do pracy jak jestem przycmiony (robiac zapewne zle) albo jak juz odpoczywam odpoczywam dalej gdy defakto mozna by tej energii troche zmienic w kod - znalezienie jednak tej odpowiedniej ilosci odpoczywania nie jest jednak takie proste + wchodza zyciowe komplikacje (np ostatnio bardzo zle wyniki krwii i ciagle bole serca, rak i nog tez caly dzien zwlaszcza po obudzeniu)
> 
> 
> 

ostatnio co prawda wogole nie mam umyslowo formy, forme
tutaj mierzylbym pewnego rodzaju glebokoscią (jej przeciwienstwo zmierza natomiast w kierunku plytkosci),
mozliwe ze to w zwiazku z tymi zlymi wynikami i zlymi odczuciami oraz ew z wiekiem (very bad)
> 
> > 15% mocy to dla mnie zrobienie 2-3 prostych rzeczy na dzien (co zajmie ze 3 godziny ale jak jestem zmeczony nie chce mi sie zmusic do tego by dlubac dluzej i ew musze
> > powoli rozmyslac) 100% mocy to dla mnie zrobienie kilkunastu (pewnie pod 20) takich rzeczy na dzien 
> > (troche zalezy jak liczyc bo kazde takie male zadanie sklada sie z kilku elementow i wchodzi jeszcze debugowanie itd)
> > 
> > ogolnie ten temat zmeczenia jest ciekawy i bardzo praktyczny, trzeba to rozkminic by umiec lepiej sobie z tym radzic

[toc] | [prev] | [next] | [standalone]

#29541

W dniu 30.03.2017 o 21:48, Adam Wysocki pisze:
> Taki temat... pomyślałem że może być ciekawie zarzucić go tutaj. Czego nie
> lubicie w tej pracy, co Was denerwuje?

Nie lubię że w C++ nie ma modułów i czasem zgłasza błąd nie w moim 
kodzie ale w bibliotecznych headerach.
No i czasem nie można linkować z tego powodu, że chce podkreślenia w 
nazwach funkcji a tam ich nie ma lub na odwrót.

[toc] | [prev] | [next] | [standalone]

#29561

Andyy <nie@spamowac.tego> wrote:

> No i czasem nie można linkować z tego powodu, że chce podkreślenia w 
> nazwach funkcji a tam ich nie ma lub na odwrót.

Jakie podkreślenia?

-- 
http://www.chmurka.net/

[toc] | [prev] | [next] | [standalone]

#29562

> > No i czasem nie można linkować z tego powodu, że chce podkreślenia w 
> > nazwach funkcji a tam ich nie ma lub na odwrót.
> 
> Jakie podkreślenia?

np.: jakas_fana_funkcja()
Wyrazy są oddzielone podkreśleniami - aż dziwne, że się z tym nie spotkałeś?!? Szczególnie w świecie Gnu i C to lubią... W Qt całe szczęście tego nie ma.

[toc] | [prev] | [next] | [standalone]

#29563

W dniu 01.04.2017 o 08:46, szykcech@gmail.com pisze:
>>> No i czasem nie można linkować z tego powodu, że chce podkreślenia w
>>> nazwach funkcji a tam ich nie ma lub na odwrót.
>>
>> Jakie podkreślenia?
>
> np.: jakas_fana_funkcja()
> Wyrazy są oddzielone podkreśleniami - aż dziwne, że się z tym nie spotkałeś?!? Szczególnie w świecie Gnu i C to lubią... W Qt całe szczęście tego nie ma.
>
Jak wyrazy są podzielone, to jeszcze nic, ale mogą zaczynać się:
- bez podkreślenia
- z jednym
- z dwoma
i kompilator może dodawać lub nie

[toc] | [prev] | [next] | [standalone]

#29565

On 4/1/2017 9:13 AM, Andyy wrote:
> Jak wyrazy są podzielone, to jeszcze nic, ale mogą zaczynać się:
> - bez podkreślenia
> - z jednym
> - z dwoma
> i kompilator może dodawać lub nie

Kompilator (C/C++ jak mniemam) ma jakiś konkretny styl manglowania 
nazwy. Jesli programista pisze kod zamiast hackować to *nigdy* nie 
spotka się z taki problemem żeby mu kompilator coś zmieniał i było to 
dla programisty *widoczne*. Natomiast tak, hackerów takie problemy 
czesto spotykają. Wniosek: pisać kod a nie hackować.

[toc] | [prev] | [next] | [standalone]

#29570

Użytkownik "Sebastian Biały" <heby@poczta.onet.pl> napisał:
> Kompilator (C/C++ jak mniemam) ma jakiś konkretny styl manglowania

Zle mniemasz :(.
Powino byc:
"Kompilator C ma scisle okreslony styl manglowania,"
ale i owszem:
"Kompilator (C++) ma jakiś konkretny styl manglowania."

> nazwy. Jesli programista pisze kod zamiast hackować to *nigdy* nie spotka się z taki problemem 
> żeby mu kompilator coś zmieniał i było to dla programisty *widoczne*. Natomiast tak, hackerów 
> takie problemy czesto spotykają. Wniosek: pisać kod a nie hackować.

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++.
Wtedy nawet takie podejscie w C++:

extern "C"
{
#include <header_czystego_C.h>
}

ma sens

AK

[toc] | [prev] | [next] | [standalone]

#29571

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.

[toc] | [prev] | [next] | [standalone]

#29574

Użytkownik "Sebastian Biały" <heby@poczta.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

[toc] | [prev] | [next] | [standalone]

#29576

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

[toc] | [prev] | [next] | [standalone]

#29577

Użytkownik "Sebastian Biały" <heby@poczta.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

[toc] | [prev] | [next] | [standalone]

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

[toc] | [prev] | [next] | [standalone]

#29580

Użytkownik "Sebastian Biały" <heby@poczta.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

[toc] | [prev] | [next] | [standalone]

#29581

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.

[toc] | [prev] | [next] | [standalone]

#29569

Użytkownik "Andyy" <nie@spamowac.tego> napisał:

> Jak wyrazy są podzielone, to jeszcze nic, ale mogą zaczynać się:
> - bez podkreślenia
> - z jednym
> - z dwoma
> i kompilator może dodawać lub nie

Do ksiazek (standard C/C++) Kolego :)
To nie wina kompilatora, ale Twojej niewiedzy w temacie.
Zlikwidowanie niedomogi zajmnie Ci max 30min (bo to drobnostka jest).

Hint:
extern "C" void aaa(int i);
a:
void aaa(int i);
extern "C++" void aaa(int i);

to sa dla linkera dwie zupelnie inne funkcje.

AK

[toc] | [prev] | [next] | [standalone]

#29572

szykcech@gmail.com wrote:

>> > No i czasem nie można linkować z tego powodu, że chce podkreślenia w 
>> > nazwach funkcji a tam ich nie ma lub na odwrót.
>> 
>> Jakie podkreślenia?
> 
> np.: jakas_fana_funkcja()
> Wyrazy są oddzielone podkreśleniami - aż dziwne, że się z tym nie spotkałeś?!? Szczególnie w świecie Gnu i C to lubią... W Qt całe szczęście tego nie ma.

Spotkałem, ale czemu nie można przez to linkować?

-- 
[ Email: a@b a=grp b=chmurka.net ]
[ Web:   http://www.chmurka.net/ ]

[toc] | [prev] | [next] | [standalone]

#29573

W dniu 01.04.2017 o 12:47, Adam Wysocki pisze:
> Spotkałem, ale czemu nie można przez to linkować?

Nie zawsze, ale gdy jest jedna wersja GNUC a druga Visual C++ i metody 
mają jakieś deklaracje zdefiniowane w plikach .h zależne od innych .h to 
mogą być problemy.
Pojawiło się na przykład w Java native function (JNI):
W przypadku VC dodaje podkreślenia do nazw funkcji i jest dobrze ale GCC 
nie dodaje. Są opcje "-Wl,--kill-at" czy -fleading-underscore
ale też nie pomagają czasem

[toc] | [prev] | [next] | [standalone]

#29575

Użytkownik "Andyy" <nie@spamowac.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 

[toc] | [prev] | [next] | [standalone]

#29600 — Re: Czego nie lubicie jako programi?ci?

AK <nobody@nowhere.net> wrote:
> U?ytkownik "Andyy" <nie@spamowac.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.

Moze wiekszosc windowsowych.  Typowe Linuxowe kompilatory C _nie_
dodaja podkreslen (chyba ze wycianiesz jakis antyk).  Takie rzeczy
jak pliki obiektowe, biblioteki itp sa poza standardem C.
Standartwy kompilator C moze generowac program binarny w RAM bez
zadnej mozliwosc zapisania go na dysku.  Standard nie zabrania
robienia interpretera (sa takie, moga sie przydac do debugowania).

Pod Linux specyfikacja ELF nakazuje uzycie nazw w binarkach
takich jak w zrodle C.  Jak ktoras implementacja sie do tego
nie stosuje to nie znaczy ze lamie standard C -- lamie
specyfikacje ELF.

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

Pod windows 32-bit to jest cale zoo konwencji laczenia,
jak programista w tym namiesza to moga byc problemy...

-- 
                              Waldek Hebisch

[toc] | [prev] | [next] | [standalone]

#29542

On Thu, 30 Mar 2017 19:48:48 +0000 (UTC), Adam Wysocki wrote:

> Taki temat... pomyślałem że może być ciekawie zarzucić go tutaj. Czego nie 
> lubicie w tej pracy, co Was denerwuje?
> 
> Ja odpowiedziałem tutaj:
> 
> https://www.quora.com/What-do-programmers-hate/answer/Adam-Rex-4

Mógłbym taką listę zrobić o np. mechanice pojazdowej, albo stolarce.

Zatem ...zmień zawód, programowanie nie jest dla Ciebie ;-)

-- 
pozdrawiam
Roman Tyczka

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | pl.comp.programming

csiph-web