这篇文章 表示：
-ansi：告诉编译器实现 ANSI 语言选项，关闭某些 GCC 不符合 ANSI 标准的“特性”。
-pedantic：与-ansi同时使用，严格遵守 ANSI 标准，拒绝任何不符合标准的代码。
首先明确：
-pedantic 和 -ansi 选项是GCC/G++编译器的作用？（我没看懂上述描述）-pedantic 和 -ansi 是GCC/G++编译器的选项，用来控制是否严格遵守C/C++语言的标准规范。
- 在编写跨平台代码时，为了避免不同编译器实现的差异，可以考虑使用这两个选项。
- 在需要最大程度地控制代码规范、确保代码可移植性的情况下，应该使用这两个选项。
- 它们非常重要，能够帮助开发者在编写代码时尽可能地符合C/C++标准，从而提高代码质量和可维护性。我在编码中经常使用它。
-ansi标志等同于-std=c89。如前所述，它关闭了GCC的一些扩展功能。添加-pedantic会关闭更多的扩展功能并生成更多警告。
-pedantic会发出警告，因为它超过了C89标准所要求的最小限制。也就是说，每个C89编译器必须接受长度为509的字符串；它们可以接受更长的字符串，但如果你要严格遵守规范，使用更长的字符串是不可移植的，即使编译器允许接受更长的字符串，而且没有启用严格警告，GCC也会接受它们。GCC编译器总是尝试编译您的程序，如果可能的话。然而，在某些情况下，C和C ++标准规定某些扩展是被禁止的。像GCC或g ++这样符合标准的编译器在遇到这些扩展时必须发出诊断。
例如，GCC编译器的-pedantic选项会导致GCC在这种情况下发出警告。使用更严格的-pedantic-errors选项将这样的诊断警告转换为错误，这将导致编译在这些点上失败。只有那些需要由符合标准的编译器标记的非ISO构造才会生成警告或错误。
-pedantic-errors 不等同于 -Werror=pedantic，它们执行不同的检查。 - Warp-ansi 是一个过时的开关，请求编译器按照30年前的过时的C标准修订版 ISO/IEC 9899:1990 进行编译，这本质上是ANSI标准 X3.159-1989 "Programming Language C" 的重新命名。为什么过时？因为在ISO发布了C90之后，ISO一直负责C标准化，并且对C90的任何技术勘误都已经被ISO标准化。因此，更适合使用-std=c90。
没有这个开关，最近的GCC C编译器将符合ISO/IEC 9899:2011或最新的2018修订版中规定的C语言标准。
不幸的是，有些懒惰的编译器供应商认为坚持使用旧的过时标准修订版是可以接受的，而这些标准化文档甚至无法从标准机构获取。
使用该开关有助于确保代码可以在这些过时的编译器中进行编译。
-pedantic 是一个有趣的选项。如果没有 -pedantic，即使请求了特定的标准，GCC 仍将允许一些不符合 C 标准的扩展。例如考虑下面的程序：
struct test {
int zero_size_array[0];
};
除了可选的类型限定符和关键字static之外，[和]可以用来界定一个表达式或*。如果它们界定了一个表达式（指定数组的大小），那么该表达式必须具有整数类型。如果该表达式是一个常量表达式，它的值必须大于零。[...]
C标准要求数组的长度必须大于零；而这段话属于约束条件；标准在5.1.1.3p1节中如下所述：
即使行为也明确规定为未定义或实现定义，符合规范的实现应当以一种实现定义的方式产生至少一条诊断消息，如果预处理翻译单元或翻译单元包含任何语法规则或约束条件的违反。在其他情况下，不需要产生诊断消息。9）
然而，如果您使用gcc -c -std=c90 pedantic_test.c编译程序，则不会产生警告。
-pedantic使编译器实际上遵守C标准；因此现在它将生成诊断消息，正如标准所要求的那样：
gcc -c -pedantic -std=c90 pedantic_test.c
pedantic_test.c:2:9: warning: ISO C forbids zero-size array ‘zero_size_array’ [-Wpedantic]
int zero_size_array[0];
^~~~~~~~~~~~~~~
因此，为了实现最大的可移植性，仅仅指定标准修订版是不够的，您还必须使用-pedantic（或-pedantic-errors）来确保GCC实际上符合标准的要求。
-ansi。 ANSI从未标准化C++语言 - 只是从ISO中采用了它，因此这就像说“由法国标准化的英语”一样没有意义。然而，GCC似乎仍然接受它来编译C++，尽管听起来很愚蠢。-std=c++20。 - user4945014如果你的代码需要可移植，那么你可以测试它是否编译时没有使用任何GCC扩展或其他非标准特性。如果你的代码能够通过-pedantic -ansi编译，那么理论上它应该可以在任何符合ANSI标准的编译器中编译通过。
-pedantic并不会关闭所有扩展，它会保留一些双下划线的东西。因此更准确的说法可能是，如果你的代码能够在使用-pedantic -ansi编译通过，并且看起来可能也可以在其他实现中编译通过，那么它就可以编译通过。 - Steve Jessop如果你正在编写代码，并希望它能够在各种平台上编译，使用多个不同的编译器，则自己使用这些标志将有助于确保你不会生成仅在GCC下编译的代码。
其他人已经回答得足够详细了。我只想添加一些常见扩展的示例：
main函数返回void。这不是标准定义的，这意味着它只能在一些编译器上工作（包括GCC），但在其他编译器上不能工作。顺便说一下，int main()和int main(int, char**)是标准定义的两个签名。
另一个流行的扩展是能够在其他函数内部声明和定义函数：
void f()
{
void g()
{
// ...
}
// ...
g();
// ...
}
int main(void)？但是 int main() 似乎总是被接受，即使使用 -pedantic。请参见 https://dev59.com/Ml4b5IYBdhLWcg3waA1P - qwrPedantic 让 GCC 编译器拒绝所有 GNU C 扩展，而不仅仅是使其符合 ANSI 标准的扩展。