c - posix_spawn 的限制是 "right"吗？

Question

所以我看到头文件 spawn.h 大量使用了'restrict':

extern int posix_spawn (pid_t *__restrict __pid,
        const char *__restrict __path,
        const posix_spawn_file_actions_t *__restrict
        __file_actions,
        const posix_spawnattr_t *__restrict __attrp,
        char *const __argv[__restrict_arr],
        char *const __envp[__restrict_arr]);

• 有趣的是，posix_spawnp 没有。

但是我经常使用的 exec 系列调用的使用模式是:

const char* command = "whatever";
const char* args[] = {command, "--arg1", "--arg2"};

现在，exec 家族，/不/使用 restrict，所以我可以(忽略一些 const 转换)

execv(command, args);

但是我(技术上)不能因为限制而做以下事情:__path 和 __argv 都被标记为受限，因此不能指向同一个对象。

posix_spawn(nullptr, command, nullptr, nullptr, args, __environ);

这在我不知道的某个深层次上是否合理？ :-)
当然，它都包含在宏中，所以也许它从未启用过？

请注意，这个问题在很大程度上属于假设和语言律师领域。我还没有找到强制执行此限制的编译或 lint 选项，当然也不是来自 C++，带有 extern "C"，但同样我不想在未来走进一个。

Answer 1

是的，它对 posix_spawn 函数本身的编译器很有用。

它告诉编译器他可能对数组的假设。特别是它告诉第一个参数不能被字符数组别名:char* 和类似的可以别名所有其他指针类型。

这对您和任何其他人(谁会传递一个 char* 转换后的 pid_t* 作为路径？)可能是显而易见的，但对编译器而言却不是.

类似的论点适用于其他数组。如果它们的基类型只是一些 typedefed 整数类型，编译器可能会怀疑别名，而实际上永远不会有别名。

对于您展示的代码没有问题，因为 restrict 保护它指向的对象，而不是它所引用的其他对象。如果有人想要，他必须使用类似的东西

char *restrict const __argv[restrict],

但这里可能过于“限制性”了。