SOURCES: poldek-cookie.patch - was doing a lot of these seeks, use...

[Arkadiusz Miskiewicz]

On Thursday 21 of April 2005 03:39, Patrys :: Patryk Zawadzki wrote:

Zbiorczo:

> Dnia 21-04-2005, czw o godzinie 01:02 +0200, Jakub Bogusz napisał(a):
> > On Thu, Apr 21, 2005 at 12:38:55AM +0200, Arkadiusz Miskiewicz wrote:
> > > > Wygląda na workaround metodą gwałtu analnego :D
> > >
> > > Pomijając, że nie sprawdza czy alokacja się udała (wynik fseeka też nie
> > > był sprawdzany choć hmm, chyba jak fseek się nie uda to po prostu nic
> > > się nie zmienia jeśli chodzi o wskaźnik pozycji w strumieniu) to z czym
> > > jest problem?
>
> Nie ma problemu, tylko przykro, że trzeba takie obejścia robić...
No niestety.

>
> > Jeszcze drugi podobny fseek() został - tylko z odczytaną 16-bitową liczbą
> > jako parametrem.
Chodzi o ten w pkguinf_restore() ? Tam właściwie nie wiadomo czy przesuwa się 
do przodu czy do tyłu, a na dodatek ftell() w glibc 2.3.5 woła seek()'a z 
filecookie więc nie wiem czy się uda zrobić taki myk by sprawdzać ftellem 
gdzie się jest vs żądany offset tak by działało to szybciej niż obecnie :-/

> > BTW: temu powyższemu nie zdarza się mieć jakiegoś dużego argumentu?
> > Myślałem o sprawdzaniu size i w zależności od niego robienia fread()
> > lub fseek() - bo jak skądś się weźmie duża liczba 32-bitowa (choćby
> > z uszkodzonego indeksu), to poleci...
Teraz jest wersja z mallocem - tych wywołań afaik nie było zbyt wiele.

> A nie można zrobić w pętli fseeka aż wyczerpie parametr?
Chodzi o to by nie  używać w ogóle fseeka, patrz któryś poprzedni post qboosha 
o tym, że gzseek szuka cofając się do 0 i odczytując offset skompresowanego 
strumienia jeśli chcesz się cofnąć co jest woooooooooolne.

-- 
Arkadiusz Miśkiewicz                    PLD/Linux Team
http://www.t17.ds.pwr.wroc.pl/~misiek/  http://ftp.pld-linux.org/