在这个问题上，有人在评论中建议我不要使用malloc的结果。即，我应该这样做：
int *sieve = malloc(sizeof(*sieve) * length);
而不是：
int *sieve = (int *) malloc(sizeof(*sieve) * length);
为什么会这样？
在C语言中，不需要强制转换malloc的返回值。malloc返回的指向void的指针会自动转换为正确的类型。但是，如果您想用C++编译器编译代码，则需要强制转换。社区中的首选替代方案是使用以下方法：
int *sieve = malloc(sizeof *sieve * length);
另外，如果你改变了筛子的类型，你就不用担心改变表达式的右边。
正如人们所指出的那样，铸件是不好的。尤其是指针强制转换。
TL；博士
int *sieve = (int *) malloc(sizeof(int) * length);
有两个问题。类型转换，并且您使用类型而不是变量作为sizeof的参数。相反，请这样做：
int *sieve = malloc(sizeof *sieve * length);
长版本
不您不必计算结果，因为：
这是不必要的，因为在这种情况下，void*会自动安全地升级为任何其他指针类型。它给代码增加了混乱，强制转换不太容易阅读（特别是如果指针类型很长）。这会让你重复自己，这通常是不好的。如果您忘记包含＜stdlib.h＞，它可能会隐藏错误。这可能会导致崩溃（或者更糟糕的是，直到稍后在代码的某个完全不同的部分发生崩溃）。考虑如果指针和整数的大小不同会发生什么；然后你通过投射来隐藏警告，可能会丢失返回地址的一部分。注意：从C99开始，隐式函数从C中消失，这一点不再相关，因为没有自动假设未声明的函数返回int。
作为澄清，请注意我说的是“你不需要投”，而不是“你不必投”。在我看来，这是一个失败的演员阵容，即使你做得对。这样做根本没有好处，但有一系列潜在的风险，包括演员阵容表明你不知道这些风险。
另外，正如评论家指出的，上面提到的是直接C，而不是C++。我非常坚信C和C++是独立的语言。
此外，代码不必要地重复类型信息（int），这可能会导致错误。最好取消引用用于存储返回值的指针，将两者“锁定”在一起：
int *sieve = malloc(length * sizeof *sieve);
这还将长度移到前面以增加可见性，并删除sizeof的多余括号；只有当参数是类型名时，才需要它们。许多人似乎不知道（或忽略）这一点，这使得他们的代码更加冗长。记住：sizeof不是函数！：）
虽然在一些罕见的情况下，将长度移到前面可能会增加可见性，但也应注意，在一般情况下，最好将表达式写成：
int *sieve = malloc(sizeof *sieve * length);
在这种情况下，由于首先保持sizeof，确保乘法至少使用size_t数学运算完成。
比较：malloc（sizeof*sive*length*width）与malloc，当width和length的类型小于size_t时，第二个可能会溢出长度*宽度。
正如其他人所说的，它不是C所必需的，而是C++所必需的。如果您认为要使用C++编译器编译C代码，无论出于何种原因，都可以使用宏，例如：
#ifdef __cplusplus
# define MALLOC(type) ((type *)malloc(sizeof(type)))
# define CALLOC(count, type) ((type *)calloc(count, sizeof(type)))
#else
# define MALLOC(type) (malloc(sizeof(type)))
# define CALLOC(count, type) (calloc(count, sizeof(type)))
#endif
# define FREE(pointer) free(pointer)
这样，您仍然可以以非常紧凑的方式编写它：
int *sieve = MALLOC(int); // allocate single int => compare to stack int sieve = ???;
int *sieve_arr = CALLOC(4, int); // allocate 4 times size of int => compare to stack (int sieve_arr[4] = {0, 0, 0, 0};
// do something with the ptr or the value
FREE(sieve);
FREE(sieve_arr);
它将为C和C++编译。
你会选演员，因为：
它使您的代码在C和C++之间更具可移植性，正如SO的经验所示，许多程序员声称，当他们真正用C++（或C加本地编译器扩展）编写时，他们是在用C编写。如果不这样做，可能会隐藏一个错误：请注意所有的so示例，它们混淆了何时写入类型*和类型**。它会让你注意不到你没有#包含一个合适的头文件，这一想法让你错过了树的森林。这与说“不要担心你没能让编译器抱怨没有看到原型的事实——讨厌的stdlib.h才是真正需要记住的重要东西！”它强制进行额外的认知交叉检查。它将（所谓的）所需类型放在您对该变量的原始大小所做的算术旁边。我敢打赌，你可以做一个SO研究，表明malloc（）错误在有演员时被捕获的速度要快得多。与断言一样，揭示意图的注释可以减少错误。以机器可以检查的方式重复自己的行为通常是一个好主意。事实上，这就是断言，使用强制转换就是断言。断言仍然是我们获得正确代码的最通用技术，因为图灵多年前就提出了这个想法。
现在不需要强制转换malloc（）返回的值，但我想补充一点，似乎没有人指出：
在古代，也就是说，在ANSI C提供void*作为指针的通用类型之前，char*是这种用法的类型。在这种情况下，强制转换可以关闭编译器警告。
参考：C常见问题解答
这取决于编程语言和编译器。如果在C中使用malloc，则无需键入cast，因为它会自动键入cast。然而，如果您使用的是C++，那么应该键入cast，因为malloc将返回void*类型。
您不需要强制转换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年历史的编译器呢？
加上我学习计算机工程的经验，我发现我见过的两三位教授总是用C语言写作，但我问的那位教授（有着丰富的简历和对C语言的理解）告诉我，这是绝对没有必要的，但只用于绝对具体，并让学生们养成绝对具体的心态。从本质上讲，强制转换不会改变它的工作方式，它完全按照它所说的做，分配内存，强制转换不影响它，你会得到相同的内存，即使你错误地将它强制转换为其他东西（并以某种方式规避编译器错误），C也会以同样的方式访问它。
编辑：铸造有一定的意义。当您使用数组表示法时，生成的代码必须知道要到达下一个元素的开头，需要前进多少个内存位置，这是通过强制转换实现的。通过这种方式，您可以知道，对于double，您可以提前8个字节，而对于int，则可以提前4个字节，依此类推。因此，如果您使用指针表示法，则不会产生任何影响，在数组表示法中，这是必要的。
void指针是一个通用对象指针，C支持从void指针类型到其他类型的隐式转换，因此不需要显式类型转换。
然而，如果您希望相同的代码在不支持隐式转换的C++平台上完美兼容，则需要进行类型转换，因此这一切都取决于可用性。
尽可能在C语言中编程时最好做的事情是：
通过C编译器编译程序，并打开所有警告-Wall并修复所有错误和警告确保没有声明为auto的变量然后使用带有-Wall和-std=C++11的C++编译器对其进行编译。修复所有错误和警告。现在再次使用C编译器进行编译。您的程序现在应该在没有任何警告的情况下编译，并且包含更少的错误。
这个过程使您可以利用C++严格的类型检查，从而减少错误的数量。特别是，此过程强制您包含stdlib.否则您将得到
malloc未在此范围内声明
并且还强制你使用malloc的结果，否则你会得到
从void*到T的转换无效*
或者你的目标类型是什么。
用C而不是C++编写的唯一好处是
C具有明确规定的ABIC++可能会生成更多代码[异常、RTTI、模板、运行时多态性]
请注意，在理想情况下，当使用C所共有的子集和静态多态特性时，第二个缺点应该消失。
对于那些觉得C++严格规则不方便的人，我们可以使用带有推断类型的C++11特性
auto memblock=static_cast<T*>(malloc(n*sizeof(T))); //Mult may overflow...
void指针背后的概念是它可以被强制转换为任何数据类型，这就是malloc返回void的原因。此外，您必须了解自动打字。因此，虽然必须强制强制强制转换指针，但它有助于保持代码整洁，并有助于调试
在C语言中，可以将空指针分配给任何指针，这就是为什么不应该使用类型转换的原因。如果您想要“类型安全”分配，我可以推荐以下宏函数，这些函数我总是在C项目中使用：
#include <stdlib.h>
#define NEW_ARRAY(ptr, n) (ptr) = malloc((n) * sizeof *(ptr))
#define NEW(ptr) NEW_ARRAY((ptr), 1)
有了这些，你可以简单地说
NEW_ARRAY(sieve, length);
对于非动态数组，第三个必须的函数宏是
#define LEN(arr) (sizeof (arr) / sizeof (arr)[0])
这使得阵列环路更加安全和方便：
int i, a[100];
for (i = 0; i < LEN(a); i++) {
...
}
这就是GNU C库参考手册所说的：
您可以将malloc的结果存储到任何指针变量中强制转换，因为ISO C会自动将类型void*转换为另一个必要时的指针类型。但演员阵容在上下文中是必要的而不是赋值运算符，或者如果您可能希望代码运行在传统C。
事实上，ISO C11标准（第47页）是这么说的：
如果分配成功，则返回的指针将适当对齐它可以分配给指向任何类型对象的指针基本对齐要求，然后用于访问这样的对象或此类对象的数组（直到空间被显式释放）
来自维基百科：
铸造的优点包括强制转换可以允许C程序或函数编译为C++。强制转换允许最初返回char*的1989年以前版本的malloc。如果目标指针类型发生变化，强制转换可以帮助开发人员识别类型大小的不一致，特别是如果指针声明的位置远离malloc（）调用（尽管现代编译器和静态分析器可以在不需要强制转换的情况下警告此类行为）。铸造的缺点根据ANSI C标准，铸件是多余的。添加强制转换可能会掩盖将标头stdlib.h包含在找到了malloc的原型。如果没有malloc的原型，标准要求C编译器假设malloc返回一个int。如果没有强制转换，则警告为当该整数被分配给指针时发出；然而，随着演员，这个警告没有产生，隐藏了一个bug。在某些情况下体系结构和数据模型（例如64位系统上的LP64，其中long和指针为64位，int为32位），此错误可能实际上导致未定义的行为，正如隐式声明的malloc返回32位值，而实际定义的函数返回64位值。取决于调用约定和内存布局，这可能会导致堆栈损坏。这个问题不太可能在现代编译器中不被注意，因为它们统一地生成警告已使用未声明的函数，因此警告将仍然出现。例如，GCC的默认行为是显示警告：“内置的不兼容隐式声明函数”，而不管是否存在强制转换。如果指针的类型在其声明时发生了更改，则可以此外，需要更改调用和强制转换malloc的所有行。
尽管malloc不带强制转换是首选方法，大多数有经验的程序员都会选择它，但在意识到问题后，您应该使用任何您喜欢的方法。
即：如果您需要将C程序编译为C++（尽管它是一种单独的语言），则必须强制转换使用malloc的结果。
习惯于GCC和Clang的人被宠坏了。外面不是很好。
这些年来，我被要求使用的过时的编译器吓坏了。公司和管理者通常采用极端保守的方法来更改编译器，甚至不会测试新的编译器（具有更好的标准遵从性和代码优化）是否能在他们的系统中工作。对于正在工作的开发人员来说，实际情况是，当你在编写代码时，你需要覆盖你的基础，不幸的是，如果你不能控制什么编译器可以应用于你的代码，那么使用mallocs是一个好习惯。
我还建议许多组织应用自己的编码标准，如果定义了编码标准，那么这应该是人们遵循的方法。在缺乏明确指导的情况下，我倾向于选择最有可能在任何地方编译，而不是盲目地遵守某个标准。
根据现行标准，这是不必要的，这一论点是非常有效的。但这一论点忽略了现实世界的现实性。在一个完全由当今标准统治的世界里，我们并没有编码，而是由我喜欢称之为“地方管理的现实领域”的实用性来控制。这比太空时代更加弯曲和扭曲
YMMV。
我倾向于将使用malloc作为防御操作。不漂亮，不完美，但总体安全。（老实说，如果你没有包含stdlib.h，那么你会遇到比强制执行malloc更多的问题！）。
我加入强制转换只是为了表示对类型系统中的丑陋漏洞的不满，这种漏洞允许像以下代码片段这样的代码在没有诊断的情况下编译，即使没有强制转换来导致错误的转换：
double d;
void *p = &d;
int *q = p;
我希望这不存在（而且在C++中也不存在），所以我投了。它代表了我的品味和我的编程政治。我不仅投了一个指针，而且有效地投了一张选票，并淘汰了愚蠢的恶魔。如果我真的不能摆脱愚蠢，那么至少让我用一种抗议的姿态来表达这样做的愿望。
事实上，一个好的做法是用返回无符号char*的函数包装malloc（和朋友），并且基本上不要在代码中使用void*。如果需要指向任何对象的通用指针，请使用char*或无符号char*，并在两个方向上进行强制转换。也许，可以放松的一点是使用memset和memcpy等函数而不进行强制转换。
关于强制转换和C++兼容性的主题，如果您编写代码以使其同时编译为C和C++（在这种情况下，当将malloc的返回值分配给void*以外的其他对象时，您必须强制转换malloc），您可以为自己做一件非常有用的事情：当编译为C++时，可以使用宏强制转换为C++风格的强制转换，但当编译为C:
/* In a header somewhere */
#ifdef __cplusplus
#define strip_qual(TYPE, EXPR) (const_cast<TYPE>(EXPR))
#define convert(TYPE, EXPR) (static_cast<TYPE>(EXPR))
#define coerce(TYPE, EXPR) (reinterpret_cast<TYPE>(EXPR))
#else
#define strip_qual(TYPE, EXPR) ((TYPE) (EXPR))
#define convert(TYPE, EXPR) ((TYPE) (EXPR))
#define coerce(TYPE, EXPR) ((TYPE) (EXPR))
#endif
如果您遵循这些宏，那么对代码库进行简单的grep搜索以查找这些标识符将显示所有强制转换的位置，因此您可以检查其中是否有错误。
然后，如果您经常使用C++编译代码，那么它将强制使用适当的强制转换。例如，如果您使用strip_qual只是为了删除常量或volatile，但是程序的变化导致现在涉及到类型转换，那么您将得到一个诊断，并且您必须使用强制转换的组合来获得所需的转换。
为了帮助您遵守这些宏，GNUC++（而不是C！）编译器有一个漂亮的功能：一个可选的诊断程序，它针对所有C样式强制转换的出现而生成。
-Wold-style-cast (C++ and Objective-C++ only)
Warn if an old-style (C-style) cast to a non-void type is used
within a C++ program. The new-style casts (dynamic_cast,
static_cast, reinterpret_cast, and const_cast) are less vulnerable
to unintended effects and much easier to search for.
如果您的C代码编译为C++，则可以使用此-Wold样式的转换选项来查找可能在代码中出现的（类型）转换语法的所有情况，并通过使用上述宏中的适当选项（或组合，如果需要）来替换它来跟踪这些诊断。
这种转换处理是在“Clean C”中工作的唯一最大的独立技术理由：结合了C和C++方言，这反过来又在技术上证明了强制转换malloc的返回值是合理的。
我更喜欢演演员，但不是手动。我最喜欢使用glib中的g_new和g_new0宏。如果不使用glib，我会添加类似的宏。这些宏在不损害类型安全的情况下减少代码重复。如果类型错误，将在非空指针之间进行隐式转换，这将导致警告（C++中的错误）。如果忘记包含定义g_new和g_new0的标头，则会出现错误。gnew和gnew0都采用相同的参数，不像malloc采用比calloc更少的参数。只需添加0即可获得零初始化内存。该代码可以用C++编译器编译而无需更改。
void指针是泛型指针，C支持从void指针类型到其他类型的隐式转换，因此不需要显式类型转换。
然而，如果您希望相同的代码在不支持隐式转换的C++平台上完美兼容，则需要进行类型转换，因此这一切都取决于可用性。
正如其他人所说的，它不是C所需要的，而是C++所需要的。包括强制转换可以允许C程序或函数编译为C++。在C中，这是不必要的，因为void*会自动安全地升级为任何其他指针类型。但如果你当时就投了，如果你忘了包括，它会隐藏一个错误stdlib.h。这可能会导致崩溃（更糟的是，不会导致崩溃直到稍后在代码的某个完全不同的部分）。因为stdlib.h包含找到malloc的原型。在由于没有malloc的原型，标准要求C编译器假设malloc返回int。如果没有强制转换当该整数被分配给指针时发出警告；然而，在演员阵容中，这个警告并没有产生，隐藏了一个bug。
不，您不强制转换malloc（）的结果。
一般来说，你不会向虚空施法或从虚空施法。
不这样做的一个典型原因是#include<stdlib.h>失败可能会被忽略。这在很长一段时间内不再是问题，因为C99使隐式函数声明非法，所以如果您的编译器至少符合C99，您将得到一条诊断消息。
但有一个更强烈的理由不引入不必要的指针强制转换：
在C语言中，指针转换几乎总是一个错误。这是因为以下规则（N1570中的§6.5 p7，C11的最新草案）：
对象的存储值只能由左值表达式访问，左值表达式具有以下类型：-与对象的有效类型兼容的类型，-与对象的有效类型兼容的类型的限定版本，-一种类型，它是与对象-类型，该类型是与对象的有效类型，-一种聚合或联合类型，在其成员（递归地包括子集合或包含联合的成员），或-字符类型。
这也称为严格别名规则。因此，以下代码是未定义的行为：
long x = 5;
double *p = (double *)&x;
double y = *p;
有时令人惊讶的是，以下内容也是：
struct foo { int x; };
struct bar { int x; int y; };
struct bar b = { 1, 2};
struct foo *p = (struct foo *)&b;
int z = p->x;
有时，您确实需要强制转换指针，但考虑到严格的别名规则，您必须非常小心。因此，代码中出现的任何指针强制转换都需要重新检查其有效性。因此，您永远不会编写不必要的指针强制转换。
tl；博士
简而言之：因为在C语言中，指针强制转换的任何出现都会给需要特别注意的代码带来危险，所以您不应该编写不必要的指针强制转换。
附带说明：
在某些情况下，您实际上需要转换为void*，例如，如果您想要打印指针：int x=5；printf（“%p\n”，（void*）&x）；这里强制转换是必要的，因为printf（）是一个可变函数，所以隐式转换不起作用。在C++中，情况不同。在处理派生类的对象时，强制转换指针类型有些常见（也是正确的）。因此，在C++中，与void*的转换不是隐式的，这是有意义的。C++有一整套不同风格的铸造。
malloc的转换在C中是不必要的，但在C++中是必需的。
C中不需要铸造，因为：
在C的情况下，void*会自动安全地升级为任何其他指针类型。如果您忘记包含<stdlib.h>，它可能会隐藏错误。这可能会导致崩溃。如果指针和整数的大小不同，则通过强制转换隐藏警告，可能会丢失返回地址的位。如果指针的类型在声明时发生了更改，那么可能还需要更改调用和强制转换malloc的所有行。
另一方面，强制转换可能会增加程序的可移植性。即它允许C程序或函数编译为C++。
对我来说，这里的结论是，在C语言中使用malloc是完全没有必要的，但是如果你使用了C语言，它不会影响malloc，因为malloc仍然会为你分配你请求的内存空间。另一个原因是人们进行选角的原因或原因之一，这是为了使他们能够用C或C++编译相同的程序。
可能还有其他原因，但几乎可以肯定的是，其他原因迟早会让你陷入严重的麻烦。
这个问题是基于意见的滥用问题。
有时我会注意到这样的评论：
不要抛出malloc的结果
or
为什么你不投malloc的结果
关于OP使用铸造的问题。评论本身包含指向此问题的超链接。
这在任何可能的情况下都是不恰当和不正确的。当这确实是一个人自己的编码风格的问题时，没有对也没有错。
为什么会发生这种情况？
它基于两个原因：
这个问题确实是基于意见的。从技术上讲，这个问题早在几年前就应该以观点为基础。一个“我应该”或“我不应该”或等效的“我应该吗”或“不应该”问题，如果没有自己的观点，你就无法集中回答。结束一个问题的原因之一是因为它“可能会导致基于意见的答案”，如这里所示。许多答案（包括最明显和最被接受的@unwind答案）要么完全或几乎完全基于观点（例如，如果你自己选角或重复选角，会在代码中添加一个神秘的“杂乱”，这会很糟糕），并显示出明显和专注的省略选角的倾向。他们一边争论演员阵容的冗余，但更糟糕的是，他们还争论解决由编程本身的错误/失败导致的错误——如果想使用malloc（），就不要#include<stdlib.h>。
我想对所讨论的一些观点提出一个真实的观点，而不是我个人的观点。需要特别注意以下几点：
这样一个很容易陷入自己观点的问题需要一个正反中立的答案。不只是缺点或优点。下面的答案中列出了一个很好的利弊概述：https://stackoverflow.com/a/33047365/12139179（由于这个原因，我个人认为这是迄今为止最好的答案。）
最多会遇到一个原因来解释省略强制转换的原因，即强制转换可能隐藏错误。如果有人使用隐式声明的malloc（）返回int（自C99以来，隐式函数不再是标准函数）和sizeof（int）！=sizeof（int*），如本问题所示为什么这段代码在64位体系结构上是错误的，但在32位体系结构中运行良好？演员阵容会隐藏一个bug。虽然这是真的，但它只显示了故事的一半，因为省略了强制转换只能向前解决更大的错误-在使用malloc（）时不包括stdlib.h。这永远不会是一个严重的问题，如果你，使用符合C99或更高版本的编译器（这是推荐的，应该是强制性的），以及当您想在代码中使用malloc（）时，不要忘记包含stdlib.h，这本身就是一个巨大的错误。
有些人认为C代码符合C++，因为在C++中强制执行强制转换。首先要概括地说：用C++编译器编译C代码不是一种好的做法。C和C++实际上是两种完全不同的语言，具有不同的语义。但如果您真的想/需要使C代码符合C++，反之亦然，请使用编译器开关而不是任何强制转换。由于演员阵容被认为是多余的，甚至是有害的，所以我想把重点放在这些问题上，这些问题给出了演员阵容有用甚至必要的充分理由：https://stackoverflow.com/a/34094068/12139179https://stackoverflow.com/a/36297486/12139179https://stackoverflow.com/a/33044300/12139179
当您的代码、分配的指针的类型（以及转换的类型）发生变化时，转换可能是无效的，尽管这在大多数情况下是不可能的。然后，您还需要维护/更改所有的强制转换，如果代码中有几千个对内存管理函数的调用，那么这将真正地总结并降低维护效率。
摘要：
事实是，如果分配的指针指向基本对齐要求的对象（包括所有对象中的大多数），则根据C标准（从ANSI-C（C89/C90）开始），强制转换是冗余的。
在这种情况下，指针自动对齐，因此不需要执行强制转换：
对aligned_alloc、calloc、malloc和realloc函数的连续调用所分配的存储的顺序和连续性未指定。如果分配成功，则返回的指针将适当对齐，以便可以将其分配给具有基本对齐要求的任何类型对象的指针，然后用于访问空间分配中的此类对象或此类对象的数组ated（直到空间被显式释放）。"来源：C18，§7.22.3/1
“基本对齐是指小于或等于_Aligef（max_align_t）的有效对齐。所有存储持续时间的对象的实现应支持基本对齐。以下类型的对齐要求应为基本对齐：-所有原子、合格或不合格的基本类型；-所有原子、限定或非限定枚举类型；-所有原子、限定或非限定指针类型；-其元素类型具有基本对齐要求的所有数组类型；57)-第7条中规定为完整对象类型的所有类型；-所有结构或联合类型，其所有元素都具有具有基本对齐要求的类型，且其所有元素均没有指定非基本对齐的对齐说明符。如6.2.1所述，后面的声明可能会隐藏前面的声明。"来源：C18，§6.2.8/2
但是，如果为扩展对齐需求的实现定义对象分配内存，则需要强制转换。
扩展对齐由大于_align f（max_align_t）的对齐表示。实现定义了是否支持任何扩展对齐以及支持这些对齐的存储持续时间。具有扩展对齐要求的类型是过度对齐类型。58）来源C18，§6.2.8/3
其他一切都取决于具体的用例和个人的看法。
请注意如何教育自己。
我建议您首先仔细阅读到目前为止所做的所有答案（以及他们可能指出失败的评论），然后如果您或如果您没有将malloc（）的结果应用于某个特定案例，请建立自己的观点。
请注意：
这个问题没有正确和错误的答案。这是一个风格问题，你自己决定选择哪种方式（当然，如果你不是受教育或工作所迫）。请注意这一点，不要让你上当。
最后一点：我最近投票结束了这个基于意见的问题，这是多年来确实需要的。如果您获得了关闭/重新打开特权，我也想邀请您这样做。
malloc的主要问题是获得正确的大小。
malloc（）返回的内存是非类型的，由于简单的强制转换，它不会神奇地获得有效的类型。
我想这两种方法都很好，选择应该取决于程序员的意图。
如果为类型分配内存，则使用强制转换。
ptr=（T*）malloc（sizeof（T））；
如果为给定指针分配内存，则不要使用强制转换。
ptr=malloc（sizeof*ptr）；
Ad 1
第一种方法通过为给定类型分配内存，然后将其强制转换以确保分配给正确的指针，从而确保正确的大小。如果使用了不正确的ptr类型，则编译器将发出警告/错误。如果ptr的类型被更改，那么编译器将指出代码需要重构的地方。
此外，第一种方法可以组合成类似于C++中新运算符的宏。
#define NEW(T) ((T*)malloc(sizeof(T)))
...
ptr = NEW(T);
此外，如果ptr为void*，则此方法有效。
Ad 2
第二个方法不关心类型，它通过从指针的类型中获取数据来确保正确的大小。这种方法的主要优点是，每当ptr的类型发生变化时，都可以自动调整存储大小。它可以在重构时节省一些时间（或错误）。
缺点是，如果ptr为空，则该方法不起作用，但它可能被认为是一件好事。而且它不适用于C++，因此不应在C++程序将要使用的头中的内联函数中使用。
就我个人而言，我更喜欢第二种选择。
