printf arguments variants

Je récupère une version d'un code source en C ou printf était utilisé de la façon suivante :

Citation:

---

printf("%1$ld%2$s%6$7.7ld", 2134,(const char*) "valu", 1234, (const char*)"emet", "autreem", 1234);

---

Lors d'une compilation via l'optimisation gcc "O2", j'ai le droit à un plantage du printf. Si je vire l'option, cela marche.
J'aimerai savoir si il existe un workarround via une option du GCC ou autre permettant d'utiliser le printf comme cela. Ou bien si il existe une autre fonction que le printf permettant d'utiliser un pattern de formattage variant sans l'intégralité des arguments.

Bonjour,
C'est juste que le printf ne comprends que trois %, et qu'il y a six arguments.
Quelque soit le compilo, ce printf est faux.
Donner trop d'arguments est un comportement <indéfini/défini par l'implémentation>, visiblement, GCC plante dans ton cas.

Le bon workaround, c'est de corriger le printf.

A mon avis le problème est plus sûrement du à ce que tu utilises %ld (long) alors que l'argument est un int, surtout si tu compiles en 64 bits. Utilise %d, ou passe 1234L.

Les argument surnuméraires, évidemment ce n'est pas correct, mais je ne vois pas comment ça pourrait faire planter ton programme.

Si le comportement n'est pas défini par la norme, alors ça peut planter sur certaines implémentations :)

Citation:

---

Envoyé par leternel

Bonjour,
C'est juste que le printf ne comprends que trois %, et qu'il y a six arguments.
Quelque soit le compilo, ce printf est faux.
Donner trop d'arguments est un comportement <indéfini/défini par l'implémentation>, visiblement, GCC plante dans ton cas.

Le bon workaround, c'est de corriger le printf.

---

Non, ce code n'est pas faux. Du moins, pas sur ce point.
Jouer avec la position de l'argument qu'on utilise est très courant. Surtout dans la traduction. D'un point de vue pure C, il n'y a jamais "trop" ou "top peu" d'arguments à une fonction variadique. C'est printf lui-même qui risque de faire de la merde en essayant de lire plus d'arguments qu'il n'y en a.

Citation:

---

Envoyé par [url=http://flash-gordon.me.uk/ansi.c.txt]Standard C89[/url] section 4.9.6.1 The fprintf function et [url=http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf]standard C99[/url] section 7.19.6.1 The fprintf function et [url=http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf]standard C11[/url] section 7.21.6.1 The fprintf function

The fprintf function writes output to the stream pointed to by
stream , under control of the string pointed to by format that
specifies how subsequent arguments are converted for output. If there
are insufficient arguments for the format, the behavior is undefined.
If the format is exhausted while arguments remain, the excess
arguments are evaluated (as always) but are otherwise ignored. The
fprintf function returns when the end of the format string is
encountered.

---

Cela dit, prendre des arguments dans un ordre arbitraire ne fait pas parti du standard C. C'est par contre spécifié par POSIX. POSIX qui dit que si on utilise le format %n$ il faut que tous les arguments avant lui soient spécifiés.

Citation:

---

The format can contain either numbered argument conversion specifications (that is, "%n$" and "*m$"), or unnumbered argument conversion specifications (that is, % and * ), but not both. The only exception to this is that %% can be mixed with the "%n$"
form. The results of mixing numbered and unnumbered argument specifications in a format string are undefined. When numbered argument specifications are used, specifying the Nth argument requires that all the leading arguments, from the first to the
(N-1)th, are specified in the format string.

---

En effet, sans ça il ne peut pas connaître la taille des arguments sur la pile (4 ou 8 octets en général) et ne peut donc pas atteindre l'argument demandé.

Note: Lien Single UNIX Specification

^Merci. L'erreur viendrait donc d'une part de la taille des arguments mal spécifiée (si long est plus long que int, comme en 64 bits sous *n*x ou en 16 bits) d'autre part de la spécification de l'argument 6 sans les autres.

Le problème majeur quant à la seconde partie, c'est qu'il n'existe apparemment pas de spécificateur de format pour dire "invisible", ce qui aurait permis de définir le type des arguments "sautés". Ici, il n'y a que deux solutions: Afficher tout ou changer l'ordre des arguments pour que les arguments non-imprimés soient forcément les derniers.

Je suppose que ta chaîne de format n'est pas constante.
Donc à voir si selon comment elle est construite.

Et sinon, si tu utilises gcc avec la glibc et les bonnes options de warning (mais tout le monde met les warnings, n'est-ce pas ?), gcc devrait te dire qu'il y a un foirage dans le format.

Citation:

---

Envoyé par gcc -Wall -Wextra

test.printf.c: In function `main':
test.printf.c:5:2: warning: format `%ld' expects argument of type `long int', but argument 2 has type `int' [-Wformat]
test.printf.c:5:2: warning: format `%ld' expects argument of type `long int', but argument 7 has type `int' [-Wformat]
test.printf.c:5:2: warning: format argument 3 unused before used argument 6 in $-style format [-Wformat]
test.printf.c:5:2: warning: format argument 4 unused before used argument 6 in $-style format [-Wformat]
test.printf.c:5:2: warning: format argument 5 unused before used argument 6 in $-style format [-Wformat]

---

Et si je rajoute l'option -m 32, l'exécution me donne même le bon résultat.


Sinon, tu peux dire à printf de ne pas afficher les chaînes de caractère avec le format %.0s. Mais j'ai rien trouvé pour les entiers.