@FrankHB #31

“在任何符合 C/C++ 标准的语言实现中总是正确”，我已经加上了全称量词，那么我应该说“在任何……总是被支持”。显然可以造出一个只支持 int main(void) 和 int main(int, char **) 的实现，所以这是惟二“总是正确”（总是被支持）的写法。

我觉得你是知道我知道 C/C++ 对于 () 作为形参列表的不同的 - - 我没有指出 C/C++ 在这方面的区别，是因为我的写法在 C/C++ 中含义一样。（ C++ 仍然支持 (void) 表达 () 见于 n4659 11.3.5.4。）

关于签名，我并不知道文档中使用的定义，是否包含返回类型只是一个取决于使用目的的美学选择。不过感谢你指出标准里的定义是什么样的。

最后，我并不知道 C 支持（意思是“任何实现必须支持”而不是“允许这样的扩展”） int main()。

@FrankHB #29 OK，更准确的说法是“在任何符合 C/C++ 标准的语言实现中总是正确的 main 的签名只有 2 种”，例如见 n4659 6.6.1.2 和 n1256 5.1.2.2.1.1。

签名，如果不是一个 C/C++ 语言中的概念，就是日常理解的含义，是若干个类型的有序组（返回类型，第一个形参类型，第二个形参类型……）以及一个 bool （是否具有 ... 变长参数）。两个签名相同当且仅当这个 (有序组, bool) 的 pair 相等。

@mgrddsj #5 没必要加戏，Edge 的滚动效果任何 app 都可以通过官方文档记载的方式实现。

楼主问了好几个不同的问题。

就 C/C++ 标准来说，正确的 main 的签名只有以下 2 种

int main(void);
int main(int, char **);

注意，char *argv[] 和 char **argv 作为形参是完全一样的，以及使用 typedef 导致的等价定义也是允许的。就语言层面，没有什么讲究。

就 Java 来说，一维数组形参可以用 TypeName argName[] 或者 TypeName[] argName 声明，它们是等价的写法。阿里巴巴的规范是选择他们内部喜欢的写法，原因可以理解为把类型名挤在一起便于理解。

C# 中，一维数组的形参可以用 TypeName[] argName 声明，不能使用 TypeName argName[] 的原因是后者是 C# 中不存在的写法（不符合句法）。

保存在 OneDrive 上的文件可以自动保存。

@good1uck #5 只含一项的数组答案永远是 false，为什么 if 里面还要再判断？

简单的方法不需要这些字符串操作弄来弄去，计数+计算最大公因数就完了。

@lhx2008 #8 可以给用户存一个 version number，在用户变更安全信息或者撤销所有会话的时候增加之，只有 version number 足够高的签名才有效就行了。

@keepeye #9 赞同。

（如果引入 state 的话 JWT 就属于传统 session 的特例了）

JWT 是数字签名，所以只需要 public key 和受信任的时间即可验证有效性

@Hstar #56 您对“非对称加密”的理解完全错误

从美学上来说，现代研究者会将文法、正确性和安全性分开定义。当然，当人们说“加密”的时候，人们通常都想要表达的是“正确且安全的加密方案”。

Base64 符合加密方案的文法和正确性要求，但是不满足任何有价值的安全性定义。

简单问题复杂化的高手了 😨

以及我没有理解

if(group.length==1){
return group[0].split(',').join('').length>1?true:false
}

是在干什么，是 contrived 写法（故意展示需要测试 [10]）么？还是本来有别的含义？

最后，缺少任何一个测试数据都可以导致一个不正确的程序通过。

但是你仍然可以探究该软件作者是否有抄袭你的源代码，《计算机软件保护法》赋予用户很多权利。

这个 UI 太一般化了，算不上抄袭。

我假设你说的“不加注释”的意思是“不注释掉 consumer 拿锁的两行”。

成语：掩耳盗铃。

用 su/setuid 等用其他用户的身份启动进程。（寻找 ImpersonateUser、CreateProcessAsUser、CreateProcessWithLogon 的等价物）

@Buffer2Disk #6 你一开始并没有提到重新打开正常的概率很低。（你真的读了自己写了什么吗？！

你说重新设置环境变量就好了，那么你查看不能运行的时候 cmd 的环境变量了吗？用 set 命令可以查看。另外除了 PATH 会影响结果，PATHEXT 也有很大影响。

从目前的信息来看，没有理由怀疑是 Windows 的问题。

具体见 https://tools.ietf.org/html/rfc733


3. Receiver Fields

[...]

b. [sic] Bcc

This field contains the identity of additional recipients of the message. The contents of this field are not included in copies of the message sent to the primary and secondary recipients. Some systems may choose to include the text of the "Bcc" field only in the author(s)'s copy, while others may also include it in the text sent to all those indicated in the "Bcc" list.

Bcc 的标准只需要确保 To 和 Cc 的副本看不到 Bcc 的内容，并不是所有软件都会把 Bcc 的副本中的 Bcc 删除。

我觉得最佳发件软件应该把每个 Bcc 的 copy 的 Bcc line 删除到只剩下该 copy 的收件人自己，这样既有隐私也可以减少误判为垃圾邮件。

最安全的方法是用 Mail Merge 产生多封邮件。

@misaka19000 #1 微软真惨，什么锅都能被甩到自己头上

我来试试念力 debug 法：楼主说关掉 cmd 再打开就又正常了，一个简单的假设是有些程序修改了正在运行的 cmd 的（进程级别）环境变量，尤其是 PATH，例如可能会在 PATH 的开头追加一些目录（并且忘记判断是否 PATH 已经含有需要路径而无脑增加），但是环境变量的总长度有限制，所以随着修改的次数增加，go 所在的目录就被挤掉了。

要判断是否有此事发生，首先考虑是否在命令中有 .bat/.cmd ，这些最容易修改 cmd 的环境变量。找到目标后阅读代码寻找 set 命令。

另一种判断方法是写一个程序，它的作用是查看自己的环境变量并和一个磁盘上的存档对比，如果不同则发出提示，如果磁盘上没有则把自己的环境变量存到磁盘上。如果可以同时运行多个 cmd，那么这个程序应该根据自己父进程的 PID 决定哪一个存档应该被检查。

接着在所有的命令后都追加调用该程序，即可看出哪两个命令之间 cmd 的环境变量发生了变化，从而定位问题所在。