Eso de experto lo dije porque esta frase:

¿Al menos sabes por qué la solución que le di le funcionó?:

me había sonado un poco condescendiente, como si fuera demasiado complicado para que alguien (yo) lo entendiera. En fin.

Sólo puntualizar una cosa. No es que almacenar el valor de un puntero en un entero como size_t esté mal en sí. Como había dicho antes, a veces se hace; la propia API de Windows es un ejemplo. Pero aunque en todos los sistemas actuales size_t es lo suficientemente grande para guardar direcciones, no hay garantía de que siempre sea así, y en los casos donde no lo sea, el resultado quedaría indefinido (por ejemplo, en DOS de 16 bits, el programa seguramente no funcionaría correctamente, al menos si se compila para modelo compact, large, etc.) por lo que, si no es estrictamente necesario no se debería hacer.

No dije ser experto, sólo que algo de experiencia sí que tengo. Estoy de acuerdo en que experimentar y equivocarse es indispensable para aprender, aunque normalmente yo trato de señalar cuando algo no es del todo correcto, sobre todo en cuestiones relacionadas con punteros, que puede ser un tema confuso.


El problema no es si es direccionable o no por el programa. Como había mencionado en otro comentario, aunque es una idea muy extendida, el objetivo de size_t no es almacenar direcciones. Nunca fue creado para eso, y de hecho, existen plataformas donde tiene un tamaño menor a un puntero, por lo que es totalmente posible, y probable, tener variables cuyas direcciones no pueden ser almacenadas en un size_t. Eso es válido, ya que la especificación de C dice expresamente que aunque un puntero puede convertirse a cualquiera de los tipos enteros (incluyendo size_t), puede no caber, y que en ese caso, el comportamiento del programa queda indefinido. En la práctica, en casi todas las arquitecturas actuales sí tiene el tamaño suficiente, y por eso no es tan raro almacenar direcciones en variables enteras (aunque normalmente se usa directamente el long o unsigned long), sin embargo, no hay garantías. Por eso se incorporaron a C los tipos opcionales intptr_t y uintptr_t, los únicos con los que es seguro almacenar punteros (siempre que no sean punteros a funciones). Por cierto, tampoco se requiere que size_t tenga el tamaño de una palabra, aunque eso es lo habitual.


size_t* puede direccionar la memoria, como el resto de punteros, aunque aquí también, C dice que punteros a diferentes tipos pueden tener tamaños distintos, por lo que en teoría sólo deberían apuntar a memoria donde haya un valor size_t. Claro que en la realidad es prácticamente seguro que todos los punteros tengan el mismo tamaño, exceptuando, otra vez, los punteros a funciones. Ni siquiera void* es válido para apuntar a funciones. Para eso únicamente se deben usar punteros a funciones. Y por supuesto, desreferenciar un puntero que apunta a un dato cuyo tipo no es el mismo que el del puntero es arriesgado. No sólo puede haber problemas de alineación o tamaño, sino que a veces los compiladores, apegándose a lo que dicen las reglas, hacen optimizaciones que rompen código que accede a direcciones por medio de punteros a tipos distintos. Según su rígida interpretación, dado que un puntero de tipo A "no puede" apuntar a un valor de un tipo distinto a A, el compilador no está obligado asegurar que ese acceso se produzca correctamente, y si se rompe algo, toda la culpa es del programador. Eso ha pasado con el kernel Linux, por ejemplo, y hay mucho debate al respecto.

Lo de memorias con segmentos es un ejemplo. En el caso de DOS de 16 bits, para modelo large, por ejemplo, típicamente size_t es de 16 bits, pero los punteros ocupan 32. En este caso específico (x86) sí sería porque contienen segmentos, pero aún en ausencia de segmentación, otras arquitecturas pueden tener punteros más grandes que size_t por motivos diferentes.

Hasta donde yo se no hay ninguna garantía que un programa en C pueda usar un puntero void* para almacenar punteros a funciones (los punteros de funciones pueden usar otro tipo de direccionamiento). Había un apartado en la especificación en la que dejaba esto en claro. Hay otros estándares y extensiones que quizás puedan agregar esa limitación pero al menos el estándar en C no ofrece esa garantía.

Esto ya se sale fuera del tema.