Historias
Slashboxes
Comentarios
 

Login Barrapunto

Login

[ Crear nueva cuenta ]

mig21 (7781)

mig21
  reversethis-{moc.liamg} {ta} {pb12gim}
https://twitter.com/yapw

Hola, soy Miguel. Algo que pueda ser relevante aquí... Uhmm... Me gusta escribir en mi bitácora de BP [barrapunto.com] y en su clon en blogspot: Yet Another Programming Weblog [blogspot.com]
Me gustaría que Barrapunto fuese un sitio con más discusiones técnicas y trato de hacer lo que está en mi mano. De todos modos, también me gusta leer flames ;)

No creo que te interese, pero en Lecturas aleatorias [blogspot.com] dejo registro de los libros que voy leyendo...

Esta es toda mi información de usuario :)

Down Kill Up Publicidad

Bitácora de mig21 (7781)

Miércoles, 09 de Abril 2008

La aritmética de punteros, su desbordamiento y la seguridad

09:07h.
Programación
Me he enterado vía el valle del viento helado de una nueva polémica acerca de gcc y su implementación. El hecho es que gcc cambió su comportamiento en cuanto a comparaciones entre punteros incrementados y ha provocado muchos meses después una alerta de seguridad desproporcionada y según los desarrolladores de gcc, falsa (Se puede oír desde aquí el ruido y la furia)

El caso es que, entrando en profundidad, es una optimización casi "trivial" que hace que p + C1 < p + C2 pase a ser C1 < C2 sin tener en cuenta el posible desbordamiento ( overflow ) de ambas operaciones. Hay que decir además que el estándar (de C y de C++) declara no definido el valor del resultado de la suma entre un puntero y un entero cuando se sobrepasa el tamaño del objeto al que apunta.

Es muy importante este último punto, porque deja traslucir un error de concepto: la comprobación de overflow propuesta en la alerta(*) es muy burda porque sólo se comprueba el desbordamiento de la operación aritmética, no que nos estamos saliendo del rango permitido. Sin embargo lo que deben saber el programador y el programa a la vez, cuando están manejando aritmética de punteros es cual es el desplazamiento (offset) máximo, de cuanta memoria se dispone. Si eso no lo sabe, es inútil cualquier otra comprobación...

Hay que hacer notar además que la optimización de la que se habla aquí la aplican casi todos los compiladores y lo que provoca la alerta es en realidad el cambio de comportamiento, no que sea incorrecto.

También recuerda esto que es muy mala política basar el código en detalles de implementación específicos de la plataforma. En este caso y en muchos otros, los desarrolladores de gcc tiran de cita del estándar para argumentar sus decisiones. Los usuarios se quejan, llamándoles abogados del lenguaje (language lawyer) pero en momentos como esos hay que recordar que probablemente están defendiendo sus decisiones de implementación y lo importante de esas decisiones para el éxito de una tecnología.

(*)char *buf;
  int len;
  len = 1 << 30;
  if (buf+len < buf){ Overflow }
Este hilo ha sido archivado. No pueden publicarse nuevos comentarios.
Mostrar opciones Umbral:
Y recuerda: Los comentarios que siguen pertenecen a las personas que los han enviado. No somos responsables de los mismos.
  • Lo de siempre.

    (Puntos:2)
    por Tom Bomba (3108) el Jueves, 10 Abril de 2008, 07:22h (#1033092)
    ( http://barrapunto.com/ )
    Joé, el C es una herramienta que puede producir efectos sorprendentes pero distintos de los esperados.

    Esto refuerza la importancia del aprendizaje y el sentido común, algo que cada vez más gente olvida.

    Yo, personalmente, creo que se debe aplicar a la aritmética de punteros el mismo control que a la de enteros.

    Salud!

  • por Julio_sao (29798) el Jueves, 10 Abril de 2008, 11:39h (#1033166)
    ( Última bitácora: Lunes, 27 Diciembre de 2010, 18:41h )
    Ese eslogan es increíblemente cierto hoy día con los lenguajes de programación, no es una crítica al lenguaje C/C++, pero esto debería hacer pensar a los que lo defienden como lenguaje para toda clase de proyectos incluso de alto nivel.

    C/C++ proporciona un control sobre la máquina impensable en otros lenguajes entre otras cosas gracias a la aritmética de punteros, pero como toda cosa tiene su "reverso tenebroso" pues el uso de aritmética de punteros provoca que ante cambios en los compiladores nuestro código esté expuesto a este tipo de cosas.

    Es por eso por lo que siempre he defendido el uso de lenguajes de más alto nivel para aplicaciones normales como Pascal, Java, Pyton, C# o incluso VB.NET , dejando C sólo para el motor más básico de la aplicación (o incluso eliminar su uso si el rendimiento de la aplicacion no es un tema muy importante)

    Mas vale usar un lenguaje de alto nivel que usar C si no estás dispuesto a lidiar con estos temas, o si usas C, más te vale estar atento a lo que haces y no confiarte por que "lo tienes dominao" por que te puedes encontrar un problema tan importante como este demasiado tarde.

    El poder conlleva responsabilidad y C no es una excepción.
    --
    JulioSAO xD.
  • 1 respuesta por debajo de tu umbral de lectura actual.