Вывести результат malloc?

Ответ 1

Нет; Вы не разыгрываете результат, так как:

• В этом нет необходимости, поскольку в этом случае void * автоматически и безопасно переводится на любой другой тип указателя.
• Это добавляет беспорядок в код, приведения не очень легко читаются (особенно если тип указателя длинный).
• Это заставляет вас повторяться, что, как правило, плохо.
• Он может скрыть ошибку, если вы забыли включить <stdlib.h>. Это может вызывать сбои (или, что еще хуже, не приводить к сбою, пока в какой-то совершенно другой части кода). Подумайте, что произойдет, если указатели и целые числа имеют разные размеры; тогда вы скрываете предупреждение путем приведения и можете потерять биты вашего возвращенного адреса. Примечание: начиная с C99 неявные функции ушли из C, и эта точка больше не актуальна, поскольку нет автоматического предположения, что необъявленные функции возвращают int.

В качестве пояснения обратите внимание, что я сказал: "Вы не читаете", а не "вам не нужно читать". На мой взгляд, это неумение включать актерский состав, даже если вы правильно поняли. В этом нет просто никакой выгоды, но куча потенциальных рисков, и в том числе актерский состав, указывает на то, что вы не знаете о рисках.

Также отметьте, как отмечают комментаторы, что вышеизложенное говорит о прямой С, а не о C++. Я очень твердо верю в C и C++ как отдельные языки.

Чтобы добавить, ваш код без необходимости повторяет информацию о типе (int), которая может вызвать ошибки. Лучше отменить ссылку на указатель, используемый для хранения возвращаемого значения, чтобы "заблокировать" их вместе:

int *sieve = malloc(length * sizeof *sieve);

Это также перемещает length вперед для повышения видимости и удаляет лишние скобки с sizeof; они нужны только тогда, когда аргумент является именем типа. Многие люди, кажется, не знают (или игнорируют) это, что делает их код более многословным. Помните: sizeof не является функцией! :)

Хотя перемещение length вперед может улучшить видимость в некоторых редких случаях, следует также обратить внимание, что в общем случае лучше написать выражение следующим образом:

int *sieve = malloc(sizeof *sieve * length);

Поскольку сохранение sizeof первым, в этом случае обеспечивает умножение по крайней мере с size_t математикой.

Сравните: malloc(sizeof *sieve * length * width) и malloc(length * width * sizeof *sieve) вторая может переполнить length * width, когда width и length имеют меньшие типы, чем size_t.

Ответ 2

В C вам не нужно указывать возвращаемое значение malloc. Указатель на void, возвращаемый malloc, автоматически преобразуется в правильный тип. Однако, если вы хотите, чтобы ваш код компилировался с помощью компилятора С++, вам необходимо выполнить актерский состав. Предпочтительной альтернативой для сообщества является использование следующего:

int *sieve = malloc(sizeof *sieve * length);

который дополнительно освобождает вас от необходимости беспокоиться об изменении правой части выражения, если вы измените тип sieve.

Касты плохие, как указывали люди. Специально накладывается указатель.

Ответ 3

Вы делаем, потому что:

• Это делает ваш код более переносимым между C и С++, и, как показывает опыт SO, многие программисты утверждают, что они пишут на C, когда они действительно пишут на С++ (или локальный компилятор C плюс расширения).
• Неспособность сделать это может скрыть ошибку: обратите внимание на все SO-примеры запутывания при написании type * versus type **.
• Идея, что он не позволяет вам заметить, что вам не удалось #include соответствующий заголовочный файл пропускает лес для деревьев. Это то же самое, что сказать: "Не беспокойтесь о том, что вы не попросили компилятора жаловаться на то, что не видите прототипов, - что надоедливый stdlib.h - это важная вещь, которую нужно помнить!"
• Он заставляет дополнительную когнитивную перекрестную проверку. Он помещает (предполагаемый) желаемый тип рядом с арифметикой, которую вы делаете для необработанного размера этой переменной. Бьюсь об заклад, вы можете сделать исследование SO, которое показывает, что ошибки malloc() пойманы намного быстрее, когда есть бросок. Как и в случае с утверждениями, аннотации, которые показывают намерение, уменьшают количество ошибок.
• Повторение себя таким образом, что машина может проверять, часто является идеей большой. На самом деле, что такое утверждение, и это использование актеров - это утверждение. Утверждения по-прежнему являются наиболее общей техникой, которую мы имеем для правильного кода, поскольку Тьюринг много лет назад придумал эту идею.

