Re: [tyndur-devel] [PATCH] Neue POSIX-Funktionen

[Max Reitz <max@xxxxxxxxxx>]

Am 30.01.2011 11:52, schrieb Arne Hasselbring:
>>> +	}
>>> +	fclose(handle);
>>> +	return 0;
>>> +    } else {
>>> +	errno = EAGAIN;
>>> +	return -1;
>>>       
>> Wieso ist es ein Fehler, wenn die Dateigröße auf die aktuelle Größe
>> gesetzt werden soll (diff == 0)?
>>     
> Das ist kein Fehler, sondern viel mehr wird das nie passieren. Siehe:
> +    int cur_len = ftell(handle);
> +    int diff = length - cur_len;
> +    if (diff == 0) {
> +       return 0;
> +    }
> Schon dort wird ohne Fehler zurückgekehrt. Aber gcc fände das nicht in 
> Ordnung, glaube ich, dass am Ende nirgends was zurückgegeben wird. 
> Alternative:
> if (diff > 0) { ... }
> else if (diff < 0) { ... }
> else { return 0; }
> Also ich meine damit, dass man die if-Struktur umstellen müsste.
>   
Oh, gar nicht gesehen, na dann. ^^
>> +    if (diff < 0) {
>> +     char *data = malloc(cur_len);
>> +     fseek(handle, 0, SEEK_SET);
>> +     fread(data, cur_len, 1, handle);
>> +     char *buffer = malloc(length);
>> +     memcpy(buffer, data, length);
>> +     free(data);
>> +     fclose(handle);
>> +     handle = fopen(path, "w");
>> +     fwrite(buffer, length, 1, handle);
>> +     free(buffer);
>> +     fclose(handle);
>> +     return 0;
>>   
>>     
> Ich habe mich natürlich auch gefragt, ob das nicht schneller geht als erst die 
> ganze Datei einzulesen, auf eine bestimmte Länge zu kopieren, die Datei 
> komplett zu leeren und dann den verkürzten Inhalt wieder da rein zu schreiben.
> Wenn LIOv2 so eine Funktion hat, ist das gut, aber zu Zeit ist mir keine 
> bessere Lösung eingefallen, schließlich ist dies ja gerade die Funktion, die 
> man aufruft, wenn man eine Datei verkürzen will (->Lowlevel, so sehe ich das 
> zumindest).
>   
Es geht schon schneller, nur muss man dazu eben Funktionen des
Dateisystemtreibers verwenden. Das meinte ich mit "auf LIOv1-Ebene
implementieren".
>   
>>> +    } else if (diff > 0) {
>>> +     fseek(handle, 0, SEEK_END);
>>> +     int i;
>>> +     for (i = 0; i < diff; i++) {
>>> +         fprintf(handle, "%c", 0);
>>>   
>>>       
>> fprintf ist hier wohl eher ein Overkill, fputc reicht doch, wobei
>> es wohl noch besser wäre, wenn man ganze Speicherblöcke mit Nullen
>> auf einmal schreibt.
>>     
> Jetzt wo du's sagst, Speicherblöcke hätte ich natürlich nehmen können.
> Wo ist denn der Unterschied zwischen fprintf und fputc? Sind doch sowieso nur 
> Front-Ends, glaube ich.
>   
Das mag sein, aber ein fprintf rechnet normalerweise nicht damit, dass
man nur ein einziges Zeichen ausgeben will. Das ist dafür ausgelegt,
einen langen Formatstring zu parsen, deshalb dauert der Aufruf wohl um
einiges länger als ein fputc-Aufruf.
> Fazit von meiner Seite: Natürlich ist die Funktion nicht optimal, 
> wahrscheinlich ist sie sogar vom Design her schlecht, aber sie hat 
> funktioniert und das war für mich ausschlaggebend.
>   
OK. Ich hoffe, du bist mir nicht böse, dass ich das dennoch ob meiner
Bedenken nicht acke. ;-)