小编prz*_*moc的帖子

在x86/amd64中,世界sizeof(long long)是8.

让我引用Zack Weinberg发来的具有洞察力的8年历史的邮件:

Scott Robert Ladd写道:

在64位AMD64架构上,GCC定义long long为64位,与a相同long.

鉴于某些64位指令(乘法)产生128位结果,看起来是不是逻辑上long long被定义为128位？

不,有两个原因:

1. long long大多数LP64模型操作系统的ABI中都写入了64位'的选择; 我们不能单方面改变它.

2. 这实际上是正确的选择,因为它消除了使long"不是最宽的基本积分类型" 的像差.野外有很多很多代码写成这样的假设 sizeof(long) >= sizeof(size_t)- 这至少可能被ABI所破坏,其中long long比long长.

   (在C99的开发过程中,这是一个极具争议的话题.从外部的角度来看,最好的是' long long'由于微软的压力而被标准化,因为微软不能出于某种原因实施LP64模型.其他人都讨厌使' long'不一定是最宽的基本积分类型的想法.)

目前最好的做法似乎是提供"扩展整体类型" __int128.这没有' long long' 的问题,因为它不是基本的整数类型(特别是它不能用于 size_t).

ZW

long long是最宽的基本积分型.在我所知道的任何非死亡架构/ ABI上它都是64位长.这允许使用简单的跨平台(好吧,至少对于许多32/64位架构)typedef:

typedef char               s8;
typedef unsigned char      u8;
typedef short              s16;
typedef unsigned short     u16;
typedef int                s32;
typedef …

关于IndexedDB,unlimitedStorage权限和访问从background/options脚本在内容脚本中创建的数据库的一些问题:

1. "unlimitedStorage"权限是否涵盖在background.js中创建的数据库？(在文档中不清楚)
2. "unlimitedStorage"权限是否涵盖在匹配域上的content.js中创建的数据库？
3. 在匹配域上的content.js中创建的数据库是无方案的吗？(即在http://和https://上运行的内容脚本会访问同一个数据库吗？)
4. 是否可以从其他扩展程序的内容脚本访问在匹配域的内容脚本中创建的数据库,并且它是否能在扩展删除后继续使
5. 从background/options.js访问给定域的数据库的方法是什么？(假设没有可用于发送消息的内容脚本)

我希望1-4的答案是积极的,但是从开发人员那里得到明确的答案会很好.