En implementaciones con un modelo de memoria plana (básicamente todo), la conversión a uintptr_tJust Work.
(Pero consulte ¿Deben las comparaciones de punteros estar firmadas o no en x86 de 64 bits? Para analizar si debe tratar los punteros como firmados o no, incluidos los problemas de formar punteros fuera de los objetos que es UB en C.)
Sin embargo, los sistemas con modelos de memoria no planos existen, y pensando en ellos puede ayudar a explicar la situación actual, como C ++ que tienen diferentes especificaciones de <frente std::less.
Parte del objetivo de los <punteros para separar objetos siendo UB en C (o al menos no especificado en algunas revisiones de C ++) es permitir máquinas extrañas, incluidos modelos de memoria no planos.
Un ejemplo bien conocido es el modo real x86-16 donde los punteros son segmentos: offset, formando una dirección lineal de 20 bits (segment << 4) + offset. La misma dirección lineal se puede representar mediante múltiples combinaciones seg: off diferentes.
C ++ std::lessen punteros en ISA extraños puede necesitar ser costoso , por ejemplo, "normalizar" un segmento: desplazamiento en x86-16 para tener un desplazamiento <= 15. Sin embargo, no hay una forma portátil de implementar esto. La manipulación requerida para normalizar a uintptr_t(o la representación de un objeto puntero) es específica de la implementación.
Pero incluso en sistemas donde C ++ std::lesstiene que ser costoso, <no tiene que serlo. Por ejemplo, suponiendo un modelo de memoria "grande" donde un objeto cabe dentro de un segmento, <puede comparar la parte de desplazamiento y ni siquiera molestarse con la parte del segmento. (Los punteros dentro del mismo objeto tendrán el mismo segmento, y de lo contrario es UB en C. C ++ 17 cambiado a simplemente "no especificado", lo que podría permitir omitir la normalización y solo comparar las compensaciones). Esto supone que todos los punteros a cualquier parte de un objeto siempre usa el mismo segvalor, nunca normalizando. Esto es lo que esperaría que requiera un ABI para un modelo de memoria "grande" en lugar de "enorme". (Ver discusión en comentarios ).
(Tal modelo de memoria podría tener un tamaño máximo de objeto de 64 kB, por ejemplo, pero un espacio de dirección total máximo mucho mayor que tiene espacio para muchos de esos objetos de tamaño máximo. ISO C permite que las implementaciones tengan un límite en el tamaño del objeto que sea inferior al el valor máximo (sin signo) size_tpuede representar, SIZE_MAXpor ejemplo, incluso en sistemas modelo de memoria plana, GNU C limita el tamaño máximo del objeto para PTRDIFF_MAXque el cálculo del tamaño pueda ignorar el desbordamiento firmado). Vea esta respuesta y discusión en los comentarios.
Si desea permitir objetos más grandes que un segmento, necesita un modelo de memoria "enorme" que tenga que preocuparse por desbordar la parte de desplazamiento de un puntero al hacer p++un bucle a través de una matriz, o al hacer indexación / aritmética de puntero. Esto conduce a un código más lento en todas partes, pero probablemente significaría que p < qfuncionaría para punteros a diferentes objetos, porque una implementación dirigida a un modelo de memoria "enorme" normalmente elegiría mantener todos los punteros normalizados todo el tiempo. Ver ¿Qué son los punteros cercanos, lejanos y enormes? - algunos compiladores reales de C para el modo real x86 tenían una opción para compilar para el modelo "enorme", donde todos los punteros predeterminados a "enorme" a menos que se declare lo contrario.
La segmentación x86 en modo real no es el único modelo de memoria no plano posible , es simplemente un ejemplo concreto útil para ilustrar cómo ha sido manejado por las implementaciones de C / C ++. En la vida real, las implementaciones extendieron ISO C con el concepto de punteros farvs. near, permitiendo a los programadores elegir cuándo pueden salirse con solo almacenar / pasar alrededor de la parte de desplazamiento de 16 bits, en relación con algún segmento de datos común.
Pero una implementación pura de ISO C tendría que elegir entre un modelo de memoria pequeño (todo excepto el código en el mismo 64 kB con punteros de 16 bits) o grande o enorme con todos los punteros de 32 bits. Algunos bucles podrían optimizar incrementando solo la parte de desplazamiento, pero los objetos de puntero no podrían optimizarse para ser más pequeños.
Si supieras cuál es la manipulación mágica para cualquier implementación dada, podrías implementarla en C puro . El problema es que diferentes sistemas usan direcciones diferentes y los detalles no están parametrizados por ninguna macros portátil.
O tal vez no: podría implicar buscar algo desde una tabla de segmentos especial o algo así, por ejemplo, como el modo protegido x86 en lugar del modo real donde la parte del segmento de la dirección es un índice, no un valor que se debe cambiar. Puede configurar segmentos parcialmente superpuestos en modo protegido, y las partes del selector de segmento de las direcciones ni siquiera se ordenarán necesariamente en el mismo orden que las direcciones base del segmento correspondiente. Obtener una dirección lineal desde un puntero seg: off en modo protegido x86 podría implicar una llamada al sistema, si el GDT y / o LDT no se asignan a páginas legibles en su proceso.
(Por supuesto, los sistemas operativos principales para x86 usan un modelo de memoria plana, por lo que la base del segmento siempre es 0 (excepto para el almacenamiento local de subprocesos que usa fso gssegmentos), y solo la parte de "desplazamiento" de 32 bits o 64 bits se usa como puntero .)
Puede agregar código manualmente para varias plataformas específicas, por ejemplo, asumir de forma predeterminada plano o #ifdefalgo para detectar el modo real x86 y dividirlo uintptr_ten mitades de 16 bits para seg -= off>>4; off &= 0xf;luego combinar esas partes nuevamente en un número de 32 bits.