Discussion :

[Emmanuel Delahaye]

Les fonctions utilisant la mémoire sous C ont toutes été déprécies

par Microsoft. L'intention est bonne, mais pour le moment, ce n'est pas standard. Il n'empêche que les fonctions standards peuvent être utilisées de façon tout à fait sure par un programmeur qui sait ce qu'il fait et qui sait de quoi il parle. Le C, c'est pas un langage de bricoleurs... C'est un langage de professionnel, issu de l'industrie... C'est pas un langage jouet pour débutants...

en faveur des fonctions xxx_s pour empêcher les buffer overflow. Un buffer Overflow permet à un malatentioné de prendre le contrôle de la machine en passant par des droits root..et il y a beaucoup d'exemples sur le net qui expliquent ce genre d'attaque

Je seul cas vraiment critique est gets() que l'on ne peut pas utiliser portablement de façon sûre. Le reste, ça va si on est pas complètement gruyèrisé par Alzheimer...

Faut pas se laisser éblouir par la propagande de Microsoft....

[Médinoc]

La moitié (et je suis gentil) des fonctions xxx_s() de microsoft sont inutiles.

• memmove_s() n'a aucun intéret, on a déjà un paramètre taille.
• sprintf_s() ne sert pas à grand-chose, même si ça donne un plantage "plus récupérable" qu'un banal sprinf(). Mais ça n'arrive pas à la cheville du snprintf() standard C99, qu'ils n'ont pas voulu implémenter.
• fopen_s() ne sert absolument à rien.
• strtok_s() est bien gentil, mais ils auraient pu lui donner son vrai nom POSIX...

Mais le pompon, c'est leur nouvelle fonction d'allocation sur la pile: Ils ont déprécié alloca() et créé à la place malloca(), qui nécessite un appel à freea() pour libérér. Bizarrement, pas un d'eux ne s'est souvenu que c'est justement grâce à l'absence de fonction de libération que les gens utilisaient alloca() à l'origine...

[Melem]

Ah bon ? Et le paramètre taille il sert à quoi ? A la déco de Noël ? Evidemment, il ne faut pas passer n'importe quoi comme paramètre...

Pour les fonctions str* et mem* ça va, mais sprintf par exemple n'est pas épargné (il y a snprintf, mais ce n'est pas sprintf).

Le risque du buffer overflow face à un utilisateur mal intentionné se situe au niveau des entrées, pas dans les entrailles du programme. Dans un programme bien conçu il n'y a aucun risque d'un tel danger même en utilisant strcpy ou memcpy etc.
...
Et enfin, si tu veux des fonctions "sécurisées" tu n'as qu'à implémenter les tiennes. Mais jusqu'où va cette sécurité en fait? Si le programme est bien écrit, il n'y a pas vraiment de différence à utiliser memcpy ou memcpy_s ...

L'interêt d'utiliser les fonctions sécurisées de Microsoft ne se joue pas eulement au niveau du contrôle de la taille du buffer de destination, la société ayant déjà avancé ses explications (Security Enhancements in the CRT), je ne vois aucun interêt de le refaire.

[souviron34]

en bref, sur un forum consacré au C, tu conseilles de faire comme pour Java et comme pour HTML : transformer quelque chose de standard en quelque chose de uniquement M$-compatible...

Bravo .. ça j'appelle ça de l'ouverture d'esprit !!

Et je répéterais que je ne comprends pas le problème : si on sait ce qu'on fait, ça ne plante JAMAIS.

[Médinoc]

L'interêt d'utiliser les fonctions sécurisées de Microsoft ne se joue pas eulement au niveau du contrôle de la taille du buffer de destination, la société ayant déjà avancé ses explications (Security Enhancements in the CRT), je ne vois aucun interêt de le refaire.

Bulls**t pour la plupart des explications, car les fonctions sans "_s" valident également leurs paramètres un minimum, et le coup des errno pour fopen_s() par exemple ne tient pas la route contre la perte de portabilité.

Edit: Voir aussi: http://blogs.msdn.com/vcblog/archive...rd-update.aspx. Surtout les commentaires.

[kakibend]

Merci pour le lien..très intéressant.

Sinon le problèmes des fonctions en _s ne relèvent pas justement que de Windows, l'ISO a sorti un document normalisant ce genre de fonction (ISO/IEC WDTR 24731 [URL="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf"[/URL]), il reste à savoir si les autres compilateurs seront tenus à suivre ce nouveau "standard"...Je suis tout à fait d'accord qu'un code bien fait résout empêche tout problème mais s'il faudra utiliser ces fonctions standardisées pourquoi pas?

Bulls**t pour la plupart des explications, car les fonctions sans "_s" valident également leurs paramètres un minimum, et le coup des errno pour fopen_s() par exemple ne tient pas la route contre la perte de portabilité.

Edit: Voir aussi: http://blogs.msdn.com/vcblog/archive...rd-update.aspx. Surtout les commentaires.

[Emmanuel Delahaye]

Sinon le problèmes des fonctions en _s ne relèvent pas justement que de Windows, l'ISO a sorti un document normalisant ce genre de fonction (ISO/IEC WDTR 24731 [URL="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf"[/URL]),

Non, pas de chance, c'est pas dans n1124, ça se saurait !

[Melem]

Ouais il s'est trompé de lien. C'est plutôt le 1135, pas le 1124. Mais c'est qu'un Technical Report, suite à la demande de Microsoft de normaliser ces fonctions paraît-il?