Calculer Girl
  1. Calculer Girl
  3. C programme montre% zu après la conversion à Windows
Intereting Posts
Impossible de modifier la taille du texte dans le tracé de la règle Renommez plusieurs dossiers avec un motif dans le nom en utilisant le lot CORS Filter ne change pas d’en-tête Jouer 2 déployer sur Ubuntu Comment rendre les symboles d’impression gdb dans les bibliothèques partagées chargées avec dlopen? Linux comment trouver des fichiers spécifiques dans des dossiers spécifiques Erreur interne du navigateur Web Aptana, Ubuntu 12.04 Avoir du mal à exécuter nginx sur l’instance EC2 Que devrait servir Apache et que devrait servir Tomcat? Comment extraire du texte entre parenthèses dans une chaîne plus longue en utilisant awk? Windows Mobile 6.5 vs Windows Embedded Handheld 6.5 – quelle est la différence? Chargement des journaux apache dans Amazon Redshift (htaccess) Autoriser le stream mais désactiver le téléchargement du lien direct Profilage de programmes partiels sous Linux Où la commande docker ps recherche-t-elle les conteneurs actuels?

C programme montre% zu après la conversion à Windows

J’ai exécuté un programme Linux sur Windows via Mingw. Cependant, le résultat du programme semble différent sous Windows que sous Linux.

Par exemple, sous Windows, la sortie est la suivante (j’obtiens «zu» au lieu de nombres réels): 

Approximated minimal memory consumption: Sequence : zuM Buffer : 1 X zuM = zuM Table : 1 X zuM = zuM Miscellaneous : zuM Total : zuM

Sous Linux, le programme d’origine comstack (sans Mingw) avec un avertissement. Sous Windows, sous Mingw, il comstack avec des avertissements zéro.

Il y a quelque chose dont je devrais être au courant?
Mingw offre-t-il une compatibilité à 100% ou dois-je modifier le programme pour travailler sur Win?

Je ne sais pas dans quelle direction aller. Où dois-je commencer ma tentative de correction du programme?
Pensez-vous que j’ai de meilleures chances avec Cygwin?

Mettre à jour:
Wikipedia mentionne ceci: “le manque de prise en charge de C99 a causé des problèmes de portage, en particulier en ce qui concerne les spécificateurs de conversion de type printf”.
Est-ce la chose dans laquelle je me suis cogné la tête?

Mettre à jour:
Ma version est: 

 MINGWBASEDIR=C:\MinGW gcc version 4.8.1 (GCC) gcc version 4.8.1 (GCC) GNU gdb (GDB) 7.6.1 GNU ld (GNU Binutils) 2.24 GNU windres (GNU Binutils) 2.24 GNU dlltool (GNU Binutils) 2.24 GNU Make 3.82.90 #define __MINGW32_VERSION 3.20 #define __W32API_VERSION 3.17

(J’ai utilisé ce code pour obtenir la version: 

 @echo off REM version-of-mingw.bat REM credit to Peter Ward work in ReactOS Build Environment RosBE.cmd it gave me a starting point that I edited. :: :: Display the current version of GCC, ld, make and others. :: REM %CD% works in Windows XP, not sure when it was added to Windows REM set MINGWBASEDIR=C:\MinGW set MINGWBASEDIR=%CD% ECHO MINGWBASEDIR=%MINGWBASEDIR% SET PATH=%MINGWBASEDIR%\bin;%SystemRoot%\system32 if exist %MINGWBASEDIR%\bin\gcc.exe (gcc -v 2>&1 | find "gcc version") REM if exist %MINGWBASEDIR%\bin\gcc.exe gcc -print-search-dirs if exist %MINGWBASEDIR%\bin\c++.exe (c++ -v 2>&1 | find "gcc version") if exist %MINGWBASEDIR%\bin\gcc-sjlj.exe (gcc-sjlj.exe -v 2>&1 | find "gcc version") if exist %MINGWBASEDIR%\bin\gcc-dw2.exe (gcc-dw2.exe -v 2>&1 | find "gcc version") if exist %MINGWBASEDIR%\bin\gdb.exe (gdb.exe -v | find "GNU gdb") if exist %MINGWBASEDIR%\bin\nasm.exe (nasm -v) if exist %MINGWBASEDIR%\bin\ld.exe (ld -v) if exist %MINGWBASEDIR%\bin\windres.exe (windres --version | find "GNU windres") if exist %MINGWBASEDIR%\bin\dlltool.exe (dlltool --version | find "GNU dlltool") if exist %MINGWBASEDIR%\bin\pexports.exe (pexports | find "PExports" ) if exist %MINGWBASEDIR%\bin\mingw32-make.exe (mingw32-make -v | find "GNU Make") if exist %MINGWBASEDIR%\bin\make.exe (ECHO It is not recommended to have make.exe in mingw/bin) REM ECHO "The minGW runtime version is the same as __MINGW32_VERSION" if exist "%MINGWBASEDIR%\include\_mingw.h" (type "%MINGWBASEDIR%\include\_mingw.h" | find "__MINGW32_VERSION" | find "#define") if exist "%MINGWBASEDIR%\include\w32api.h" (type "%MINGWBASEDIR%\include\w32api.h" | find "__W32API_VERSION") :_end PAUSE

)

Comme le suggère la discussion du rapport de bogue dans les commentaires , les fonctions printf de Microsoft ne prennent pas en charge C99. Le projet mingw-w64 fournit des fonctions alternatives qui peuvent être utilisées comme s’il s’agissait des fonctions C99 normales si la macro __USE_MINGW_ANSI_STDIO est définie sur 1 avant d’inclure des en-têtes ou sur la ligne de commande. Ils prennent en charge les spécificateurs de format standard %zu , %jd , etc., contrairement aux versions les plus récentes de MSVCRT. Vous pouvez appeler la fonction directement en utilisant mingw_printf , mais il est généralement plus simple de définir la macro susmentionnée sur 1 et d’appeler printf , etc.

Il est à noter que si vous utilisez le snprintf de Microsoft, il renverra -1 pour indiquer une troncature si le tampon n’est pas assez grand, à moins que les parameters de taille de tampon et de tampon soient respectivement NULL et 0, auquel cas la sortie est renvoyée. Le comportement de C99 consiste à toujours renvoyer le nombre d’octets qui seraient générés si la mémoire tampon était suffisamment grande ou négative si une erreur de codage se produisait, et l’implémentation de mingw-w64 semble se comporter correctement conformément à C99.

Et tout ce que vous devez faire pour obtenir tout ce comportement standard est soit #define __USE_MINGW_ANSI_STDIO 1 avant tout inclut si vous utilisez l’une des fonctions printf ou simplement ajoutez -D__USE_MINGW_ANSI_STDIO=1 à votre appel du compilateur.

Si vous craignez que la macro interfère avec d’autres plates-formes, aucune autre implémentation, à l’exception du projet MinGW [32] original (hérité?) Fournissant des fonctionnalités similaires, ne devrait réellement utiliser cette macro de préprocesseur.