Question

Comme je l'écrivais une unité de test, j'ai trébuché sur certains comportement étrange d' glibc, concernant "%p" et la NULL pointeur.

Si j'ai une ligne telle que printf("NULL pointer is %p\n", NULL);, puis-je voir NULL pointer is (nil) imprimé à l'écran, comme je m'y attendais.

Si j'utilise plutôt la version grand caractère: wprintf(L"NULL pointer is %p\n", NULL);, puis il imprime NULL pointer is (, et s'arrête à l'ouverture de la parenthèse.Si j'ai l'impression nonNULL un pointeur, il imprime le pointeur, normal et grand caractère des versions.Est-ce un bug connu de glibc, ou suis-je raté quelque chose?

NB:Je me rends compte que la norme dit que les pointeurs avec %p sont convertis en œuvre de la manière définie;il semble tout à fait inhabituel d'impression ( pour un NULL pointeur.

Était-ce utile?

La solution

C'est vraiment un bug: https://sourceware.org/git/gitweb.cgi?p=glibc.git;a=blob;f=stdio-common/vfprintf.c;hb=c15cf13a8a672bd27bf3d94b995c52872eed537d#l932

 934             /* Write "(nil)" for a nil pointer.  */                           \
 935             string = (CHAR_T *) L_("(nil)");                                  \
 936             /* Make sure the full string "(nil)" is printed.  */              \
 937             if (prec < 5)                                                     \
 938               prec = 5;                                                       \
 939             is_long = 0;        /* This is no wide-char string.  */           \
 940             goto LABEL (print_string);                                        \

L' L_("(nil)") se développe pour L"(nil)" pour wprintf, mais quelques lignes plus tard is_long est fixé à 0 (c'est à direfalse).La suite string est interprété comme une étroite chaîne de caractères, donc l'impression qu'il va s'arrêter à sa première de zéro octet c'est à direaprès l' (.

Bug rapporté lien: https://sourceware.org/bugzilla/show_bug.cgi?id=16890 - ce problème est résolu dans la version 2.20 de la glibc.

Fait intéressant, ce bug semble avoir existé depuis près de 15 ans avant qu'il a été trouvé et corrigé - dans un délai de 2 jours à compter de sa déclaration!

Autres conseils

Confirmé sur Ubuntu 14.04 LTS;De la Bibliothèque C GNU (Ubuntu EGLIBC 2.19-0ubuntu6).

Il semble être un rapport de bogue dans au moins Debian glibc;le bug a été corrigé le 1er Mai 2014, et devrait être disponible dans la Glibc 2.20.Il suffit d'attendre en amont des mises à jour.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top