Ответ 4

Как и указано, он не нужен для C, а для С++. Если вы думаете, что собираетесь скомпилировать свой C-код с помощью компилятора С++, по каким причинам вы можете использовать макрос, например:

#ifdef __cplusplus
# define NEW(type, count) ((type *)calloc(count, sizeof(type)))
#else
# define NEW(type, count) (calloc(count, sizeof(type)))
#endif

Таким образом, вы все равно можете записать его очень компактно:

int *sieve = NEW(int, 1);

и он будет скомпилирован для C и С++.

Ответ 5

Из Википедии:

Advantages to casting

• Включение преобразования может позволить программе или функции на C компилироваться как C++.

• Приведение допускает версии malloc, выпущенные до 1989 года, которые изначально возвращали символ *.

• Приведение может помочь разработчику выявить несоответствия в определении размера при изменении типа указателя назначения, особенно если указатель объявлен вдали от вызова malloc() (хотя современные компиляторы и статические анализаторы могут предупреждать о таком поведении, не требуя приведения).

Disadvantages to casting

• В соответствии со стандартом ANSI C приведение является избыточным.

• Добавление приведения может маскировать неудачу при включении заголовка stdlib.h в который найден прототип для malloc. В отсутствие прототип для malloc, стандарт требует, чтобы компилятор C предположим, что malloc возвращает int. Если нет приведения, предупреждение выдается, когда это целое число назначено указателю; однако с В касте это предупреждение не выдается, скрывая ошибку. По определенным архитектуры и модели данных (такие как LP64 в 64-битных системах, где long и указатели 64-битные, а int 32-битные), эта ошибка может на самом деле приводит к неопределенному поведению, как неявно объявлено malloc возвращает 32-битное значение, тогда как фактически определенная функция возвращает 64-битное значение. В зависимости от соглашения о вызовах и памяти макет, это может привести к разрушению стека. Эта проблема менее вероятна остаться незамеченным в современных компиляторах, так как они производят единообразно предупреждения о том, что была использована необъявленная функция, поэтому предупреждение все еще появляются. Например, поведение по умолчанию GCC - показать предупреждение, которое гласит "несовместимое неявное объявление встроенного функция "независимо от того, присутствует ли приведение или нет.

• Если тип указателя изменяется при его объявлении, можно Кроме того, необходимо изменить все строки, где вызывается malloc, и приведение.

Хотя malloc без приведения является предпочтительным методом, и большинство опытных программистов выбирают его, вы должны использовать все, что захотите, зная о проблемах.

Т.е.: если вам нужно скомпилировать программу на C как C++ (хотя это отдельный язык), вы должны привести результат использования malloc.

Ответ 6

В C вы можете неявно преобразовывать указатель void в любой другой указатель, поэтому приведение не требуется. Используя один, вы можете предложить случайному наблюдателю, что есть какая-то причина, по которой требуется одна, что может ввести в заблуждение.

Ответ 7

Вы не произносите результат malloc, потому что это добавляет бесполезный беспорядок в ваш код.

Наиболее распространенная причина, по которой люди приводят результат malloc, заключается в том, что они не уверены в том, как работает язык C. Это предупреждающий знак: если вы не знаете, как работает конкретный языковой механизм, не делайте предположений. Посмотрите его или спросите о переполнении стека.

Некоторые комментарии:

• Указатель void может быть преобразован в/из любого другого типа указателя без явного приведения (C11 6.3.2.3 и 6.5.16.1).

