datei operationen
-
Wieso passt EOF nicht in char rein,
das passt da wie A**** auf Eimer rein, aber hallo !
So, in char gehen Zahlen von -128 bis +127 rein, das sind summa summarum
128*EOF im negativen Bereich, gelle.
Schreib doch mal char c = EOF;
und dann kompilier das mal zusammen mit printf("%i", c );
Meinst du da kommt ne Meldung von wegen Konstant too large oder so ? Neeee, der zeigt ganz brav -1 an, so wie sich das gehört.
-
Auch wenn ein Wert, welcher auf "(int)-1" lautet, bei der Konvertierung in signed char -1 bleibt, hast Du trotzdem unrecht, proggingmania.
Der Grund ist ganz einfach: File-I/O-Funktionen, die ein int zurückliefern, lesen volle Bytes. Und da ein Byte und ein Char (welch Zufall) dieselbe Breite haben, bleibt hier kein Spielraum für EOF.
Oder kannst Du plausibel erklären, warum zum Henker diese Funktionen int zurückgeben, und nicht einfach char, wenn doch EOF so toll in char definiert ist?
-
Theoretisch kann jeder Wert zwischen 0x00 und 0xFF (als signed char ist das 0..127;-128..-1) in deiner Datei vorkommen (und damit auch als Rückgabewert von getch() auftreten). Also kannst du nicht einfach einen Wert in diesem Bereich auswählen und als EOF festlegen. Darum gibt getch() auch einen int-Wert zurück, der entweder im Bereich 0..255 (echtes Zeichen) liegt oder EOF ist.
Und mit deinen wirren Typumwandlungen erreichst du herzlich wenig - "char c=EOF" schneidet die letzten 8 Bit von -1 ab und bei der Ausgabe wird dieser Wert (der als signed char auch gleich -1 ist) wieder auf int-Länge erweitert. (auf einem System mit vorzeichenlosem 'char' würde der übrigens nicht -1 anzeigen, sondern 255 ;))
-
LordJaxom schrieb:
...
Der Grund ist ganz einfach: File-I/O-Funktionen, die ein int zurückliefern, lesen volle Bytes. Und da ein Byte und ein Char (welch Zufall) dieselbe Breite haben, bleibt hier kein Spielraum für EOF.
...Eben, volle Bytes werden eingelesen. Wenn ich also Byteweise einlese, immer nur ein Byte, bis EOF kommt, wo soll dann der Platzmangel für EOF sein ?
Dem armen kleinen EOF bleibt gar nichts anderes übrig, als in mein char c zu plumpsen und dort auch als solches erkannt zu werden.
-
ein scheiss troll, nix anderes.
ich hab mir schon ein greasemonkey script gesucht um den spacken aus meinem blickfeld zu haben.
-
CStoll schrieb:
Theoretisch kann jeder Wert zwischen 0x00 und 0xFF (als signed char ist das 0..127;-128..-1) in deiner Datei vorkommen (und damit auch als Rückgabewert von getch() auftreten). Also kannst du nicht einfach einen Wert in diesem Bereich auswählen und als EOF festlegen.
Also, ich habe nichts festgelegt, das haben schon andere gemacht:
// Definiert in stdio.h: #define EOF (-1)Bei näherer Betrachtung also weder char, noch int.
Einfach nur eine negative, ganze Zahl.
Es ist ja nicht so, das die -1 in der Datei selbst irgendwo am Ende steht, das ist quasi nur eine Ende-Der-Datei-Indikator.
Sonst würde ja, wenn man einen Buchstaben in einer Textdatei im ANSI-Format abspeichert mindestens noch ein zusätzliches Byte für die -1 gebraucht werden und aus einem gespeicherten 'A' hätte man auf einmal eine doppelt so grosse ( 2 Byte ) Datei. Nönööö
-
proggingmania schrieb:
Dem armen kleinen EOF bleibt gar nichts anderes übrig, als in mein char c zu plumpsen und dort auch als solches erkannt zu werden.
da plumpst nichts, es wird reingequetscht und die oberen bits werden abgschnitten. derartig verkrüppelt kann hinterher niemand mehr feststellen, dass es mal ein EOF war.
-
proggingmania schrieb:
CStoll schrieb:
Theoretisch kann jeder Wert zwischen 0x00 und 0xFF (als signed char ist das 0..127;-128..-1) in deiner Datei vorkommen (und damit auch als Rückgabewert von getch() auftreten). Also kannst du nicht einfach einen Wert in diesem Bereich auswählen und als EOF festlegen.
Also, ich habe nichts festgelegt, das haben schon andere gemacht:
// Definiert in stdio.h: #define EOF (-1)Bei näherer Betrachtung also weder char, noch int.
Und bei noch näherer Betrachtung ist das ein int (es gibt keine typlosen Werte in C, darum gibt es auch Regeln, welchen Typ ein Literal hat)
Es ist ja nicht so, das die -1 in der Datei selbst irgendwo am Ende steht, das ist quasi nur eine Ende-Der-Datei-Indikator.
Sonst würde ja, wenn man einen Buchstaben in einer Textdatei im ANSI-Format abspeichert mindestens noch ein zusätzliches Byte für die -1 gebraucht werden und aus einem gespeicherten 'A' hätte man auf einmal eine doppelt so grosse ( 2 Byte ) Datei. NönöööSo, und jetzt hast du dich endgültig in deiner eigenen Argumentation verheddert. Ich versuche mal, es für dich zu ordnen:
- ein char ist genau 1 Byte groß (per Definition des ANSI-Standards)
- jeder mögliche char-Wert kann in einer Datei vorkommen
- die EOF-Kennung kann nicht in der Datei stehen
=> EOF kann kein char sein
-
c.rackwitz schrieb:
ein scheiss troll, nix anderes.
ich hab mir schon ein greasemonkey script gesucht um den spacken aus meinem blickfeld zu haben.
Beherrsch dich bitte.
-
Frag mal am besten einen C Programmierer, ob -1 in char reinpasst, lol.
-
proggingmania schrieb:
Frag mal am besten einen C Programmierer, ob -1 in char reinpasst, lol.
-1 passt sogar in nur 2 bits rein.
--> http://en.wikipedia.org/wiki/Two's_complement
aber es geht hier nicht um den zahlenwert, sondern darum, dass das höchste bit (oder ein anderes ausserhalb der breite con 'char') bei EOF immer gesetzt sein muss.
-
Tim schrieb:
Beherrsch dich bitte.
Wo er doch recht hat...
Entweder Troll oder absolut lernresistent.
@proggingmania:
Falls Du wider Erwarten kein Troll sein solltest, les Dir die Beiträge nochmal durch, es geht hier nicht darum ob -1 in ein char passt sondern darum den Char-Wert -1 (in der Datei Hex 0xFF) eindeutig von EOF aka dem Int-Wert -1 (Hex 0xFFFFFFFF) unterscheiden zu können. Oder brechen alle Deine Programme das Lesen ab wenn in der Datei mal Hex 0xFF vorkommt?Für mich ist damit btw EOD.
-
LordJaxom schrieb:
Tim schrieb:
Beherrsch dich bitte.
Wo er doch recht hat...
Stimmt, "recht haben" legitimiert ja alles...
-
wer braucht schon eine legitimierung um zu fluchen?
wenn ich nicht ausfallend geworden waere, waer mein standpunkt wahrscheinlich untergegangen.edit: heisst nicht, dass mein verhalten hier hinpassen wuerde
-
LordJaxom schrieb:
Oder brechen alle Deine Programme das Lesen ab wenn in der Datei mal Hex 0xFF vorkommt?
Ja, alle, entweder bei (char)0xFF oder bei (int)0xFF, je nachdem wie ich den Wert da reinschreibe.
LordJaxom schrieb:
Für mich ist damit btw EOD.
Ok, geht in ordung.
-
proggingmania schrieb:
LordJaxom schrieb:
Oder brechen alle Deine Programme das Lesen ab wenn in der Datei mal Hex 0xFF vorkommt?
Ja, alle, entweder bei (char)0xFF oder bei (int)0xFF, je nachdem wie ich den Wert da reinschreibe.
Dir ist aber klar, daß (int)0xFF (=255) etwas anderes ist als EOF?
-
CStoll schrieb:
Dir ist aber klar, daß (int)0xFF (=255) etwas anderes ist als EOF?
Ja, denn ( EOF == -1 ) != ( (int)0xFF == 255 )
-
in einem char ist das aber der gleiche wert :p
-
c.rackwitz schrieb:
in einem char ist das aber der gleiche wert :p
jetzt fängst du auch noch damit an...
EOF passt *nicht* in einen 'char'
-
tuerlich nicht. der wird abgeschnitten. deswegen ist in einem char -1 == 255 (modulo 256), weshalb getchar() auch einen ganzen int zurueckgibt (scheinbar daten >=0 und eof == -1).
lesen, dann fluchen. meinen verstand habe ich noch. du auch?