Bom... ainda bem que dizes isso porque as actuais arquitecturas RISC têm dado provas de valor... ah claro, para não mudar tudo e haver compatibilidade para trás mantem-se o x86 que dá chatices, é em geral mais lenta, pior... mas tem compatibilidade para trás! De tal forma que os ex-sortudos mac boys tiveram a sorte (ou azar) de andar de cavalo para burro (***** para intel). Por isso: pelo tempo passar não quer dizer que as coisas melhorem necessáriamente. Agora claro que não será igual, mas o problema de base mantem-se! Só lá vai com força bruta. A evolução diz que a força bruta de antigamente é uma formiga actual.... mas só lá vai com mais bits! Period.
É complicado mas a segunda solução que apresentaste é a mais parecida com "bons" costumes.
OK, vamos lá tentar explicar as coisas... o C não explicita quanta memória ocupa um inteiro, por exemplo:
sizeof(int) = 32 (x86); sizeof(int)=64 (amd64);
Não sei se sabes mas para todos os efeitos, um ponteiro é um valor inteiro positivo. acontece que com um bus de 32bit consegues endereçar 32bit de memória; com 64... 64. Há quem por facilitismo, faça a atribuição de um ponteiro a variáveis que foram declaradas como inteiros. E é garantido que em x86 funciona. Mas não noutras arquitecturas. Há variáveis para todos os gostos (que são typedefs, macros, etc para tipos básicos) e se uma função retorna um tipo (exemplo size_t) utiliza esse tipo de variável porque apesar de ser igual na arquitectura ABC a um tipo básico, na XYZ pode já ser diferente.
Aquilo que
aqui está dito para o kernel é (em parte) aplicável em terras do utilizador (
userland); Agora não uses as "internal data types",sff (a não ser que estejas a meter as mãos na massa). Usa sempre o
man para saberes com que tipo de váriável é que estás a lidar, por chato que seja.
