Grüß Euch,
ich habe glaub ich einen Bug beim printf() entdeckt.
Wenn ich mit
printf("Hallo\n");
diesen Text über die Serielle an den PC sende, kommt das \n-zeichen
nicht an.
printf("%s Hallo\n", "dummyString");
Erst wenn irgendein parameter dem Formatstring im printf() übergeben
wird, so wird auch das abschließende \n mitgesendet.
Somit funktioniert auch folgendes richtig:
printf("Hallo%c",'\n');
Hat diesen Fehler schon mal jemand entdeckt?
Ich verwende "codesourcery-codebench-lite-2011.09-69-arm-eabi".
Das problem tritt dabei unabhängig davon auf, ob das Programm auf Linux
oder Windows kompiliert wurde.
lg, Karl
Karl Zeilhofer schrieb: > Wenn ich mit > printf("Hallo\n"); > diesen Text über die Serielle an den PC sende, kommt das \n-zeichen > nicht an. Obiges wird der Compiler vermutlich durch puts("Hallo") ersetzen. Vielleicht steckt der Bug ja in puts()?
ich hab jetzt mal puts() gecheckt, und finde dort nichts ungewöhnliches. Das seltsame ist ja, dass nur das letzte \n geschluckt wird. eines mitten im String funktioniert. doppeltes \n am ende geht auch. bin ratlos.
Gast
#2699022
Check mal, was der Preprozessor aus deinem Code gemacht hat.
wir haben das nun nochmals überdacht. ich hatte zuvor deine antwort nicht richtig interpretiert. mein kollege hat nun den bug in der stdio.c von Atmel behoben. dort wird in der puts() wird fputs() ohne hinzufügen eines \n aufgerufen! Es handelt sich um die at91lib Version 1.5! Vielen Dank für deinen Hinweis!
Karl Zeilhofer schrieb: > Es handelt sich um die at91lib Version 1.5! Dann solltet ihr wohl auch noch Atmel darüber berichten. Ist mir allerdings unklar, warum die überhaupt an stdio rumfummeln. Ist das von der newlib so schlecht? > dort wird in der puts() wird fputs() ohne hinzufügen eines \n > aufgerufen! In so eine Richtung ging meine Vermutung schon, nachdem ich über die Effekte nachgedacht hatte. Ich wusste allerdings aus der Vergangenheit (als ich das stdio für die avr-libc entworfen habe), dass der Compiler rigoros ein printf("...\n") durch puts("...") ersetzt.