fputc() verschluckt Zeichen

[Walter T. (nicolas)]

Hallo zusammen,

ich habe eine BMP-Datei, von der ich nur noch ein C-Array habe (und die 
Original-Datei fehlt).

Eigentlich kein Problem - einfach das Array wieder in eine Datei 
speichern (siehe Quelltext im Anhang). Aber irgendetwas macht mir einen 
Strich durch die Rechnung. Die ersten und die letzten HEX-Werte stimmen 
immer (überprüft mit einem HEX-Editor). Aber mittendrin scheint fputs() 
Zeichen zu verschlucken oder zu verdoppeln - in sich auch konsistent, 
denn bei jedem Array kommt immer die gleiche Binärdatei heraus 
(zumindest bei den Versuchen, die ich bis jetzt gemacht habe). Unterm 
Strich ist die Datei immer grob 1000 Bytes zu groß (obwohl die in Zeile 
4657 angezeigte Größe stimmt) und natürlich unbrauchbar.

Build-Umgebung ist ein betagter (tdm64-1) gcc 5.1.0 oder der 9.2.0

Was passiert hier? Ich weiss, dass fputc() Zeichen bis zu einem Flush 
oder Programmende zurückstellen darf, aber Zeichen verdoppeln?

[Jörg W. (dl8dtl) (Moderator)]

carriage-return / newline issue?

Je nach Umgebung, probier mal, die Datei mit fopen(…, "wb") anzulegen.

[Walter T. (nicolas)]

Jörg W. schrieb:
> carriage-return / newline issue?
>
> Je nach Umgebung, probier mal, die Datei mit fopen(…, "wb") anzulegen.

Danke! Das war es!

Jetzt muss ich mal schauen, was sich fputc() bei "w" herausnimmt.

[(prx) A. K. (prx)]

Walter T. schrieb:
> Jetzt muss ich mal schauen, was sich fputc() bei "w" herausnimmt.

0x0A => 0x0D,0x0A

[Walter T. (nicolas)]

(prx) A. K. schrieb:
> 0x0A => 0x0D,0x0A

Da haben wir uns gedoppelt. Ja, solche Stellen lassen sich 
identifizieren. War mir deshalb nicht aufgefallen, weil im Binärformat 
wirklich 0x0D,0x0A mehrmals vorkommt und das Array sehr groß ist.

[Klaus W. (mfgkw)]

erledigt...