Discussion :

[psyphi]

Alors voila j'ai un code qui fonctionne parfaitement avec code::blocks+MingW mais j'ai voulu le compiler avec visual studio 2005 et j'ai une erreur qui m'embête un peu.
En effet visual studio ne reconnait pas snprintf() [j'ai bien inclu stdio.h ]. Je me dis bon ba tant pis je vais testé sprintf(), eh mais dans ce cas j'ai un warning qui apparait:

warning C4996: 'sprintf': This function or variable may be unsafe. Consider using sprintf_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS.

Je pense que je dois donc utilisé la fonction sprintf_s dont je n'avais jamais entendue parler avant, est ce que quelqu'un sait si cette fonction est portable et sera reconnu par gcc (MingW) ?

PS: extrait de man snprintf

Les fonctions
snprintf, et vsnprintf sont conformes à ISO/IEC 9899:1999.

[Médinoc]

En effet, M$ a refusé C99, préférant leur "secure CRT" 100% non-portable.

Tu trouvera ici des wrappers des fonctions M$ qui reproduisent la spec de snprintf() :
http://www.developpez.net/forums/sho...8&postcount=14

Selon la version de Visual que tu utilises (ici, 2005) tu peux commenter les lignes avec _snprintf() et décommenter celle avec _snprintf_s().

[gl]

En effet, M$ a refusé C99, préférant leur "secure CRT" 100% non-portable.

C'est un poil plus complique que ca, ce n'est pas une invention Microsoft : http://www.open-std.org/jtc1/sc22/wg...docs/n1199.pdf

[psyphi]

Pourquoi tu rajoutes des underscores '_' devant les fonctions ?

[Médinoc]

Parce que le _snprintf() microsoft en possède un...
Heureusement d'ailleurs, car il ne correspond pas à la spec: Il n'en a ni les garanties ni la valeur de retour.
Quant à _scprintf(), c'est une fonction Microsoft qui possède un underscrore, c'est dans la doc.

[Médinoc]

gl : Ils ne collent quand même pas à ce standard pour autant, ils n'utilisent même pas les noms standard pour les macros (__STDC_WANT_SECURE_LIB__ au lieu de __STDC_WANT_LIB_EXT1__) et les fonctions (_set_invalid_parameter_handler() au lieu de _set_constraint_handler_s())...

Edit: D'ailleurs, leur vsnprintf_s() et consorts ne correspond pas non plus (carrément pas le même nombre d'argument). Sans compter strtok_s(), qui est une implémentation très tardive de strtok_r() chez MS, et qui a un paramètre ne plus dans le standard...
Donc, ils restent non-portables...

Edit2: Tiens, c'est sans doute un changement compris dans le SP1, à présent ils conseillent _CRT_SECURE_NO_WARNINGS au lieu de _CRT_SECURE_NO_DEPRECATE, et le __declspec(deprecated(_Text)) n'indique plus "deprecated" dans le warning...

[gl]

gl : Ils ne collent quand même pas à ce standard pour autant, ils n'utilisent même pas les noms standard pour les macros (__STDC_WANT_SECURE_LIB__ au lieu de __STDC_WANT_LIB_EXT1__) et les fonctions (_set_invalid_parameter_handler() au lieu de _set_constraint_handler_s())...

Vu les dates de publication du document et de Visual Studio, je suis bien en peine de dire si Microsoft a pris des libertes (voire reinventer) ce "standard" ou si le document a evolue entre temps.
Il n'en reste pas moins que ces fonctions n'est pas une pure invention de Microsoft.

[dj.motte]

Bonjour,

Je pense que je dois donc utilisé la fonction sprintf_s dont je n'avais jamais entendue parler avant, est ce que quelqu'un sait si cette fonction est portable et sera reconnu par gcc (MingW) ?

Non elle ne sera pas portable ( avec MingW de Windows ) .

Par contre il existe de nouvelles possibilités avec la dernière norme du C.

Salut.

[psyphi]

Qu'est ce je dois faire alors entre snprintf qui fonctionne pas avec visual studio et sprintf_s qui ne fonctionne pas avec MingW ?!
Je ne connais pas d'autres fonctions qui réalise la même chose ou alors j'ai pas assez cherché?

[souviron34]

utilises sprintf....

