c pointers undefined-behavior memory-model memory-segmentation

¿C tiene un equivalente de std:: less de C++?



pointers undefined-behavior (3)

Hace poco respondí una pregunta sobre el comportamiento indefinido de hacer p < q en C cuando q son punteros en diferentes objetos / matrices. Eso me hizo pensar: C ++ tiene el mismo comportamiento (indefinido) de < en este caso, pero también ofrece la plantilla de biblioteca estándar std::less que garantiza que devolverá lo mismo que < cuando se pueden comparar los punteros, y devolver algunos ordenamiento consistente cuando no pueden.

¿C ofrece algo con una funcionalidad similar que permita comparar de forma segura punteros arbitrarios (con el mismo tipo)? Intenté mirar a través del estándar C11 y no encontré nada, pero mi experiencia en C es mucho menor que en C ++, por lo que podría haber pasado algo por alto fácilmente.

¿C ofrece algo con una funcionalidad similar que permita comparar de forma segura punteros arbitrarios?

No

Primero consideremos solo los apuntadores de objetos . Los punteros de función traen otro conjunto de preocupaciones.

2 punteros p1, p2 pueden tener diferentes codificaciones y apuntar a la misma dirección, por lo que p1 == p2 aunque memcmp(&p1, &p2, sizeof p1) no es 0. Tales arquitecturas son raras.

Sin embargo, la conversión de estos punteros a uintptr_t no requiere el mismo resultado entero que conduce a (uintptr_t)p1 != (uinptr_t)p2 .

(uintptr_t)p1 < (uinptr_t)p2 sí mismo es un código legal, ya que puede no proporcionar la funcionalidad esperada.

Si el código realmente necesita comparar punteros no relacionados, forme una función auxiliar less(const void *p1, const void *p2) y realice allí el código específico de la plataforma.

Quizás:

// return -1,0,1 for <,==,> int ptrcmp(const void *c1, const void *c1) { // Equivalence test works on all platforms if (c1 == c2) { return 0; } // At this point, we know pointers are not equivalent. #ifdef UINTPTR_MAX uintptr_t u1 = (uintptr_t)c1; uintptr_t u2 = (uintptr_t)c2; // Below code "works" in that the computation is legal, // but does it function as desired? // Likely, but strange systems lurk out in the wild. // Check implementation before using #if tbd return (u1 > u2) - (u1 < u2); #else #error TBD code #endif #else #error TBD code #endif }

En implementaciones con un modo de memoria plana (básicamente todo), la conversión a uintptr_t simplemente funcionará.

Pero existen sistemas con modelos de memoria no planos, y pensar en ellos puede ayudar a explicar la situación actual, como C ++ que tiene diferentes especificaciones para < vs. std::less .

Parte del objetivo de < en punteros para separar objetos que son 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 segmento: desplazamiento, formando una dirección lineal de 20 bits a través de (segment << 4) + offset . La misma dirección lineal se puede representar mediante múltiples combinaciones seg: off diferentes.

C ++ std::less en punteros en ISA extraños podría 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 un uintptr_t (o la representación de objeto de un objeto puntero) es específica de la implementación.

Pero incluso en sistemas donde C ++ std::less tiene que ser costoso, < no tiene que serlo. Por ejemplo, suponiendo un modelo de memoria "grande" donde un objeto cabe dentro de un segmento, < solo 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 valor seg , nunca se normaliza. 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 valor máximo (sin signo) size_t puede representar, SIZE_MAX . Por ejemplo, incluso en sistemas modelo de memoria plana, GNU C limita el tamaño máximo del objeto a PTRDIFF_MAX para que 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++ para recorrer 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 < q funcionarí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 en modo real x86 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 far frente a near , permitiendo a los programadores elegir cuándo pueden salirse con solo almacenar / pasar 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ña (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 segmento 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. Podría configurar segmentos parcialmente superpuestos en modo protegido, y las partes del selector de segmento de las direcciones ni siquiera se ordenarían 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 puede 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 segmentos fs o gs ), y solo se usa la parte de "desplazamiento" de 32 bits o 64 bits como un puntero)

Puede agregar manualmente código para varias plataformas específicas, por ejemplo, asumir de forma predeterminada plano, o #ifdef algo para detectar el modo real x86 y dividir uintptr_t en mitades de 16 bits para seg -= off>>4; off &= 0xf; seg -= off>>4; off &= 0xf; luego combine esas partes nuevamente en un número de 32 bits.

No. Una vez traté de encontrar una forma de evitar esto, pero no pude encontrar nada.

Su mejor uintptr_t es probablemente lanzar a uintptr_t y esperar que el compilador haga lo correcto, como terminé haciendo:

void *memmove(void *dest, const void *src, size_t len) { const unsigned char *s = (const unsigned char *)src; unsigned char *d = (unsigned char *)dest; /* The most portable this is ever going to get * without incurring an O(n) memory penalty */ if((uintptr_t)dest < (uintptr_t)(void *)src) { ...