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/ _______________________________________________ pld-devel-pl mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