• Однако С++ не допускает неявного переноса между void* и другим типом указателя. Итак, на С++ литье было бы правильным. Но если вы программируете на С++, вы должны использовать new, а не malloc(). И вы никогда не должны компилировать C-код с помощью компилятора С++.

  Если вам нужно поддерживать как C, так и С++ с тем же исходным кодом, используйте переключатели компилятора, чтобы отметить различия. Не пытайтесь удовлетворить оба языковых стандарта одним и тем же кодом, потому что они несовместимы.

• Если компилятор C не может найти функцию, потому что вы забыли включить заголовок, вы получите сообщение об ошибке компилятора/компоновщика. Поэтому, если вы забыли включить <stdlib.h>, что нет biggie, вы не сможете создать свою программу.

• В древних компиляторах, которые следуют версии стандарта, которому больше 25 лет, забыть включить <stdlib.h> приведет к опасному поведению. Поскольку в этом древнем стандарте функции без видимого прототипа неявно преобразуют возвращаемый тип в int. Выделение результата из malloc явно скрывает эту ошибку.

  Но это действительно не проблема. Вы не используете 25-летний компьютер, так зачем использовать 25-летний компилятор?

Ответ 8

В C вы получаете неявное преобразование из void* в любой другой указатель (data).

Ответ 9

Теперь значение значения, возвращаемого malloc(), не требуется, но я хотел бы добавить одну точку, которая, как кажется, никто не указал:

В древние времена, то есть до ANSI C, void * в качестве общего типа указателей, char * является типом такого использования. В этом случае приведение может отключить предупреждения компилятора.

Ссылка: C Часто задаваемые вопросы

Ответ 10

Не обязательно выводить результаты malloc, так как он возвращает void*, а void* можно указать на любой тип данных.

Ответ 11

Просто добавив свой опыт, изучая компьютерную инженерию, я вижу, что два или три профессора, которые я видел в C, всегда бросали malloc, однако тот, который я попросил (с огромным резюме и пониманием C), сказал мне, что это абсолютно ненужный, но только используемый для того, чтобы быть абсолютно конкретным, и заставить учащихся в менталитете быть абсолютно конкретными. По сути, кастинг ничего не изменит в том, как он работает, он делает именно то, что он говорит, выделяет память, а кастинг не влияет на нее, вы получаете одну и ту же память, и даже если вы производите ее по ошибке (и каким-то образом избегаете компилятора ошибки). C будет обращаться к нему одинаково.

Изменить: У кастинга есть определенная точка. Когда вы используете нотацию массива, генерируемый код должен знать, сколько мест памяти он должен продвинуться, чтобы достичь начала следующего элемента, это достигается путем кастинга. Таким образом, вы знаете, что за двойной вы идете на 8 байт вперед, а для int вы идете 4 и т.д. Таким образом, это не имеет никакого эффекта, если вы используете нотацию указателя, в нотации массива она становится необходимой.

Ответ 12

Вот что говорит Справочное руководство по библиотеке GNU C:

Вы можете сохранить результат malloc в любой переменной указателя без приведения, потому что ISO C автоматически преобразует тип void * в указатель другого типа при необходимости. Но приведение необходимо в контекстах, отличных от операторов присваивания или если вы хотите, чтобы ваш код выполнялся в традиционном C.

И действительно, стандарт ISO C11 (p347) гласит:

Указатель, возвращаемый в случае успешного выделения, выравнивается соответствующим образом, чтобы его можно было присвоить указателю на любой тип объекта с фундаментальным требованием выравнивания, а затем использовать для доступа к такому объекту или массиву таких объектов в выделенном пространстве (до тех пор, пока пространство явно освобождено)

Ответ 13

Указатель void является общим указателем, а C поддерживает неявное преобразование из типа указателя void в другие типы, поэтому нет необходимости явно указывать его.

Однако, если вы хотите, чтобы один и тот же код работал полностью совместимым на платформе С++, который не поддерживает неявное преобразование, вам нужно сделать typecasting, поэтому все зависит от удобства использования.

Ответ 14

Возвращаемый тип - это void *, который может быть отнесен к нужному типу указателя данных, чтобы быть разыменованным.

