Da, daca fac presupunerea asta nu mai apare problema specificata. Insa e o presupunere complet gresita. Read nu garanteaza ca va citi cat ii dam noi, asa ca nu ne putem baza pe asa ceva. Testul in sine e cel mai simplu. Face doua so_fgetc. Primul populeaza, teoretic, bufferul, al doilea citeste din buffer. Testul vrea un singur apel de read pentru ca al doilea so_fgetc ar trebui sa citeasca din buffer, nu printr-un read. Ce e de facut?
În dum., 15 mar. 2020 la 22:24, Paul Olaru <[email protected]> a scris: > Bine, nu știu cum e testul în sine. Dacă so_fread e apelat cu maxim 14 tu > nu ar trebui să faci mai multe citiri. Când bufferul e gol și ai nevoie de > date faci o singură citire, chiar dacă e sub cât are nevoie bufferul ca să > se umple. > > On Sun, Mar 15, 2020, 22:21 Paul Olaru <[email protected]> > wrote: > >> Cred că există o presupunere (nu tocmai validă) în checker că poți >> profita de faptul că dacă un apel read ți-a returnat mai puțin decât i-ai >> cerut singurul motiv ar fi EOF. >> >> Dacă faci chestia asta îți trec toate testele? >> >> On Sun, Mar 15, 2020, 22:18 Vlad Lungu via so <[email protected]> >> wrote: >> >>> Salut, >>> Primesc aceasta eroare. Checkerul asteapta sa fac o singura operatie >>> de read pentru a popula bufferul. Eu fac fix ca la laborator. Intr-o bucla >>> while testez daca mai am de citit. Daca a umplut bufferul sau apelul read a >>> intors 0(eof), ies din bucla. Initial bufferul e 4096, citeste 14. Nu a >>> intors 0, deci nu marcheaza eof si nu iese. Nu a umplut bufferul, deci nu >>> iese. Astfel, face un al doilea apel de sistem, care intoarce 0 si iese din >>> bucla. O solutie pe care o vad pentru a trece de checker e sa retin undeva >>> si dimensiunea fisierului. in momentul in care dimensiunea fisierului a >>> fost atinsa, iese. Asta se doreste? >>> _______________________________________________ >>> http://ocw.cs.pub.ro/courses/so/info/lista-discutii >> >>
_______________________________________________ http://ocw.cs.pub.ro/courses/so/info/lista-discutii
