即使是 GNU 系統也會因為 CPU 類型的差異而有所不同——例如，位元組順序和對齊要求的差異。處理這些差異絕對是必要的。然而，不要為了 int 可能小於 32 位元的情況而費心。GNU 不支援 16 位元機器。
您無需為了 long 可能小於指標和 size_t 的情況而費心。我們知道有這樣一個平台：Microsoft Windows 上的 64 位元程式。如果您關心讓您的套件在使用 Mingw64 的 Windows 上運行，您將需要處理 8 位元組的指標和 4 位元組的 long，這會破壞此程式碼。
printf ("size = %lu\n", (unsigned long) sizeof array);
printf ("diff = %ld\n", (long) (pointer2 - pointer1));
是否在您的套件中支援 Mingw64 以及一般的 Windows，是您自己的選擇。GNU 專案並未表示您有任何責任這樣做。我們的目標是取代專有系統，包括 Windows，而不是增強它們。如果有人向您施壓，要求您的程式在 Windows 上運行，而您不感興趣，您可以回應說：「切換到 GNU/Linux——您的自由取決於它。」
預定義的檔案大小類型（如 off_t）是一個例外：它們在許多平台上比 long 更長，因此像上面的程式碼無法與它們一起使用。可移植地列印 off_t 值的一種方法是自己逐個列印其數字。
不要假設 int 物件的地址也是其最低有效位元組的地址。這在 big-endian（大端序）機器上是錯誤的。因此，不要犯以下錯誤
int c; … while ((c = getchar ()) != EOF) write (file_descriptor, &c, 1);
相反地，請如下使用 unsigned char。（unsigned 是為了可移植到不常見的系統，在這些系統中 char 是有符號的，並且存在整數溢位檢查。）
int c;
while ((c = getchar ()) != EOF)
{
unsigned char u = c;
write (file_descriptor, &u, 1);
}
如果可以，請避免將指標轉換為整數。這種轉換會大大降低可移植性，並且在大多數程式中，它們很容易避免。在必須將指標轉換為整數的情況下——例如，Lisp 直譯器將型別資訊以及地址儲存在一個字組中——您必須做出明確的規定來處理不同的字組大小。您還需要為某些系統做出規定，在這些系統中，您可以從 malloc 獲得的正常地址範圍從遠離零的位置開始。