swscanf Unterschiede GCC vs. Windows MSVC?



  • Servus,

    ich habe gerade das Problem, dass sich swscanf unter Windows anders verhält als unter Mac/Linux. Unter Windows verwende ich VC++2010 als Compiler, unter Mac/Linux gcc 4.2 bzw 4.5.

    Folgender Code:

    int i;
    char c;
    const wchar_t* ws = L"90/L";
    if (swscanf(ws, L"%d/%c", &i, &c) == 2)
    {
    ...
    }
    

    Führt unter Mac/Linux zum erwarteten Ergebnis i == 90 und c == 'L'.
    Unter Windows ist jedoch i == 0 und c == 'L'.

    Woran liegt das?

    Gruß,
    Philipp

    EDIT: Das sscanf-Gegenstück funktioniert auch unter Windows wie erwartet. Ist swscanf unter Windows kaputt? Habe auch mal, weil sich MSVC ja immer so penentrant beschwert, swscanf_s benutzt, mit dem gleichen Ergebnis.



  • Bei swscanf liest %c, wenn mich nicht alles täuscht, einen wchar_t ein. Dass das unter Linux und MacOS das richtige Ergebnis liefert, ist dann eher zufällig und liegt im Zweifel daran, dass die Variablen in anderer Reihenfolge als unter Windows auf den Stack gelegt werden.



  • Dürfte nicht nur %lc einen wchar_t einlesen?



  • Aus der Manpage:

    c Matches a sequence of wide characters of exactly the number specified by the field width (1 if no field width is present in the conversion specification).

    If no l (ell) length modifier is present, characters from the input field shall be converted as if by repeated calls to the wcrtomb() function, with the conversion state described by an mbstate_t object initial‐
    ized to zero before the first wide character is converted. The corresponding argument shall be a pointer to the initial element of a character array large enough to accept the sequence. No null character is
    added.

    Demnach sollte es so richtig sein.



  • Mein MSVC2011 liefert das gewünschte Ergebnis und nicht deinen Fehler.
    Evtl. verwendest du in deinem Programm nicht durchgängig wchar_t Streams und benutzt auch fwide nicht, da kann man schnell mal den Überblick verlieren und unerwartete Ergebnisse ohne Fehlermeldung bekommen.



  • Nach ein paar Experimenten ist das Problem klar: MSVC hat ein Problem mit UTF-16 kodierten Dateien als Input. Speichert man die Datei Latin-1 kodiert ab, geht's dann wieder. Hachja, das Jahr 2012 und Umlaute ... 🙂



  • Nach ein paar Experimenten ist das Problem klar: MSVC hat ein Problem mit UTF-16 kodierten Dateien als Input. Speichert man die Datei Latin-1 kodiert ab, geht's dann wieder. Hachja, das Jahr 2012 und Umlaute ... 🙂



  • Der Code den Du oben gepostet hat läuft mit VS2010 sauber durch und gibt auch

    ws	0x00aa57a4 "90/L"	const wchar_t *
    

    zurück.

    Vermute das Problem (wie Du schon bemerktest) liegt bei sauberen Einlesen.


Anmelden zum Antworten