long ausgabe mit printf

[Christopher (Gast)]

Hallo,

ich möchte gerne eine long Variable mit printf am Terminal ausgeben.
Ich hab schon gesucht aber %li, %lu, %ld funktionieren nicht. Ich 
benutze Codevision zum Programmieren. Mit %i funktioniert es aber dann 
hab ich immer einen Überlauf.

Danke

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

Hmm, im AVR-GCC geht das (und es geht genau so), und in dessen Forum
befindest du dich hier...

Was sagt denn die Dokumentation deines Compilers?

[Christopher (Gast)]

Die Dokumentation von Codevision sagt leider nur etwas zu
float, int, char, hex, usw. leider nichts zu long.

[Peter D. (peda)]

%ld ist schon voll o.k. so für konforme C-Compiler.

In der Codesammlung hat jemand nur für Codevision %ald gepostet, keine 
Ahnung, was das bedeutet.


Peter

[Christopher (Gast)]

Oje, sonst hatte ich mit Codevision nie Sorgen. Muss mich vielleicht 
doch mal umgewöhnen. %ald funktioniert auch nicht.

[Karl Z. (griffin27)]

Ich arbeite mit dem arm-elf-gcc, und hab gerade das gleiche Problem.
Ich hab einen 64-bit integer, den ich per printf mit %ld an das Terminal 
senden möchte. Leider kommen nur kryptische Zeichen an.

%ld erwartet aber auch einen long int, aber int64_t ist mit long long 
definiert. gibts dafür eine einfache Lösung?

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

Wenn deine Bibliothek es kann: %lld.

[Karl Z. (griffin27)]

Anscheinend kann sies nicht.

Hier das Programm:

#include <board.h>
#include <pio/pio.h>
#include <dbgu/dbgu.h>

#include <stdio.h>
#include <stdint.h>

/// Pio pins to configure.
static const Pin pins[] = {PINS_DBGU};

int main(void)
{
    int32_t l1,l2;
    int64_t l3;


    PIO_Configure(pins, PIO_LISTSIZE(pins));
    DBGU_Configure(DBGU_STANDARD, 115200, BOARD_MCK);
    printf("\n-- ATMEL ARM7 Dummy Project 1.4 --\n\n");

    l1=2000000000; // 2 Mrd
    l2=0x77359400; // 2 Mrd
    l3=(int64_t)l1*l2;
    printf("2Mrd * 2Mrd = %lld\n",l3);

    return 0;
}

der GDB zeicht in Eclipse für l3 das richtige Ergebnis an.
Als Ausgabe erhelte ich im GtkTerm

-- ATMEL ARM7 Dummy Project 1.4 --
2Mrd * 2Mrd = ®ÊÀ؇˜&ÈúːSÒ°KÜeý^Á
ºŸ2äů‘WªD—1U/êîvkÕáꦂ @€6$

[chris (Gast)]

Wenn du es nur als Debug brauchst, nimm Hex ausgabe und mach aus dem
int64_t einen int32_t mittels cast im Printf sowie dasselbe nochmals
inkl vorigem shift. Mußt die Reihenfolge usw halt ausprobieren, daß
es klappt (big endian/little endian).

Sonst, unter Unix/Linux funktioniert es mit ll L oder q prefix, gcc
kann alle, die Windows Version von GCC scheitert an long long, das
ist ein bekannter Fehler von GCC, hängt aber nicht direkt von den 
Sourcen ab, eher vom verwendeten Windows-Compiler, um die GCC sourcen zu 
erstellen.

[chris (Gast)]

ich meinte natürlich immer den cross-compiler, nicht nativen Unix 
Compiler.

[Rufus Τ. F. (rufus)]

> hängt aber nicht direkt von den Sourcen ab, eher vom verwendeten
> Windows-Compiler, um die GCC sourcen zu erstellen.

Das ist aus zweierlei Gründen zu bezweifeln, einerseits wird kein 
Compiler verwendet, um "die GCC sourcen zu erstellen", andererseits wird 
gcc auch unter Windows mit sich selbst übersetzt.

[chris (Gast)]

Das ist aber leider so. Windows Ports werden meistens mit MING 
compiliert,
eine GCC Portierung auf Windows, welche die Newlib benutzt.
Bei dieser Lib existiert kein printf für ll und L ist da ein Synonym für
long double. Bei ll: behavior is undefined, laut doc.
Da GCC selbst kein long long printf hat, hat er Probleme damit, so eines
zu generieren. Warscheinlich testet er das printf selbst oder so, weiß 
ich
nicht, aber ich kenne mehrere Mailing-Lists, welche das Problem 
aufgeworfen hatten, und da es teilweise Unix Portierung waren, wie *BSD
usw kam dann auch eine Antwort von einem GCC Entwickler, der das 
natürlich besser begründet hat, aber im Prinzip ist es eine Limitierung 
der Runtime
des Compilers, mit dem GCC selbst compiliert wurde.

[chris (Gast)]

ok, sogenannte tippfehler, nicht erstellen, sondern compilieren.
habs jetzt erst gecheckt, sorry

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

chris wrote:
> Das ist aber leider so. Windows Ports werden meistens mit MING
> compiliert,
> eine GCC Portierung auf Windows, welche die Newlib benutzt.

Der Haken dabei ist wohl, dass newlib halt kein richtiges Projekt
ist, sondern lieblos und wenig gepflegt von irgendwoher zusammen
gezogener Sourcecode für eine (einigermaßen) Standardbibliothek,
die nicht den Limitierungen der (L)GPL unterworfen ist.  So findet
sich da offenbar eine uralte (lange vor ISO C99 geschaffene)
Variante der BSD-libc wieder, die damals L als modifier für long
long int benutzt hat.  Wenn die Leute mal ihre Quellen von einem
einigermaßen aktuellen FreeBSD aktualisieren würden, dann wäre das
Dilemma behoben.

Für Karl heißt das aber wohl, dass er sich auch mit %Ld behelfen
kann.

[Karl Z. (griffin27)]

Alos %Ld funktioniert genausowenig wie %lld... Ich brauch die Funktion 
grad nicht wirklich, aber trotzdem schade.

lg

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

Dann kannst du dir nur mit dem Selbstportieren einer der diversen
BSD-Bibliotheken behelfen, wenn du's mal brauchst.

[Karl Z. (griffin27)]

hört sich nach viel arbeit an...

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

Karl Zeilhofer wrote:
> hört sich nach viel arbeit an...

Ist an einem Abend gemacht.  Man sollte sich unterschiedliche
Versionen vornehmen, aktuelle Versionen sind auf Grund der später
eingebauten C99-Features u. U. etwas komplexer geworden.  Ggf. mit
einem ursprünglichen 4.4BSD beginnen, da bin ich mir nur nicht ganz
sicher, ob's da schon long long gab.

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

Für solche Debug-Zwecke hatte ich mir deshalb mal eine eigene 
eingedampfte Version von printf gestrickt. Schon auf Platzgründen wollte 
ich beim ARM auf die newlib verzichten-

Sollte ziemlich universell einsetzbar sein, sofern alloca() existiert 
und "unsigned long long" der maximal verfügbare Integer-Typ ist.

Ist Originalfassung, die Includes müssen angepasst werden, config,h kann 
man streichen.