Rust开发团队解决了长期以来与C语言在x86-32和x86-64架构上，处理128位元整数对齐（Alignment）上的不一致。采用LLVM 18的Rust现在处理i128、u128资料型别，会与所有版本的GCC，以及Clang 18以上版本相容。

Rust开发团队解决了u128、i128资料类型，在记忆体中的布局问题，这个问题涉及资料型别在记忆体中的对齐方式。所谓的记忆体对齐，是指资料型别被允许放置的记忆体地址规范，对齐方式可以依据需求变化，像是一个8位元组大小的整数，可以储存在任意记忆体地址，而64位元电脑系统可能会选择采用8位元组的对齐方式。

在Rust与C语言中，针对u128、i128资料型别在x86-32和x86-64架构上的对齐方式，长期以来存在不一致。这种不一致来自于两个实作的对齐要求不同，在C语言中，__int128（相当于Rust的u128、i128）的对齐要求遵循该平台应用程式二进位介面（ABI）的规范，代表著在x86-64系统上，__int128的对齐可能被要求为16位元组，目的是最大程度提高存取这些资料型别的效率。

Rust在早期版本中，对于u128、i128的对齐不完全遵循C的ABI规范，导致在部分情况下，这些资料型别的对齐方式与C不一样，使得外部函式介面（FFI）呼叫时可能出现难以预料的行为或是效能问题。

为了解决与C语言在处理u128、i128资料型别对齐不一致的问题，Rust进行了调整，现在使资料型别对齐方式与C保持一致，而由于资料类型在记忆体中的布局更加可预测，减少了潜在转换或是对齐物的问题，因此直接提高了外部函式介面的相容性和效能。不过，也因为这些类型现在需要更大的对齐空间，可能导致程式码的记忆体占用增加。

对大多数Rust开发者来说，这次更改并不会有太大的影响，但是如果开发者在程式码中直接假设这些类型的对齐而没有使用align_of，或是在外部函式介面中使用这些资料型别，却忽略improper_ctypes*的Lint，则开发者可能会需要更新程式码，避免发生潜在的问题。

从Rust 1.77开始，开发者在外部函式介面中使用128位元整数时会相对安全，而随著1.78版本更新LLVM，开发者就能获得更多操作确定性。