VFP自身精度好像能做到0xFFFFFFFFFFFFF0，再大就有误差。

*n = 0xFFFFFFFFFFFFFFFF
*n = 18446744073709551615
*n = 0xFFFFFFFFFFFFF0
n = 72057594037927920
? n/1024^0, FormatBytes(n/1024^0)
? n/1024^1, FormatBytes(n/1024^1)
? n/1024^2, FormatBytes(n/1024^2)
? n/1024^3, FormatBytes(n/1024^3)
? n/1024^4, FormatBytes(n/1024^4)
? n/1024^5, FormatBytes(n/1024^5)
? n/1024^6, FormatBytes(n/1024^6)

FUNCTION FormatBytes(nValue)
    IF nValue < 1
        RETURN ""
    ENDIF 
    LOCAL i, aUnits[1]
    ALINES(aUnits, "Byte,KB,MB,GB,TB,PB,EB,ZB,YB", ",")
    i = INT(LOG(nValue) / LOG(1024))
    RETURN TRANSFORM(ROUND(nValue/(1024^i),2)) + " " + aUnits(i+1)
ENDFUNC

我这正常

不需要处理64位数，我问老师了，告诉我声明成两个32位就行，见 StrFormatByteSize64 函数声明，变成4个形参

[此贴子已经被作者于2023-4-20 18:49编辑过]

n = 0xFFFFFFFFFFFFFF（72057594037927935） 这是56位， VFP存储也只能做到0xFFFFFFFFFFFFF0（72057594037927920），处理64位还是不完美。

将一个LONGLONG声明为二个LONG（LONG, LONG），参数入栈顺序符合要求，理论上是可以，但不严谨（严格说算是BUG）。这样调用函数，明显就是调用者不支持LONGLONG，有可能存在异常风险。

少两个F这到没注意，复制错了地方吧，这么长一串实在难以分辨啊
倒也无所谓，这函数主要用途不外乎就是描述硬盘或者文件的大小，目前科技水平也就TB级，这函数能勉强满足EB级已经足够了。从TB到PB再到EB，差着1024*1024=2^20次方，就算摩尔定律还有效，每18个月翻一番也够用近四十年了，vfp活不了那么久，更何况硅基芯片的2nm已是极限，也不知道咱们这辈子能不能用上碳基芯片，哈哈哈哈哈哈

我先唯一担心的是低字节的LONG会怎么被解释，vfp没法声明成 ULONG
? FormatBytes(0x80000000) 能返回 2GB，那么低字节就没受符号位影响，高字节溢出就不关心了，咱没那么大的海量存储器

当然VFP调用FormatBytes根本用不到64位，如果只是针对文件或字符串或内存，顶多也是32位，过GB级点点。
所以VFP调用64位函数是否真的有必要，只能说VFP调用64位函数来处理FormatBytes只是个例，并不能说VFP都能这样去调用64位函数而没问题。

就是因为现在TB级的硬盘已经稀松平常，32位不够用才会调这个带64的api

ULONG只是符号位问题，LONGLONG符号位在63位，如果LONGLONG用（LONG，LONG）组合，符号位在高LONG的31位，所以低LONG是没有“符号”问题。
只要传入的数据符合大小端模式和编译器对参数入栈的顺序，（LONG，LONG）是紧接着一起的，这就相当于传入LONGLONG了。这种LONGLONG改用（LONG，LONG）的组合，理论上应该是说得过去。
但不支持64位的应用这样调用64函数，如果64函数内部涉及到高LONG时，因不支持64位的应用有可能提供不了精确的高LONG数据，就会出现意想不到的结果。

如果64位函数参数是LONGLONG数据的地址，VFP就好办，凡是地址就当是字符串。