Ответ 15

В языке C указатель void может быть назначен любому указателю, поэтому вам не следует использовать тип. Если вы хотите выделить "безопасный тип", я могу рекомендовать следующие макрофункции, которые я всегда использую в своих проектах на 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++) {
   ...
}

Ответ 16

Это зависит от языка программирования и компилятора. Если вы используете malloc в C, нет необходимости вводить его, поскольку он будет автоматически набирать cast. Однако, если вы используете С++, тогда вы должны набирать cast, потому что malloc вернет тип void*.

Ответ 17

Люди, привыкшие к GCC и Clang, испорчены. Это не все так хорошо.

Я ужасно испугался на протяжении многих лет потрясающе составленными компиляторами, которых я должен был использовать. Часто компании и менеджеры принимают ультраконсервативный подход к смене компиляторов и даже не будут проверять, будет ли в их системе новый компилятор (с лучшими стандартами и оптимизацией кода). Практическая реальность для работающих разработчиков заключается в том, что когда вы кодируете, вам нужно покрыть свои базы, и, к сожалению, отличные маллинги - хорошая привычка, если вы не можете контролировать, какой компилятор может быть применен к вашему коду.

Я бы также предположил, что многие организации применяют собственный стандарт кодирования и что это должен быть метод, которым следуют люди, если он определен. В отсутствие явных указаний я склонен скорее всего скомпилировать всюду, а не рабскую приверженность стандарту.

Аргумент о том, что он не нужен в соответствии с действующими стандартами, вполне допустим. Но этот аргумент опускает практичность реального мира. Мы не кодируем в мире, управляемом исключительно стандартом дня, а практикой того, что мне нравится называть "областью локального управления реальностью". И это согнулось и исказилось больше, чем просто пространство.: -)

YMMV.

Я склонен думать о том, чтобы бросать malloc в качестве защитной операции. Не красиво, не идеально, но в целом безопасно. (Честно говоря, если вы не включили stdlib.h, у вас больше проблем, чем при использовании malloc!).

Ответ 18

Я положил в литье просто для того, чтобы показать неодобрение уродливой дыры в системе типов, которая позволяет компилировать код, такой как следующий фрагмент, без диагностики, даже если никакие трансляции не используются, чтобы вызвать плохое преобразование:

double d;
void *p = &d;
int *q = p;

Мне жаль, что этого не было (и это не в С++), и поэтому я бросил. Это мой вкус и моя политика программирования. Я не только набрасываю указатель, но и эффективно бросаю бюллетень, и изгоняет демонов глупости. Если я не могу на самом деле изгнать глупость, то, по крайней мере, позвольте мне выразить желание сделать это с жестом протеста.

На самом деле хорошей практикой является обернуть malloc (и друзей) функциями, возвращающими unsigned char *, и в основном никогда не использовать void * в вашем коде. Если вам нужен общий указатель на любой объект, используйте char * или unsigned char *, и у вас есть броски в обоих направлениях. Возможно, единственное расслабление, которое можно потворствовать, использует функции типа memset и memcpy без приведения.

По вопросу о литье и совместимости с С++, если вы пишете свой код, чтобы он компилировался как C и С++ (в этом случае вам нужно указать возвращаемое значение malloc при присвоении ему чего-то другого, кроме void *), вы можете сделать очень полезную вещь для себя: вы можете использовать макросы для кастинга, которые переводится в приведение стилей С++ при компиляции как С++, но сводятся к 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 вашей базы кода для этих идентификаторов покажет вам, где все ваши броски, поэтому вы можете проверить, не являются ли какие-либо из них неправильными.

Затем, продолжая, если вы регулярно компилируете код с С++, он будет применять использование соответствующего приведения. Например, если вы используете strip_qual только для удаления const или volatile, но программа изменяется таким образом, что теперь происходит преобразование типа, вы получите диагностику, и вам придется использовать сочетание отливок для получения желаемого преобразования.

