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.