Meikrosoft des tages

Erstmal ein bisschen C++-kohd… wahrlich nix kompliziertes, einfach nur die formatierte ausgabe einer zahl, bei der die sprach- und landeseinstellungen berücksichtigt werden sollen — es hilft doch sehr, die größenordnung auf dem ersten blick abzuschätzen, wenn man tausenderseparatoren verwendet:

#include <iostream>
#include <locale>

using namespace std;

int main (int argc, char **argv)
{
    locale loc ("");
    cout.imbue (loc);
    cout << 1234567 << endl;
    return 0;
}

Frage: was wird ausgegeben, wenn man das mit meikrosofts „visual studio“ als konsolenanwendung kompiliert und das resultierende binary unter windohs sieben in der CMD.EXE-konsole aufruft?

Mit unbearbeiteten deutschen landeseinstellungen sollte hier 1.234.567 ausgegeben werden (und schweizerdeutsche einstellungen ergäben 1'234'567). Nun, auf einem kompjuter kam 1ÔÇç234ÔÇç567 raus, was natürlich… ähm… ein kleines bisschen unerwartet aussieht und die zahl auch nicht leichter lesbar macht. 😯

Hl. henker! Woran liegt das?

Bei einem blick in die landeseinstellungen in der windohs-systemsteuerung dieses kompjuters habe ich zunächst gedacht, dass dort ein leerzeichen als tausender-separator angegeben wurde. Es war aber kein „normales leerzeichen“ U+0020, sondern ein „ziffernleerzeichen“ U+2007 (also ein &numsp; in HTML oder ein \hphantom{0} in LaTeX). Auch im jahr 2018 kann es einem also immer noch (völlig unerwartete) probleme bereiten, dass diese scheiß-CMD.EXE nicht unicodefähig ist und eine völlig andere zeichenkohdierung als der gesamte rest des systemes verwendet. Das sind diese kleinen momente, in denen ich ganz froh darüber bin, dass ich es nur noch selten mit windohs zu tun habe und deshalb schon ganz vergessen habe, was für heitere altlasten dieses flickwerk mit sich herumträgt…

Dass diese beiden verschiedenen leerzeichen (unicode hat noch einige mehr anzubieten) in so einem einstellungsdialog wegen ihrer leerzeichenhaftigkeit natürlich nicht durch hingucken unterscheidbar sind und dass man sich deswegen etwas länger fragt, woran zum henker es liegt, brauche ich hoffentlich gar nicht erst zu erwähnen. Die moral der heitren kurzgeschicht: für CMD verwende die locales nicht!

Cmdshock

„Shellshock“ habt ihr alle mitbekommen, oder? Aber kennt ihr schon cmdshock… [via]

(Wers nicht sofort kapiert: das ist eine sehr ähnliche kategorie von fehler, allerdings erfolgt die ausführung nicht schon beim setzen einer umgebungsvariablen. Der fehler ist unter windohs deshalb viel „harmloser“, weil cmd.exe nicht so eine zentrale rolle einnimmt wie eine un*x-shell.)