这种宏真的不会出问题？

这个库叫PARI，不得不说它在数论这方面的计算功能是非常丰富和强大的，但就是这个#define long long long给我整不会了

它后面应该有个undefine，不然是有点逆天的
原代码肯定是在unix上写的，为了不用改代码就在Windows上用，就搞了个这

写了点代码来验证这玩意儿是不是真的会出问题：

size_of.c是没有被污染过的，所以它导出的三个函数肯定会返回原本应有的结果。
ftell是一个比较常用的函数，而wcstol比较冷门，这样有助于发现一些问题，这两个函数的返回类型都是long。

这个输出说明pari.h对前面的long没有影响，对后面的有，这很合理；
把包含pari.h的位置移到前面，再把wchar.h相关的东西注释掉：


神奇的是没有报错，而且ftell居然没受到影响。
启用wchar.h相关的东西试试（选择wchar.h是因为它比较冷门，几乎不可能被其他C标准头包含）


GCC终于绷不住了，报了一堆的错；
最后发现秘密其实就藏在这个pari.h里面：

pari.h事先包含了一些C标准头，然后才包含了parigen.h（没错，那个#define long long long就是这个parigen.h的杰作），所以stdio.h无论放在哪里都不会受到影响，但是wchar.h没有出现在这里，就不行了，必须放在pari.h的前面，否则就炸了。

后面居然没有undef掉吗？

做成链接库应该就行了

觉得这个搞法不太负责，我看其他很多库，他如果对精度有要求的话，无论什么平台都应该int8_t，int16_t，int32_t之类的，且应该每个平台都有一个库来确保这些数据类型的比特数是正确的。
有一些库像plibsys，他自己也会提供类似上面的数据类型定义，就叫pint8，puint8之类的。

前排