Existe alguna directiva para inicializar variables tipo objeto a Nil?
 

Un saludo al foro.

Estoy dando mantenimiento y portando código de 32 a 64 bits (D7 a XE3) que supera los dos millones de lineas de código, se complica el asunto de depuración porque un ejecutable hace llamadas a varios DLLs COM al mismo tiempo y son cajas negras, o depuro el EXE o depuro el DLL; tengo el código de todos ellos. Entre los detalles que me han surgido hay uno que da dolores de cabeza y espero que se pueda resolver de manera rápida para no urgar las dos millones de lineas:

• Como procedimiento de programacion típico de los otros programadores anteriores se declaran variables locales tipo TDataSet dentro de los DLLs que al final del Método se destruyen con FreeAndNil, pero no siempre se crean las instancias, por ejemplo si se cumple un IF se llama al TDataSet.Create(), si no se cumple, la variable no se utiliza nunca.
• Al terminar el procedimiento se intenta liberar todas las variables con FreeAndNil, hayan sido o no instanciadas.
• Si no ha sido instanciada, la variable tiene una referencia inválida ya que nunca se le asignó Nil al iniciar (el programador anterior asumió que se inicializaban las variables de manera predeterminada :confused:) y el FreeAndNil falla estrepitosamente con un Access violation read of address ... (con las versiones de 32 bits de los DLLs no ocurre, con las de 64 bits, sí), el mensaje casi nunca dice que address sea 0 o puras FFFs lo que sería indicativo de que es algo no asignado, por lo que nos fuimos a depurar los procesos y tardamos 4 dias la primera vez en localizar la fuente del error... dentro del bloque except end :eek:, el principal.

He leido que se inicializan a cero, vacio, nil o lo que aplique las variables de objetos (fields), variables globales, pero no las variables locales.

Pues bien, la solucion fué asignar Nil a todas las variables antes de utilizarlas, pero por la cantidad de código y métodos que tienen el mismo defecto es una tarea titánica y por los calendarios asignados no nos dan tiempo para esta tarea, por lo cual mi duda es saber si existe una directiva de compilación que haga que se inicialicen a Nil de manera automática los punteros y variables de objeto.

Gracias

[Resuelto]
 

Saludos al foro

Hemos encontrado el problema de las excepciones y comparto la solución para quien pueda servirle.

El proyecto originalmente consta de un lado cliente EXE y un lado servidor DLL DCOM, originalmente todo bajo D7 a 32 bits. Cuando se hizo la portación del código servidor de D7 a XE3 para 32/64 bits, empezaron a surgir errores extraños que detectamos eran fallas de FreeAndNil por objetos no inicializados dentro de los DLL compiladas con XE3 para 64 bits, extrañamente el mismo código compilado con XE3 para 32 bits no marcaba excepciones. Hicimos pruebas con código casi identico al del proyecto combinando SO de 32/64 bits con EXE 32 bits y DLLs 32/64 bits y la unica combinacion que no marcaba error fue DLL creados con D7 corriendo en Win 64, contrario a la documentacion de Borland/Embarcadero que dice que las variablesl locales no se inicializan y de entrada traen basura, en los watch aparecian inicializadas a nil dentro del DLL, esta extraña condicion siempre estuvo presente y por esta razon no habia excepciones. Este fue el primer detalle curioso.

Después de una maratónica sesión de google y de una lista de posibles causas, la última razón y que nadie creyó posible, fué investigar la convencion de llamada safecall (usada casi exclusivamente en interfaces DCOM) ya que en la declaracion de los eventos y métodos que generamos en las pruebas no aparece, siendo la convencion predeterminada register si no me equivoco, resulta que la particularidad que tiene safecall es establecer un "firewall" para las excepciones entre el invocador y el método invocado, aunque existan errores en el DLL no llegan al cliente y como la liberacion estaba en un bloque try finally end, se hacia todo el proceso al 100% y desaparecia la excepcion por arte de magia, ya que se debe preguntar a traves de una interfaz al objeto DCOM; al parecer siempre hubo errores pero nunca salieron a la luz.

Sumado a esto, la documentación técnica dice que para X64 ya solo existe un solo tipo de llamada y dejan de existir los fastcall, register, cdecl, safecall, etc. y obviamente esto hizo desaparecer la barrera para las excepciones y fué la receta perfecta para el desastre.

En resumen, safecall ocultaba las excepciones en 32 bits y en 64 bits solo existe un tipo de llamada y se manifestaron los errores.

Ahora solo queda buscar esas lineas propensas a fallos a ojo pelón :eek: adiós dia lunes no laborable...

Gracias por ir compartiendo tus descubrimientos. Imagino que aún está poca gente convirtiendo de 32 a 64, así que todas las luces que se vayan aportando será camino ganado cuando nos toque al resto. Un saludo.