Simular uniones C++

[Jonny]

Hola

:)

Chefito dijo: Anda y cambialo.

uuuups!. Al final me acabé haciendo un taco, habiéndolo entendido. ¡editado!.

Chefito dijo: . Como quitas eso? Con eso accede al primer argumento de la estructura (wType, lo que pasa que no pone el nombre del parámetro, solo pone su tipo uint)

Vaya. Es que, no había visto esta forma de crear una estructura. Entonces, digamos que $Type, es la misma estructura que creamos fuera de la función de ProgAndy; de la que pasamos el puntero a la función, para crear la estructura correcta ¿no?.

Bueno, sí había visto declarar una estructura solo poniendo los tipos, lo que no sabía que poniendo en el segundo argumento de DllStructCreate() el puntero de una estructura, era como hacer una copia de esta. Entonces, la dejaré sin modificar nada.

Chefito dijo: Mira en google la representación de números en hexadecimal, que para un programador es esencial.

Pues sí. Voy a mirarlo, que siempre me estoy peleando con eso...

Espero que ahora estén mejor las dos funciones, que he editado en el otro post.

Salu2!

[Ximorro]

Vale, creo que no puse el ejemplo más adecuado, quizás tendría que haber puesto otro ejemplo pero pensé que como ese era el que usaba todos los bytes de la estructura era más complejo.
Ciertamente al ser esa subestructura de campos de tipo byte se podría acceder a ellos simplemente por índice, pero no era mi intención. Mi intención era mostrar cómo remapear la estructura (dándole otro formato pero usando los mismos datos gracias a DllStructGetPtr). En este caso quizás sólo sirve para dar nombre a los campos, en los otros casos también sirve para cambiar el tipo (de ristra de bytes a dword, por ejemplo). Así que de acuerdo que fui poco afortunado al elegir el ejemplo.
El código era incompleto, sólo era un ejemplo de remapeo, faltan los demás, mi intención era mostrar la técnica a usar.

Sigo sin estar de acuerdo con no reservar la memoria suficiente para la estructura. No es necesario que pienses que alguien va a hacer un virus, hay otros escenarios en los que puede fallar. No sabes cómo las funciones internas usan esos datos, piensa por ejemplo que la estructura interna tiene esos bytes dummy y pad que "no se usan para nada". ¿Para nada? Eso es lo normal, pero ¿y si la dll los usa para cálculos intermedios? ¿o si meten códigos de error no documentados o cosas así?

No se trata de ser paranoico, ¿pero para qué arriesgarse? La realidad es que esos bytes existen y aunque la documentación dicen que no se usan podrían usarse de forma interna. Los programadores saben que eso está ahí y podría darles por usarlo. Lo sencillo es hacer las cosas bien y reservar la memoria que requiere la estructura, a partir de ahí que hagan lo que quieran con ella. Y si escriben en bytes que se supone que no hay nada no estarán escribiendo en zonas de memoria que pertenecen a otros datos.
Quizás estáis orientados a ignorarlos porque se llaman dummy y pad, pero yo los veo como si se llamaran reserved, podrían usarse en el futuro o estar usándose ahora en cosas internas. Y si no es así no va a fallar porque definamos bien la estructura, pero sí puede fallar si no la definimos completa.

(Chefito, yo cuando escribo algo largo o a trozos me abro un notepad y copio el texto, por si acaso Y sí, porque también he sufrido lo mismo alguna vez )