Il suffit de connaître la taille de ta chaîne, c'est la seule différence...

http://www.gnu.org/software/libc/man...Functions.html

....

[psyphi]

Warning: The sprintf function can be dangerous because it can potentially output more characters than can fit in the allocation size of the string s. Remember that the field width given in a conversion specification is only a minimum value.

J'aurais toujours un warning lors de la compilation et il y a un risque de buffer overflow.

[Emmanuel Delahaye]

J'aurais toujours un warning lors de la compilation et il y a un risque de buffer overflow.

Ce warning peut être désactivé

Il y a risque de débordement si on ne sait pas se qu'on fait. Si on code correctement, il n'y a aucun risque. C'est pas comme avec gets() où il n'y a pas moyen d'écrire du code sûr et portable.

[gl]

Qu'est ce je dois faire alors entre snprintf qui fonctionne pas avec visual studio et sprintf_s qui ne fonctionne pas avec MingW ?!

Tu peux utiliser la compilation conditionnelle (#ifdef/#endif) pour appeler snprintf ou sprintf_s selon le compilateur utilise.
De memoire Visual defini _MSC_VER et MingW defini __MINGW32_VERSION.
Pour savoir si le compilateur utilise supporte C99 et donc snprintf, tu peux utiliser la valeur de __STDC_VERSION__

L'ideal etant bien entendu d'encapsuler les appels conditionnels a snprintf/sprintf_s dans une fonction a toi afin de ne pas parsemer le code d'option de compilation.

[psyphi]

Si la chaine à copier est rentrée par l'utilisateur et qu'on ne sait pas à l'avance sa taille, il va bien falloir faire une vérification quelque part, non?

[souviron34]

encore une fois lis les manuels

et la fonction strlen() alors ??

[Emmanuel Delahaye]

Si la chaine à copier est rentrée par l'utilisateur et qu'on ne sait pas à l'avance sa taille, il va bien falloir faire une vérification quelque part, non?

Déjà, il faut commencer par écrire une fonction de saisie correcte qui ne déborde pas ou qui s'adapte (malloc() / realloc()...)

[gl]

Si la chaine à copier est rentrée par l'utilisateur et qu'on ne sait pas à l'avance sa taille, il va bien falloir faire une vérification quelque part, non?

Si tu fais attention a ce que tu codes, il est possible de connaitre les differentes tailles rentrant en jeu.
Il est alors possible soit de dimensionner correctement la chaine resultante (via l'allocation dynamique), soit de ne pas faire l'appel a sprintf si la taille de la chaine resultante est trop importante.

[psyphi]

encore une fois lis les manuels

et la fonction strlen() alors ??

Non mais bon quand même hein .

Si tu fais attention a ce que tu codes, il est possible de connaitre les differentes tailles rentrant en jeu.
Il est alors possible soit de dimensionner correctement la chaine resultante (via l'allocation dynamique), soit de ne pas faire l'appel a sprintf si la taille de la chaine resultante est trop importante.

du genre

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
if(strlen(chaine) > taille_max)
   fprintf(stderr, "Erreur ");
else
    sprintf(...);

Enfin bon là n'est pas le problème c'est dommage de ne pouvoir utilisé snprintf. Il faut de toute manière utilisé des directives pour supprimer les warnings ou pour s'adapter en fonction du compilateurs.

Merci de vos commentaires et propositions.

[souviron34]

Si la chaine à copier est rentrée par l'utilisateur et qu'on ne sait pas à l'avance sa taille, il va bien falloir faire une vérification quelque part, non?

ya 1 truc que je comprend pas :

1) soit tu lis caractère par caractère, et tu réalloues au fur et à mesure, à partir d'une taille initiale

2) soit tu prévois TRES grand au départ, quiite à réallouer à la bonne taille à la fin..

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
      malloc ( 50000 )
 
      realloc (  , (strlen() + 1) )

m'étonnerais que quelqu'un rentre 50000 caractères en ligne.....

[psyphi]

m'étonnerais que quelqu'un rentre 50000 caractères en ligne.....

Un utilisateur non mais un programme oui
Se fait très vite avec perl d'installer:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$ gcc -o demo demo.c
$ ./demo `perl -e 'print "A"x50000'`

Le crackeur à plus qu'a attendre que ça plante et y injecter son shellcode.