http://en.wikipedia.org/wiki/LLP64#64-bit_data_models
Many 64-bit compilers today use the LP64 model (including Solaris, AIX, HP-UX, Linux, Mac OS X, FreeBSD, and IBM z/OS native compilers). Microsoft's Visual C++ compiler uses the LLP64 model. The disadvantage of the LP64 model is that storing a long into an int may overflow. On the other hand, casting a pointer to a long will work. In the LLP model, the reverse is true. These are not problems which affect fully standard-compliant code, but code is often written with implicit assumptions about the widths of integer types.
(i) A "long szélesebb az int-nél" egy 100%-ban természetes és magától adódó ötlet. (ii) A C89 (SUSv1 / UNIX 95, SUSv2 / UNIX 98) alapú platformokon a legszélesebb hordozható egész típus a long, így egyáltalán nem elrugaszkodott ötlet arra számítani, hogy beleférjen a pointer. A SUS szabvány(ok) által leírt négy modellból (amelyből a platformnak legalább egyet kell támogatnia) három garantálja, hogy a long-ba belefér a pointer.
Egyszóval az LP64 egy természetes továbbgondolása a típusoknak.
Az LLP64 a Windows-ra írt források minőségéről tanúskodik. A Microsoft kompatibilitási okokból (*) arra figyelt, hogy a long beleférjen az int-be. Ki a retek kódol ilyet? Ráadásul C89-alapokon megírt program Windows-on fordítva nem fog hozzáférni 64 bites egész típushoz, hiába tudja a platform / compiler (az off_t ebben a megközelítésben lényegtelen); valamint a pointer-to-long konverzió (ami nem garantált ugyan, de azért értelmes elvárás) pofára fog esni.
(*) Itt forráskód-szintű kompatibilitásról van szó:
Another alternative is the LLP64 model, which maintains compatibility with 32-bit code by leaving both int and long as 32-bit.
Nem azon aggódtak, hogy a létező ILP32 binárisok ne futottak volna el, hanem hogy AMD64-es windows-on (LP64-en) újrafordítva fejreálltak volna.
Szerk: azt természetesen nem vitatom, hogy a Microsoft részéről talán ez volt az egyetlen kereskedelmileg járható út.