[so] [Tema 3] Extindere funcții wrapper

[Adrian Stanciu]

2016-04-08 13:35 GMT+03:00 Călin Cruceru <so at cursuri.cs.pub.ro>:
> Salutare,

Salut, Călin,

> Legat de partea în care se menționează că suntem încurajați să
> extindem fișierele common.h și common_lin/win.c cu wrappere proprii:
> părerea mea e că exprimarea asta lasă de înțeles că ar trebui să luam
> fișierele (atât headerul _cât și implementarea_) și să adăugăm noi
> declarații de wrappere și implementările lor, ceea ce e riscant și
> chiar bad practice, cred.

Se încurajează utilizarea wrapper-elor la această temă iar fișierele
din checker sunt un punct de start. Trebuie avut în vedere că
implementarea wrapper-elor din checker este cea de care checker-ul are
nevoie. El nu se așteaptă să primească aceste funcții din biblioteca
voastră pentru că interfața definită pentru bibliotecă nu conține și
acele wrapper-ele.

> Este riscant pentru că în felul acesta am avea toate funcțiile
> implementate de 2 ori în momentul linkării executabilului generat de
> framework-ul de testare: odată în shared library și odată din
> common_lin/win.o compilat de framework.  Astfel că dacă vrei la un
> moment dat să modifici unul din wrapperele _deja implementat_, o să ai
> surpriza că nu se apelează implementarea ta, ci cea din
> common_lin/win.o, din motive pe care nu pot să spun că le înțeleg prea
> bine.  Poate aduce cineva clarificări legat de asta?  De ce preferă
> linkerul implementările din obiecte, decât cele din shared library?
> Am găsit ceva asemănător cu asta, dar totuși nu e aceeași situație[1].

Ai dreptate, se vor apela cele din checker. Dar wrapper-ele definite
de checker sunt oarecum standard, eu nu am avut nevoie să le modific
în implementarea mea (iar la unele am renunțat pentru că nu îmi erau
utile).

În comanda de link-are se precizează întăi fișierele obiect iar la
final bibliotecile cu care se link-ează. Linker-ul parcurge fișierele
obiect de la stânga la dreapta și reține pentru ce simboluri nu a
găsit implementare, simboluri undefined ce sunt apoi căutate în
biblioteci. În cazul în care într-un fișier obiect avem definită o
funcție atunci aceea va fi folosită la apeluri pentru că definiția
respectivă este prima văzută de linker (și nu are nevoie să caute una
în biblioteci).

libc-ul are nume rezervate [2] pentru acele funcții folosite doar
intern (cele ce încep cu underscore-uri) cu scopul de a minimiza
conflictele de nume cu cele definite în sursele utilizatorului. Cea
mai ușoară soluție ar fi să redenumești wrapper-ele dacă le schimbi
implementarea.

>
> Modul de organizare corect în cazul acesta, cred că este următorul: se
> include common.h (cel din framework-ul de testare) din alt fișier
> header - să-i zicem lib_wrappers.h - și se adaugă în lib_wrappers.h
> declarațiile noilor wrappere iar in lib_wrappers.c definițiile lor.
> Și peste tot în implementarea lib-ului vom folosi lib_wrappers.h.  În
> felul acesta ne asigurăm prin design că suntem API compliant cu
> framework-ul de testare și nu avem mai multe definiții cu același
> nume.

Nu îmi este clar argumentul tău. Chiar dacă sunt în alt fișier, dar cu
același nume, există posibilitatea unui conflict de nume.

> PS: Dacă sunt singurul care a înterpretat inițial exprimarea din enunț
> în felul acesta, ignorați acest e-mail.
>
> PSS: Evident că o întrebare legit e "de ce ai modifica funcțiile
> existente?"; un răspuns la fel de legit e "debugging".  Dar oricum,
> asta nu schimbă flaw-ul în design.
>
> [1]: http://stackoverflow.com/questions/6538501/linking-two-shared-libraries-with-some-of-the-same-symbols
>

[2] http://www.gnu.org/software/libc/manual/html_node/Reserved-Names.html


Numai bine,
Adrian