习惯于GCC和Clang的人被宠坏了。外面不是很好。

这些年来，我被要求使用的过时的编译器吓坏了。公司和管理者通常采用极端保守的方法来更改编译器，甚至不会测试新的编译器（具有更好的标准遵从性和代码优化）是否能在他们的系统中工作。对于正在工作的开发人员来说，实际情况是，当你在编写代码时，你需要覆盖你的基础，不幸的是，如果你不能控制什么编译器可以应用于你的代码，那么使用mallocs是一个好习惯。

我还建议许多组织应用自己的编码标准，如果定义了编码标准，那么这应该是人们遵循的方法。在缺乏明确指导的情况下，我倾向于选择最有可能在任何地方编译，而不是盲目地遵守某个标准。

根据现行标准，这是不必要的，这一论点是非常有效的。但这一论点忽略了现实世界的现实性。在一个完全由当今标准统治的世界里，我们并没有编码，而是由我喜欢称之为“地方管理的现实领域”的实用性来控制。这比太空时代更加弯曲和扭曲

YMMV。

我倾向于将使用malloc作为防御操作。不漂亮，不完美，但总体安全。（老实说，如果你没有包含stdlib.h，那么你会遇到比强制执行malloc更多的问题！）。

您不需要强制转换malloc的结果，因为这样做会给代码增加无意义的混乱。

人们之所以选择malloc的结果，最常见的原因是他们不确定C语言是如何工作的。这是一个警告信号：如果你不知道特定的语言机制是如何工作的，那么就不要猜测。查找或询问堆栈溢出。

一些意见：

空指针可以转换为任何其他指针类型，而无需显式转换（C11 6.3.2.3和6.5.16.1）。但是，C++不允许在void*和另一个指针类型之间进行隐式转换。因此，在C++中，演员阵容是正确的。但是如果你用C++编程，你应该使用new而不是malloc（）。而且您永远不应该使用C++编译器编译C代码。如果需要使用相同的源代码同时支持C和C++，请使用编译器开关来标记差异。不要试图用相同的代码来满足两种语言标准，因为它们不兼容。如果C编译器因为忘记包含标头而找不到函数，则会出现编译器/链接器错误。因此，如果您忘记包含<stdlib.h>，这没什么大不了的，您将无法构建您的程序。在遵循超过25年的标准版本的古代编译器上，忘记包含＜stdlib.h＞将导致危险行为。因为在那个古老的标准中，没有可见原型的函数隐式地将返回类型转换为int。显式地从malloc转换结果将隐藏这个错误。但这真的不是问题。你不是在使用一台25年前的计算机，那么你为什么要使用一台有25年历史的编译器呢？

返回的类型为void*，可以将其转换为所需类型的数据指针，以便可以取消引用。

malloc的转换在C中是不必要的，但在C++中是必需的。

C中不需要铸造，因为：

在C的情况下，void*会自动安全地升级为任何其他指针类型。如果您忘记包含<stdlib.h>，它可能会隐藏错误。这可能会导致崩溃。如果指针和整数的大小不同，则通过强制转换隐藏警告，可能会丢失返回地址的位。如果指针的类型在声明时发生了更改，那么可能还需要更改调用和强制转换malloc的所有行。

另一方面，强制转换可能会增加程序的可移植性。即它允许C程序或函数编译为C++。

这就是GNU C库参考手册所说的：

您可以将malloc的结果存储到任何指针变量中强制转换，因为ISO C会自动将类型void*转换为另一个必要时的指针类型。但演员阵容在上下文中是必要的而不是赋值运算符，或者如果您可能希望代码运行在传统C。

事实上，ISO C11标准（第47页）是这么说的：

如果分配成功，则返回的指针将适当对齐它可以分配给指向任何类型对象的指针基本对齐要求，然后用于访问这样的对象或此类对象的数组（直到空间被显式释放）

对我来说，这里的结论是，在C语言中使用malloc是完全没有必要的，但是如果你使用了C语言，它不会影响malloc，因为malloc仍然会为你分配你请求的内存空间。另一个原因是人们进行选角的原因或原因之一，这是为了使他们能够用C或C++编译相同的程序。

可能还有其他原因，但几乎可以肯定的是，其他原因迟早会让你陷入严重的麻烦。