J'aime de Robert de réponse, mais j'ai aussi quelques points de vue sur les questions que j'ai soulevées.
- Utilisez-vous une bibliothèque ou un compilateur avec le soutien de la TR24731-1 fonctions?
Non, je n'ai pas.
- Si oui, le compilateur ou à la bibliothèque et sur quelle plate-forme(s)?
Je crois que les fonctions sont fournis par MS Visual Studio (MS VC++, Édition 2008, par exemple), et il y a des avertissements pour vous encourager à les utiliser.
- Avez-vous de découvrir des bugs comme un résultat de la fixation de votre code pour utiliser ces fonctions?
Pas encore de. Et je ne vous attendez pas à découvrir de nombreuses dans mon code. Certains de l'autre code que j'ai de travailler avec - peut-être. Mais j'ai pas encore convaincue.
- Les fonctions qui apportent le plus de valeur?
J'aime le fait que le printf_s() de la famille de fonctions de ne pas accepter le"%n' spécificateur de format.
- Il n'existe aucun qui n'apportent aucune valeur ou une valeur négative?
L' tmpfile_s() et tmpnam_s() fonctions sont une horrible déception. Ils ont vraiment besoin de travailler plus comme mkstemp() qui à la fois crée le fichier et l'ouvre pour s'assurer il n'y a pas de TOCTOU (temps de vérifier, le temps de la consommation de la vulnérabilité. En l'état actuel, ces deux apportent que très peu de valeur.
Je pense aussi qu' strerrorlen_s() fournit très peu de valeur.
- Êtes-vous planification de l'utilisation de la bibliothèque dans l'avenir?
Je suis dans deux esprits à ce sujet. J'ai commencé à travailler sur une bibliothèque qui permettrait de mettre en œuvre les capacités de TR 24731 sur une bibliothèque standard C, mais a été pris par le montant de l'unité de test nécessaires pour démontrer qu'il fonctionne correctement. Je ne suis pas sûr que ce soit de continuer. J'ai un code que j'ai envie de port pour Windows (principalement d'un pervers désir d'apporter un soutien sur toutes les plateformes, il travaille sur des dérivés d'Unix pour un couple d'années maintenant). Malheureusement, pour la compiler sans mise en garde de la MSVC compilateurs, je le plâtre le code avec des trucs pour éviter MSVC wittering sur moi, en utilisant le parfaitement fiable (utilisé avec précaution) fonctions de la bibliothèque C standard. Et ce n'est pas appétissant. Il est assez mauvais que je dois traiter avec plus de deux décennies d'un système qui s'est développé au cours de cette période, d'avoir à traiter avec l'idée de quelqu'un de plaisir (faire les gens à adopter TR 24731 quand ils n'ont pas besoin), c'est ennuyeux. C'est en partie pourquoi j'ai commencé le développement des bibliothèques, - de m'autoriser à utiliser les mêmes interfaces sur Unix et Windows. Mais je ne suis pas sûr de ce que je vais faire à partir d'ici.
- Êtes-vous le suivi de l'TR24731-2 travail?
Je n'avais pas été suivi jusqu'à ce que je suis allé aux normes site lors de la collecte des données pour la question. L' asprintf() et vasprintf() fonctions sont probablement utile; j'avais de l'utiliser. Je ne suis pas certain à propos de la mémoire de flux I/O fonctions. Ayant strdup() normalisées au niveau C serait un énorme pas en avant. Cela semble moins sujet à controverse pour moi que la partie 1 (la vérification des limites) des interfaces.
Dans l'ensemble, je ne suis pas convaincu par la partie 1 de " Vérification de Limites des Interfaces. Le matériel contenu dans le projet de la partie 2 'Allocation Dynamique des Fonctions' est mieux.
Si ça ne tenait qu'à moi, je voudrais déplacer un peu le long de la lignes de la partie 1, mais je voudrais aussi révisé les interfaces dans le standard C99 bibliothèque C qui renvoient char * pour le début de la chaîne (par exemple, strcpy() et strcat()), de sorte qu'au lieu de retourner un pointeur sur le début, ils me renvoient un pointeur sur l'octet nul à la fin de la nouvelle chaîne. Cela permettrait de faire quelques expressions idiomatiques (comme à plusieurs reprises de la concaténation de chaînes sur la fin de l'autre) plus efficace, car cela permettrait de trivial à éviter l'équation du comportement par le code qui utilise à plusieurs reprises strcat(). Le remplacement serait tout de veiller à ce nul de terminaison de chaînes de sortie, comme le TR24731 versions ne. Je ne suis pas totalement opposé à l'idée de la vérification de l'interface, ni à l'exception des fonctions de gestion. C'est une affaire délicate.
Mise à jour (2011-05-08)
Voir également cette question. Malheureusement, et fatalement à l'utilité de la TR24731 fonctions, les définitions de certaines fonctions diffère entre la mise en œuvre de Microsoft et de la norme, les rendant inutiles (pour moi). Ma réponse il y a de la cites vsnprintf_s().
Par exemple, TR 24731-1 dit que l'interface vsnprintf_s() est:
#define __STDC_WANT_LIB_EXT1__ 1
#include <stdarg.h>
#include <stdio.h>
int vsnprintf_s(char * restrict s, rsize_t n,
const char * restrict format, va_list arg);
Malheureusement, MSDN dit que l'interface vsnprintf_s() est:
int vsnprintf_s(
char *buffer,
size_t sizeOfBuffer,
size_t count,
const char *format,
va_list argptr
);
Paramètres
- tampon - emplacement de Stockage pour la sortie.
- sizeOfBuffer - La taille de la mémoire tampon de sortie.
- compter le nombre Maximum de caractères à écrire (n'incluant pas la valeur null), ou _TRUNCATE.
- format - Format de spécification.
- argptr - Pointeur vers la liste des arguments.
Notez que ce n'est pas simplement une question de type de cartographie: le nombre d'arguments fixes est différent, et donc inconciliables. Il est aussi clair pour moi (et sans doute pour la commission des normes trop) ce qu'il y a un avantage à avoir à la fois "sizeOfBuffer" et "compter"; il ressemble comme deux fois la même information (ou, au moins, le code sera habituellement écrit avec la même valeur pour les deux paramètres).
A l'origine, j'avais l'intention d'utiliser les fonctions comme un moyen d'obtenir un peu de code pour compiler proprement sur Windows et sous Unix, sans avoir à écrire de code conditionnel. Puisque c'est vaincu parce que Microsoft et ISO fonctions ne sont pas toujours les mêmes, c'est beaucoup de temps à donner.
ISO/IEC 9899:2011 - C11 Standard
La norme C11 (décembre 2010 Projet; vous pouvez obtenir une copie PDF de l'définitif de la norme ISO/IEC 9899:2011, à partir de la norme ANSI web store pour 30 USD) a la TR24731-1 fonctionne comme un élément facultatif de la norme. Ils sont définis dans l'Annexe K (vérification de Limites Interfaces), qui est "normatif", plutôt que "d'information", mais c'est facultatif.
Le C11 standard n'ont pas le TR24731-2 fonctions - ce qui est triste parce que l' vasprintf() de la fonction et de ses parents pourrait être vraiment utile.
Rapide résumé:
- C11 contient TR24731-1
- C11 ne contient pas de TR24731-2
