Struct in Binärdatei schreiben - Länge variiert!

pointercrash**

+gjm+ schrieb:

Ist zwar nicht die Lösung, aber bei fwrite() sind der zweite und der dritte Parameter vertauscht:

Doch, ist die Lösung. Kaum macht mans richtig, schon gehts. Hab's vertauscht und jetzt kommen immer 12 Bytes.

EDIT: Zu früh gefreut , um zwei soll man nimmer Debuggen, hatte vergessen, daß if und else noch auskommentiert waren. Wieder drin = 13 Bytes, altes Problem ..

bgdnoy

um zwei soll man nimmer Debuggen

Wann sonst?

volkard

zeig mal die aufrufe von fopen().

pointercrash**

volkard schrieb:

zeig mal die aufrufe von fopen().

outfile = fopen("temp.m1", "w");
	if (outfile)
	{ // Variablen init usw

Meinst Du wirklich, daß es daran liegen könnte?

bgdnoy schrieb:

Wann sonst?

Nicht, wenn man seit sechs Uhr morgens schon dransaß. Da passieren dann die wirklichen Idiotenfehler.

volkard

pointercrash() schrieb:

volkard schrieb:

zeig mal die aufrufe von fopen().
outfile = fopen("temp.m1", "w");
	if (outfile)
	{ // Variablen init usw
Meinst Du wirklich, daß es daran liegen könnte?

nein.aber ich wills auch nicht ausschließen. brauchte man für binärdateien nicht "wb"? ich glaub zwar, daß das "b" nur beim einlesen was bewirkt, aber in anbetracht der tatsache, daß es am gezeigten code nicht liegt, wird man bei den fehlervermutungen ausgelassener.

pointercrash**

volkard schrieb:

nein.aber ich wills auch nicht ausschließen. brauchte man für binärdateien nicht "wb"? ich glaub zwar, daß das "b" nur beim einlesen was bewirkt, aber in anbetracht der tatsache, daß es am gezeigten code nicht liegt, wird man bei den fehlervermutungen ausgelassener.

Prima Idee, zumindest ist der kleine Dateiauszug jetzt richtig mit 12 Bytes je Satz in der Datei gelandet.

Also scheint es auch beim Schreiben einen Unterschied zu machen, ich suche noch nach einer Manpage, die das erklärt.

Ein super- Danke !

Liegt tatsächlich an fopen() mit "w".

0x20: FFFF FF4E 0500 0000 46F4 0500 004E 0500 - ÿÿÿN....Fô...N..
0x30: 0000 421D 0000 0011 0000 00[b]0D 0A00 00[/b]00 - ..B.............

Prüf mal ob im "B"-Datensatz die letzte Koordinate ein 0x0A enthält. fwrite() hat sie wahrscheinlich konvertiert in ein CRLF (0D0A).

edit: Und die Länge von 13 kommt zustande, weil fwrite() ein Zeichen (0x0D) eingefügt hat:

0x30: 0000 421D 0000 0011 0000 000D [b]0A00 0000[/b] - ..B.............

pointercrash**

+gjm+ schrieb:

Prüf mal ob im "B"-Datensatz die letzte Koordinate ein 0x0A enthält. fwrite() hat sie wahrscheinlich konvertiert in ein CRLF (0D0A).

Pfeilgrad so war's! Das Blöde daran ist, daß ich in den meisten C-FAQs, manpages usw. kaum Hinweise auf den kleinen Unterschied gefunden habe, das wird meist unterschlagen, bzw. es wird kaum wo dezidiert auf die Folgen hingewiesen. Wenn nicht 0x0A letztes Byte der Struct ist, fällt es ja nicht auf ... fiese Sache
Aber mittlerweile kann ich das File ohne Fehler zurücklesen, heißt, ich muß mich nicht mehr damit befassen

bgdnoy

Volkard hat's gewittert, aber seltsam, daß es keiner richtig erkannt hat.
Es steht doch schon in deinem ersten Post in der letzten hexdump-Zeile:

000D 0A00

Vielleicht hab ich's wegen dem Leerzeichen übersehen?

bgdnoy schrieb:

...aber seltsam, daß es keiner richtig erkannt hat.

es waren wohl nur linux-user anwesend. denen passiert sowas nicht.