nicht angemeldet
Hoi,
na, *das* nenne ich doch mal eine 'konstruktive Kritik' -- danke!
Jaja, da bemüht man sich und bekommt es dann noch um die Ohren gehauen.
Das Schlimmste ist ja: sogar noch zu Recht! ;-)
Hae?
Weder getpid(), close() noch unlink() sind ANSI C 99.
Von close() wusste ich das ja. Aber bei getpid() und unlink() haett ich das
jetzt nicht gedacht. Auf welche Ersatz-Funktion sollte man denn zugreifen,
anstelle von unlink()?
unistd.h übrigens auch nicht ;-)
Ach ne ;-)
BTW: ist das evt keine gute Idee auf allzuviele nicht ANSI C Funktionen
zurückzugreifen?
Ja. Im Moment sind es zwei. Wenn du mir sagst, wie ich das noch weiter
reduzieren kann... ich muss halt irgendwie ein eindeutiges Merkmal erhalten
(deshalb getpid()) und irgenwie die Datei wieder entfernen.
Zeile 234: malloc() ohne Überprüfung? Ganz böse Falle, aber wirklich
_ganz_ böse!
Find ich gar nicht. Wann sollte *heutzutage* noch ein malloc()
fehlschlagen, gerade wenn es nur um ein paar Bytes geht?
Da Du nicht weißt, wie malloc() auf der jeweiligen Architektur funktioniert,
gibt es einige Gründe.
Nenn mir mal einen, damit mein Verstaendnis dafuer waechst ;-)
Kannst Dein malloc() an den meisten Stellen eh ganz weglassen.
Sicher, aber dann muesste ich mit festen Groessen arbeiten (Arrays), und das
moechte ich moeglichst vermeiden. So kann ich die Groesse ziemlich genau
bestimmen.
(Hatte ich nicht von Dir neulich mal einen Preis bekommen für die "most
useless pipe", oder war das der Michael? ;-)
Nein, ich hatte gesagt, das sei 'useless use of a pipe' -- aber meinetwegen
koennen wir gerne einen Preis draus machen *g*
und weder strcpy() noch strcat() sind eigentlich zu empfehlen.
Warum?
strcpy() weil in Deinem Fall tempfile = cfile (+ der danach notwendigen
Änderungen) besser gewesen wäre, hätte auch die Speicherallokation gespart.
(Nur die Adresse wird kopiert)
Aber dann haette ich die Zahl wieder hinten dran gehabt, und auch haette ich
das Problem, dass evntl. die Laenge zu gross wird.
strcpy() kann in die Hose gehen, wenn Argument 1 kein regulärer C String
ist (kein \0 am Ende).
Ja, das weiss ich. Damit kann ich umgehen, es ist ja in dem Fall
sichergestellt, dass die Strings 0-terminiert sind.
[... strncpy(), strncat() ...]
Das setze ich auch ein. Wenn ich mich nicht drauf verlassen kann. Aber hier
sehe ich den Sinn nicht.
(Bin ich denn eigentlich nur blind? Ich bin da auch noch fast alles im Code
nachgegangen. Nunja, "fast" alles trifft es da gut ;-)
Hae?
Zeile 271: Memory Leak! gz ist noch nicht freigegeben vor dem return!
Bitte wie? 'gz' sollte doch fclose() freigeben, ich habe den Speicher
schliesslich nicht angefordert.
Ja und?
Wenn ich den Speicher nicht explizit angefordert habe, dann muss IMHO bei der
Beschreibung der Funktion ganz fett und in Grossbuchstaben, unterstrichen und
blinkend stehen 'You have to free() the memory!' ;-)
Das halte ich fuer ganz, ganz schlechten Code.
;-)
Aber ist immer besser. Wer weiß, welcher Compiler da dran geht. Kann ja
nicht immer GCC sein ;-)
Jaja, ich weiss ja *noergel* ;-)
Zeile 348: *gzip != 0 passt nicht. Die Stelle auf die der Pointer zeigt
ist Type char, 0 ist Type int.
Zum Glueck weiss der Compiler das auch und macht daraus einen char :-)
Was suchst Du da eigentlich? \0, also Ende vom String?
Ja.
NULL, also Ende vom Speicher?
Hae? Seit wann sind Felder NULL-Terminiert, wenn man das nicht per Hand macht?
'0', die Zahl Null als Buchstabe?
Noe.
Dann schreib das doch einfach ;-)
'\0' sind drei Buchstaben mehr *jammer* ;-)
time() kann versagen, localtime() kann versagen.
Warum?
Irgendwie sieht das sowieso komisch aus. Ich mache bei time() immer:
time_t t;
time(&t);
time(NULL) habe ich noch nie gesehen ;-)
Lies mal time(3) ;-)
Da steht:
SYNOPSIS
#include <time.h>
time_t
time(time_t *tloc);
[...]
The time() function returns the value of time in seconds since 0 hours, 0
minutes, 0 seconds, January 1, 1970, Coordinated Universal Time.
A copy of the time value may be saved to the area indicated by the
pointer tloc. If tloc is a NULL pointer, no value is stored.
Du siehst: 'a copy of the time value'.
BTW: NULL kann auch als (void)(0) definiert sein. (Ich z.B. mache das immer)
Das passt dann nicht in time() rein. Gibt zumindest 'ne Warnung.
Warum machst du sowas auch? ;-)
BTW: welche Optimierung verträgt er eigentlich?
Schonmal ausprobiert?
Nein.
Diese Optimierungen vom GCC sind mir suspekt...
Ich hab da ganz schlimme Dinge gehoert, z. B. sowas wie Aufrollen von
Schleifen *schuettel*
zum Schluss. Das
mit der 'filename.conf' war mehr oder weniger ein Release-Quickhack, damit
ich bei den Binaries nicht den Cache-Pfad fest einkompilieren muss.
Könnte ja jetzt sagen: "So sieht's auch aus!", aber wer bin ich denn ;-)
Wieso?
Zugegeben, es mag vielleicht keine Loesung im C-Style sein. Aber sie ist doch
einfach und elegant?
Dadurch hast Du aber auch noch eine globale Variable, die Du ganz schlecht
wegbekommst. (Die andere (LgFile) ist einfach)
Och, wir werden sehen. Frueher war das halt ein '#define'.
gzip_cncc.c:632:6: Test expression for if not boolean, type int: may_gzip()
steht da ja auch! Und ich wollte gerade wieder meinem Lint die Schuld in die
Schuhe schieben ;-)
Hehe ;-)
Da es in C keine Booleans gibt, halte ich die Fehlermeldung fuer falsch.
(Das void steht bei mir aber nicht! ;-)
Dann guck dir mal den aktuellen Sourcecode an ;-)
Nein, noch lange nicht ;-)
Gibt es einen Switch, der alle Warnungen ausgibt?
Wenn Du das Revidierte oben hast, sag doch mal eben Bescheid.
Bescheid.
Scheiß Lint!
*grummel* ;-)
Hoehoe ;-))
BTW: Bennen Doch bitte Dein Makro EXPIRE um, alle Makros mit dem
Anfagsbuchstaben "E" sind reserviert. Mach einfach CNC_EXPIRE o.ä.
[x] Done. Aber noch nicht hochgeladen.
PS: sehe ich gerade. Schau doch mal ganz oben in die Zeile, wo Dein Name
steht. Ja, genau ;-)
Na, da siehst du mal: ich bin selbst zu bloed, meinen Namen zu schreiben ;-))
Warum meinst Du eigentlich, das eine PID bis zu 1024 Stellen haben kann?
Nur so als Frage ;-)
Wer sagt, dass ich das meine? ;-)
Ich verwende 'buff' noch etwas spaeter, als fread()-Buffer.
Gruesse,
CK