Si la representación de un long int y un int es la misma en una plataforma, ¿son estrictamente iguales? ¿Los tipos se comportan de forma diferente en la plataforma de acuerdo con el estándar C?
P.ej. esto siempre funciona:
int int_var; long long_var; void long_bar(long *l); void int_bar(int *i); void foo() { long_bar(&int_var); /* Always OK? */ int_bar(&long_var); }Supongo que la misma pregunta se aplica a short e int, si resultan ser la misma representación.
La pregunta surgió al discutir cómo definir un typedef int32_t para un compilador C89 incrustado sin stdint.h, es decir, como int o long y si importaría.
Los tipos long e int tienen diferentes rangos. El rango del tipo long es más alto que el rango del tipo int . Entonces, en una expresión binaria donde se usa un objeto de tipo long y un objeto de tipo int , el último siempre se convierte al tipo long .
Compare los siguientes fragmentos de código.
int x = 0; unsigned int y = 0; el tipo de la expresión x + y es unsigned int .
long x = 0; unsigned int y = 0; el tipo de la expresión x + y no tiene unsigned long (debido a las conversiones aritméticas habituales) siempre que sizeof( int ) sea igual a sizeof( long) .
Esto es muy importante en C++ que en C, donde se permite la sobrecarga de funciones.
En C, debe tener esto en cuenta, por ejemplo, cuando utiliza funciones de E/S como, por ejemplo, printf para especificar un especificador de conversión correcto.
No son tipos compatibles, lo que puedes ver con un ejemplo sencillo:
int* iptr; long* lptr = iptr; // compiler error herePor lo tanto, importa principalmente cuando se trata de punteros a estos tipos. Del mismo modo, existe la "regla de alias estricta" que hace que este código tenga un comportamiento indefinido:
int i; long* lptr = (long*)&i; *lptr = ...; // undefined behavior Otro tema sutil es la promoción implícita. En caso de que tenga some_int + some_long , el tipo resultante de esa expresión es long . O en caso de que alguno de los parámetros no esté firmado, unsigned long . Esto se debe a la promoción de enteros a través de las conversiones aritméticas habituales , consulte Reglas de promoción de tipos implícitos . No debería importar la mayor parte del tiempo, pero un código como este fallará: _Generic(some_int + some_long, int: stuff() ) ya que no hay una cláusula long en la expresión.
Generalmente, al asignar valores entre tipos, no debería haber ningún problema. En el caso de uint32_t , no importa a qué tipo corresponda, porque de todos modos debería tratar uint32_t como un tipo separado. Elegiría long por compatibilidad con microcontroladores pequeños, donde typedef unsigned int uint32_t; romperá. (Y obviamente, typedef signed long int32_t; para el equivalente firmado).
Incluso en plataformas en las que long e int tienen la misma representación, el estándar permitiría a los compiladores ignorar deliberadamente la posibilidad de que el acto de almacenar un valor en long* pueda afectar el valor de int* o viceversa. Dado algo como:
#include <stdint.h> void store_to_int32(void *p, int index) { ((int32_t*)p)[index] = 2; } int array1[10]; int test1(int index) { array1[0] = 1; store_to_int32(array1, index); return array1[0]; } long array2[10]; long test2(int index) { array2[0] = 1; store_to_int32(array2, index); return array2[0]; } La versión ARM de 32 bits de gcc tratará int32_t como sinónimo de long e ignorará la posibilidad de que pasar la dirección de a array1 a store_to_int32 podría causar que se escriba el primer elemento de esa matriz, y la versión de 32 bits de clang tratará int32_t como sinónimo de int e ignore la posibilidad de que al pasar la dirección de array2 a store_to_int32 se escriba el primer elemento de ese array.
Sin duda, nada en el Estándar prohibiría a los compiladores comportarse de esa manera, pero creo que el hecho de que el Estándar no prohíba tal ceguera se deriva del principio "cuanto más tonto sea algo, menos necesidad debería haber de prohibirlo".