Hallo,
Die libc
wandelt (sofern die Datei im ASCII-Modus geoeffnet wurde)
die Zeilenenden beim einlesen um in die entsprechende interne
Repraesentation. Unter UNIX ist das kein Problem, da ist meist
\n == \n. Unter Windows ist das schon mehr Arbeit :) Und
aufm Mac ist es ganz verrueckt, da ist \n extern == \r :)
Aha, da war ich wohl zu voreilig mit meiner Rechtverteilung.
Unter Windows ist '\n' auch nur ein Byte, nur das Zeilenende wird dort mit
zwei Bytes gesetzt.
Das ist doch das, was ich gesagt habe :) '\n' ist das Zeilenende. Schreibt man
es in eine Datei, hat die Datei 2 Byte Inhalt.
Dann arbeitest Du mit anderen LibCs. Ich habe es hier auf Win98 ausprobiert mit GCC (Cygwin Port) und LCCWin32 und deren LibCs. Beide schmissen nur ein Byte raus und beide Male auch 0x0d.
Benutzt Du etwa diesen "Visual Crap"? ;-)
Aber nach Standard wäre es (2 Byte zu setzen) eigentlich sogar korrekt, obwohl ich die Angaben etwas wiedersprüchlich finde:
\n (newline)Moves the active position to the initial position of the next line.
\r (carriage return)Moves the active position to the initial position of the current line.
Auch gibt es dann Schwierigkeiten mit Intergercast Konstrukten, wie '\n', das normalerweise genauso groß wie z.B. '\t' sein muß. Beim Schreiben noch kein Problem, aber beim Lesen.
Aber Windows war ja schon immer etwas merkwürdig ;-)
(Die uralte Schreibmschinentechnik für Computer zu benutzen ist ja doch etwas ... äh ..., nun ... ;-)
(Wobei ich mich frage, ob sich das jetzt geändert hat, da nun ein BSD unten
drunter läuft)
Richtig.
Gab/gibt das keine Schwierigkeiten mit (dem Auswurf von) alten Programmen? Oder greift da die Simulation des alten MacOS?
so short
Christoph Zurnieden
PS:
Die Perseiden habe ich gefunden, zu sehen war aber nix. Und dafür stehe ich mitten in der Nacht auf! ;-)
CZ