El bug de la semana

Ha sido muy difícil de encontrar el muy *#?$@. Es una de las pegas de trabajar con lenguajes interpretados, y PHP no es menos problemático que el resto en estos casos.

El aviso del cliente es poco más que extraño: cuando vamos a imprimir etiquetas recien generadas, la primera vez que se imprimen el PDF generado no es correcto (faltan etiquetas). Si a continuación volvemos a imprimir, entonces sí se genera bien :o.

Después de ojear las muestras de etiquetas generadas por el cliente veo que no hay un patrón: a veces falta una página completa, a veces una etiqueta, la mayoría de las veces no falla. Y lo peor de todo, no consigo reproducir el error en la instalación que tengo para desarrollo.

Bueno, les presento el error:

...
for($i; $i<$sql->num_rows($nota); $i++)
{
	$row=$sql->result_row($nota);
...

Cuando se recorrían las etiquetas pertenecientes a una nota de fabricación, se contaban elementos de menos porque había escrito mal la inicialización de la variable $i (falta el =0).

¿Qué causaba ese comportamiento tan extraño? Probablemente porque PHP no inicializa las variables a 0, o al menos no lo hace en la versión que está corriendo el cliente (diferente a la que tengo en desarrollo; lo sé... no es buena idea). Así que no siempre la memoria que se cogía para esa variable contenía un cero (casualmente), y por eso el número de etiquetas mostradas variaba, incluso hasta el punto de, a veces, funcionar correctamente el algortimo :).

PHP no nos advierte y no hay nada en los logs de Apache. Si miramos la documentación de for veremos que no tenía porqué: se espera una expresión y $i lo es. Así que a releer el código hasta dar con el problema.

Seguro que a más de uno le ha llevado de cabeza un fallo de este estilo.