Barrapunto

La medida crea más problemas de los que se supone que va a solucionar. Obviamente, es necesario asegurarse de que el número de bytes que vas a escribir nunca es mayor que el tamaño del bloque de memoria donde escribes, pero la solución que proponen es para partirse de risa.

En primer lugar, este cambio exige modificar una cantidad de código inmensa. No sólo hay que cargar a cuestas con el parámetro adicional que memcpy_s [microsoft.com] exige, sino que además hay que procesar el nuevo valor devuelto por la función y decidir qué hacer cuando se produzca un desbordamiento que no debería producirse nunca. ¿Qué harías tú? ¿Salir del programa, lanzar una excepción (C++), cancelar el trabajo y devolverlo a la función padre? ¿Y la función padre también habrá que cambiarla?

Pero no sólo esto, porque si se equivocan en el valor que le pasan como tamaño del "buffer" destino, entonces ojalá se equivoquen por defecto o estaremos en las mismas, y si se olvidan de recoger el valor devuelto (o lo hacen mal), entonces ojalá en ejecución no supere el límite establecido, porque el "buffer" quedará sin cambios y el programa no hará lo que tiene que hacer, ni se va a acercar, aunque si en ese caso falla y quieres que copie todo lo que pueda siempre puedes volver a llamar otra vez a strcpy_s reduciendo la cantidad copiada al tamaño del buffer, y si vuelve a dar error por un puntero NULL, entonces... jajajaja

¿En qué puñetas están pensando estos de Redmond?

Aquellos que no comprobaban que 'n' era menor o igual que el tamaño del destino antes de llamar a memcpy, son los que ahora ignorarán el warning que les saltará cuando la utilicen.

Es mucho menos engorroso, desde el punto de vista del programador perezoso, ignorar un warning que cambiar una llamada a una función. Del mismo modo que les resulta menos engorroso hacer la llamada sin comprobar los tamaños.

Vamos, que no creo que esto vaya a solucionar nada en absoluto. Los que lo hacían mal seguirán haciéndolo mal. Los que lo hacían bien seguirán haciéndolo bien. Si quieren cambiar algo, que eliminen el memcpy de la lista de llamadas.

De todos modos, no me parece que memcpy sea una llamada especialmente arriesgada. Me gustaría saber cuántos desbordamientos son debidos a memcpy. La peligrosa era strcpy, que se "sustituyó" por la versión segura, strncpy, que justamente añade una comprobación del tipo de memcpy.

warning: C4996: 'localtime': This function or variable may be unsafe. Consider using localtime_s instead.
warning: C4996: 'strcpy_s': This function or variable may be unsafe. Consider using strcpy_s instead.
warning: C4996: 'strtok': This function or variable may be unsafe. Consider using strtok_s instead.
warning: C4996: 'strcat': This function or variable may be unsafe. Consider using strcat_s instead.
warning: C4996: 'fopen': This function or variable may be unsafe. Consider using fopen_s instead.
warning: C4996: 'fprintf': This function or variable may be unsafe. Consider using fprintf_s instead.
warning: C4996: 'fscanf': This function or variable may be unsafe. Consider using fscanf_s instead.
... la lista sigue y sigue ...

Aprecio mucho los esfuerzos de Microsoft por hacer la librería estándar más segura, aunque el C nunca fué diseñado para ser un lenguaje de programación seguro. Pero sería importante que estas mejoras las propuesieran en futuras revisiones de ANSI C/C++ y mientras tanto ceñirse al estándar. Así facilitaría a los programadores el hacer códigos más exportables y evitarnos esos molestos warnings.

Pasamos de:

memcpy(pDst, pSrc, MIN(lDst, nBytes));

A:

memcpy_s(pDst, lDst, pSrc, nBytes);

Que es más corto y más natural (parejas buffer - tamaño). Además no hay una macro de por medio, "obliga" a tener en cuenta lDst, etc.

IMHO Es un pequeño cambio y la ganancia también es pequeño pero el balance es positivo.

¿Consideras un argumento en contra de Linux que una distribución enterita como Ubuntu tenga 5 fallos de seguridad más que un windows XP a pelo?
Tu comparación es como decir que en todo EEUU se producen 5 accidentes más de tráfico que en España

Además de lo que te dice Vacatalada, esta el hecho del tiempo en que tardan en arreglarse las vulnerabilidades, que es muy importante.

Yo tengo otras estadísticas mucho más reconocidas que una imagen de origen desconocido (Hay que bajar para abajo para ver las gráficas de tarta):

Vulnerabilidades de Win XP Professional [secunia.com]
Vulnerabilidades de Win Vista [secunia.com]
Vulnerabilidades de Ubuntu 8.10 [secunia.com]
Vulnerabilidades de Ubuntu 9.04 [secunia.com]

Joder, si tienen que impedir el uso de una función para que los programadores no metan la gamba, tu me dirás de que lado está el problema....

Decídelo bien.

Me esfuerzo, de verdad que me esfuerzo en ver el sarcasmo en tu comentario...xDD