Чтобы помочь вам придерживаться этих макросов, компилятор GNU С++ (не 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-код скомпилирован как С++, вы можете использовать этот параметр -Wold-style-cast, чтобы узнать все вхождения синтаксиса (type), который может входить в код, и следить за этими диагностиками, заменив его соответствующим выбор из вышеупомянутых макросов (или комбинация, если необходимо).

Эта обработка конверсий является самым большим автономным техническим обоснованием для работы в "Чистом C": комбинированном диалекте C и С++, который, в свою очередь, технически оправдывает литье возвращаемого значения malloc.

Ответ 19

Нет, вы не выполняете результат malloc().

В общем, вы не прикладываете к или из void *.

Типичная причина, по которой это не делается, заключается в том, что отказ #include <stdlib.h> может остаться незамеченным. Это уже не проблема уже давно, так как C99 делает неявные декларации функций незаконными, поэтому, если ваш компилятор соответствует по крайней мере C99, вы получите диагностическое сообщение.

Но существует гораздо более сильная причина не вводить ненужные приведения указателей:

В C литье указателей почти всегда является ошибкой. Это происходит из-за следующего правила ( §6.5 p7 в N1570, последний черновик для C11):

Объект должен иметь сохраненное значение, доступ к которому имеет только выражение lvalue, которое имеет один из следующие типы:
- тип, совместимый с эффективным типом объекта,
- квалифицированная версия типа, совместимая с эффективным типом объекта,
- тип, который является подписанным или неподписанным типом, соответствующим эффективному типу объект,
- тип, который является подписанным или неподписанным типом, соответствующим квалифицированной версии эффективный тип объекта,
- совокупный или объединенный тип, который включает один из вышеупомянутых типов среди его членов (в том числе, рекурсивно, члена субагрегата или объединенного союза), или
- тип символа.

Это также известно как правило строгого сглаживания. Таким образом, следующий код: undefined поведение:

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;DR

В двух словах: потому что в C, любое появление указателя должно поднять красный флаг для кода, требующего особого внимания, вы никогда не должны писать ненужные приведения указателей.

Боковые заметки:

• Бывают случаи, когда вам действительно нужен бросок на void *, например. если вы хотите напечатать указатель:

  int x = 5;
  printf("%p\n", (void *)&x);
  

  Приведение необходимо здесь, потому что printf() является вариационной функцией, поэтому неявные преобразования не работают.

• В С++ ситуация другая. Типы указателей заливки несколько распространены (и правильны) при работе с объектами производных классов. Поэтому имеет смысл, что в С++ преобразование в и из void * не соответствует не. С++ имеет целый набор различных вкусов кастинга.

Ответ 20

Лучшее, что нужно делать при программировании на C, когда это возможно:

• Сделайте компиляцию вашей программы с помощью компилятора C со всеми предупреждениями, включенными в -Wall, и исправьте все ошибки и предупреждения
• Убедитесь, что нет переменных, объявленных как auto
• Затем скомпилируйте его с помощью компилятора С++ с -Wall и -std=c++11. Исправьте все ошибки и предупреждения.
• Теперь скомпилируйте с помощью компилятора C еще раз. Ваша программа должна теперь компилироваться без предупреждения и содержать меньше ошибок.

Эта процедура позволяет вам использовать проверку строгих типов С++, тем самым уменьшая количество ошибок. В частности, эта процедура заставляет вас включать stdlib.h или вы получите

malloc не был объявлен в этой области

а также заставляет вас отображать результат malloc или вы получите

неверное преобразование от void* до T*

или какой бы тип вашего целевого объекта не был.

Единственные преимущества написания в C вместо С++, которые я могу найти, - это

• C имеет четко определенный ABI
• С++ может генерировать больше кода [исключения, RTTI, шаблоны, полиморфизм времени выполнения]

Обратите внимание на то, что второй недостаток в идеальном случае исчезает при использовании общего подмножества C вместе со статическим полиморфным признаком.

Для тех, кто считает строгие правила С++ неудобными, мы можем использовать функцию С++ 11 с выведенным типом

auto memblock=static_cast<T*>(malloc(n*sizeof(T))); //Mult may overflow...

Ответ 21

Я предпочитаю делать актеры, но не вручную. Мой любимый использует макросы g_new и g_new0 из glib. Если glib не используется, я бы добавил похожие макросы. Эти макросы уменьшают дублирование кода без ущерба для безопасности типа. Если вы ошиблись, вы получите неявный бросок между не-void указателями, что вызовет предупреждение (ошибка в С++). Если вы забудете включить заголовок, который определяет g_new и g_new0, вы получите сообщение об ошибке. g_new и g_new0 оба принимают те же аргументы, в отличие от malloc, который принимает меньше аргументов, чем calloc. Просто добавьте 0 для получения нулевой инициализации памяти. Код может быть скомпилирован с помощью компилятора С++ без изменений.

Ответ 22

Кастинг предназначен только для С++, а не C. Если вы используете компилятор С++, вы лучше меняете его на компилятор C.

Ответ 23

Концепция указателя void заключается в том, что он может быть применен к любому типу данных, поэтому malloc возвращает void. Также вы должны знать о автоматическом приведении типов. Поэтому не обязательно указывать указатель, хотя вы должны это делать. Это помогает сохранить код чистым и помогает отлаживать

Ответ 24

Указатель void является общим указателем, а C поддерживает неявное преобразование из типа указателя void в другие типы, поэтому нет необходимости явно указывать его.

Однако, если вы хотите, чтобы один и тот же код работал полностью совместимым на платформе С++, который не поддерживает неявное преобразование, вам нужно сделать typecasting, поэтому все зависит от удобства использования.

Ответ 25

• Как и указано, он не нужен для C, но для С++.

• Включение роли может позволить программе или функции C скомпилироваться как С++.

• В C нет необходимости, поскольку void * автоматически и безопасно продвигается к любому другому типу указателя.

• Но если вы затем нажмете, он может скрыть ошибку, если вы забыли включить stdlib.h. Это может привести к сбоям (или, что еще хуже, не вызвать сбой до конца позже в какой-то совершенно другой части кода).

  Потому что stdlib.h содержит прототип для malloc. в отсутствие прототипа для malloc, стандарт требует, чтобы C компилятор предполагает, что malloc возвращает int. Если нет броска, предупреждение выдается, когда этому целому числу присваивается указатель; однако, с литой, это предупреждение не создается, скрывая ошибку.

Ответ 26

Кастинг malloc не нужен в C, но обязателен в C++.

Кастинг не нужен в C из-за:

• void * автоматически и безопасно продвигается к любому другому типу указателя в случае C.
• Он может скрыть ошибку, если вы забыли включить <stdlib.h>. Это может привести к сбоям.
• Если указатели и целые числа имеют разный размер, тогда вы скрываете предупреждение путем кастинга и можете потерять бит вашего возвращенного адреса.
• Если тип указателя изменяется при его объявлении, также может потребоваться изменить все строки, в которых malloc вызывается и выполняется.

С другой стороны, кастинг может увеличить переносимость вашей программы. т.е. он позволяет программе или функции C компилироваться как C++.

Ответ 27

Здесь актерский состав не нужен вообще. Под языком C вы можете неявно конвертировать пустой указатель в любой другой указатель.

Ответ 28

Пожалуйста, сделайте себе одолжение и, что более важно, пользу для следующего человека, который будет поддерживать ваш код, и предоставить как можно больше информации о типе данных программных переменных.

Таким образом, cast возвращаемый указатель из malloc. В следующем коде компилятор может быть уверен, что сите фактически присваивается точка целому числу.

    int *sieve = (int *) malloc(sizeof(int) * length);

Это уменьшает вероятность возникновения человеческой ошибки при изменении типа данных для сита.

Мне было бы интересно узнать, есть ли какие-либо "чистые" компиляторы C, которые бы помешали этому утверждению как ошибочные. Если да, сообщите мне, чтобы я мог избежать их, поскольку их отсутствие проверки типов увеличит общий расход на обслуживание программного обеспечения.