On Mon, 15 Apr 2019 at 17:53, Mihai Barbulescu <b12mi...@gmail.com> wrote: > > Salut Paul, > > Acestea nu sunt definitii oficiale > > On Mon, 15 Apr 2019 at 12:47, Paul Olaru <olarupaulstelia...@gmail.com> wrote: > > > > Comportament ciudat: mă gândeam la situația în care libc și-ar reinițializa > > heap-ul după ce am dat so_exec_start și astfel bufferele din > > printf/fprintf/... nu mai sunt partajate cu programul, nu mai sunt > > flushuite corespunzător etc. Nu sunt sigur că se comportă așa sau nu, eu > > voi merge pe presupunerea asta și mă voi rezuma la a folosi doar apeluri de > > sistem pentru implementare. > > Nu te mai gandi la nimic. Daca nu e documentat in: > - manpage-ul libc-ului > - issue ridicat de developer/tester > Atunci acea problema __nu exista__
Un amendament aici: daca problema totusi exista si esti convins de ea -> se ridica bug si se specifica cum se reproduce. > > Daca nu stii sigur si ai nevoie de validarea unui > comportament/presupunere sunt doua solutii in viata reala (dar si la > temele SO) pe care le aplici: > - se face un program cat mai mic posibil de test si se valideaza sau > nu o presupunere > - se verifica documentatia daca specifica sau nu acel comportament > Asa cum faceai si la matematica metoda reducerii la absurd - > presupuneai ceva apoi gaseai contra-exemplu care sa invalideze > presupunerea. Cealalta solutie era inductia: porneai de la un caz > particular pe care il validai apoi generalizai prin presupunere prin > inductie si o validai si p-aia. > > Daca ai neclaritati asupra functionarii functiei so_start_exec din > scheletul temei 3 deschide un thread nou si pune intrebari punctuale, > cu fraze cat mai scurte si clare, iar cei care au facut scheletul vor > lamuri. > > > > > Cheaty: La tema anterioară nu puteam folosi fprintf pt a implementa > > so_fprintf -- asta ar fi fost cheaty. La SD, nu puteam folosi std::map > > pentru a implementa ceva echivalent lui. > > > > Ceea ce spui tu aici se numesc restrictii si trebuie sa tii cont de > ele in orice situatie. Nu mai folositi cuvinte complicate pentru > concepte simple. Iar presupunerea la SO este: daca nu s-a dat o > restrictie in enuntul unei teme => ai voie cu orice (asa cum i-am > clarificat lui Alice). > > Spor la lucru. > > > On Mon, Apr 15, 2019, 12:43 PM Mihai Barbulescu <b12mi...@gmail.com> wrote: > >> > >> Salut, > >> > >> Iar am probleme cu vocabularul vostru si devin din nou confuz. Ce e aia: > >> - functie libc care se comporta ciudat? -> defineste conceptul > >> "comportament ciudat" ca sa imi calibrez limbajul pe frecventa ta -> > >> da-mi si exmplele la care te gandesti, eu unul nu am in minte nici o > >> functie __standard__ care se comporta ciudat. Daca exista asa ceva a > >> fost marcata ca deprecated si inlocuita! > >> - implementare in mod cheaty -> ce-i aia mod cheaty, defineste-mi? > >> Da-mi exemplu de functie care face asta > >> > >> In standarde precum libc nu se pun functii "periculoase" sau "cheaty" > >> sau whatever le numiti voi. Se pun functii care au trecut de un amplu > >> proces de review si validare. Singurul lucru de care trebuie tinut > >> cont e daca functiile sunt sau nu thread safe atunci cand programati > >> multithreaded...ATAT. Daca se comporta ca mai sus => se ridica bug cu > >> severitate mare la libc... > >> > >> Va rog sa va luati un moment de a revizui textul scris ca sa putem > >> vorbi pe aceeasi frecventa si sa fim sincronizati. > >> > >> On Mon, 15 Apr 2019 at 12:27, Paul Olaru <olarupaulstelia...@gmail.com> > >> wrote: > >> > > >> > Pe scurt, dacă e o funcționalitate oferită de sistemul de operare e ok > >> > și putem folosi ce ne oferă acesta fără restricții, și tot ce e de > >> > evitat e doar folosirea funcțiilor din libc care ori s-ar comporta > >> > ciudat ori ar implementa într-un mod cheaty funcționalitatea dorită? > >> > (Notă, la tema asta nu cred că e nimic în a doua categorie dar ar putea > >> > fi câteva în prima) > >> > > >> > On Mon, Apr 15, 2019, 12:24 PM Mihai Barbulescu via so > >> > <so@cursuri.cs.pub.ro> wrote: > >> >> > >> >> Buna Alice, > >> >> > >> >> Si eu sunt confuz din doua motive: > >> >> 1. Formularea ta: alea nu sunt semnale, par a fi chestii pe care le > >> >> primesti in siginfo_t in si_code [1],[2] > >> >> 2. Nu vad de ce ar fi interzis sa verifici structura siginfo_t si > >> >> continutul ei daca te ajuta in rezolvare, e aceasta restrictie > >> >> mentionata pe undeva? > >> >> > >> >> [1] https://www.mkssoftware.com/docs/man5/siginfo_t.5.asp > >> >> [2] > >> >> https://elixir.bootlin.com/linux/latest/source/include/uapi/asm-generic/siginfo.h#L221 > >> >> > >> >> On Mon, 15 Apr 2019 at 11:10, Adrian Șendroiu via so > >> >> <so@cursuri.cs.pub.ro> wrote: > >> >> > > >> >> > Bună, > >> >> > > >> >> > La ce te referi mai exact? Alea nu sunt semnale. > >> >> > > >> >> > On Mon, 15 Apr 2019 at 10:22, Alice Suiu via so > >> >> > <so@cursuri.cs.pub.ro> wrote: > >> >> > > > >> >> > > Buna ziua, > >> >> > > > >> >> > > Este permis ca in cadrul rezolvării temei de pe Linux sa ne folosim > >> >> > > de semnalele SEGV_MAPERR si SEGV_ACCERR pentru a verifica dacă o > >> >> > > pagina este mapata sau nemapata? > >> >> > > > >> >> > > Mulțumesc, > >> >> > > Alice Suiu > >> >> > > _______________________________________________ > >> >> > > http://ocw.cs.pub.ro/courses/so/info/lista-discutii > >> >> > _______________________________________________ > >> >> > http://ocw.cs.pub.ro/courses/so/info/lista-discutii > >> >> > >> >> > >> >> > >> >> -- > >> >> Cu stimă, > >> >> Mihai Bărbulescu > >> >> _______________________________________________ > >> >> http://ocw.cs.pub.ro/courses/so/info/lista-discutii > >> > >> > >> > >> -- > >> Cu stimă, > >> Mihai Bărbulescu > > > > -- > Cu stimă, > Mihai Bărbulescu -- Cu stimă, Mihai Bărbulescu _______________________________________________ http://ocw.cs.pub.ro/courses/so/info/lista-discutii
