В этот вопрос, кто-то предложил в comment, что я должен не введите результат malloc
, т.е.
int *sieve = malloc(sizeof(int) * length);
а не:
int *sieve = (int *) malloc(sizeof(int) * length);
Почему это так?
Нет; вы не произносите результат, так как:
void *
автоматически и безопасно продвигается к любому другому типу указателя в этом случае.<stdlib.h>
. Это может привести к сбоям (или, что еще хуже, не привести к сбою до конца позже в какой-то совершенно другой части кода). Подумайте, что произойдет, если указатели и целые числа по-разному; то вы скрываете предупреждение путем кастинга и можете потерять бит вашего возвращенного адреса. Примечание: с C11 неявные функции исчезли из C, и эта точка больше не актуальна, поскольку нет автоматического предположения о том, что необъявленные функции возвращают int
.Как пояснение, обратите внимание, что я сказал "вы не бросаете", а не "вам не нужно бросать". На мой взгляд, это неспособность включить актерский состав, даже если вы поняли это правильно. Для этого просто нет преимуществ, но куча потенциальных рисков, включая включение, указывает, что вы не знаете о рисках.
Также обратите внимание, как отмечают комментаторы, что вышеперечисленные разговоры о прямом C, а не С++. Я очень твердо верю в C и С++ как отдельные языки.
Чтобы добавить далее, ваш код без необходимости повторяет информацию типа (int
), которая может вызвать ошибки. Лучше разыменовать указатель, используемый для хранения возвращаемого значения, чтобы "заблокировать" два вместе:
int *sieve = malloc(length * sizeof *sieve);
Это также перемещает length
на передний план для увеличения видимости и сбрасывает лишние круглые скобки с помощью sizeof
; они нужны только тогда, когда аргумент является именем типа. Многие люди, похоже, не знают (или игнорируют) это, что делает их код более подробным. Помните: sizeof
не является функцией!:)
При перемещении length
на фронт может увеличиться видимость в некоторых редких случаях, следует также обратить внимание на то, что в общем случае лучше написать выражение как:
int *sieve = malloc(sizeof *sieve * length);
Так как сначала удерживая sizeof
, в этом случае, умножение выполняется, по крайней мере, с помощью size_t
math.
Compare: malloc(sizeof *sieve * length * width)
vs. malloc(length * width * sizeof *sieve)
второй может переполнить length * width
, когда width
и length
являются меньшими типами, чем size_t
.
void*
тип!), эти версии никогда не были стандартными. C89 (первая стандартизированная версия) требовала, чтобы malloc
возвращал void*
и чтобы void*
был неявно конвертируемым.
В C вам не нужно указывать возвращаемое значение malloc
. Указатель на void, возвращаемый malloc
, автоматически преобразуется в правильный тип. Однако, если вы хотите, чтобы ваш код компилировался с помощью компилятора С++, вам необходимо выполнить актерский состав. Предпочтительной альтернативой для сообщества является использование следующего:
int *sieve = malloc(sizeof *sieve * length);
который дополнительно освобождает вас от необходимости беспокоиться об изменении правой части выражения, если вы измените тип sieve
.
Касты плохие, как указывали люди. Специально накладывается указатель.
malloc(length * sizeof *sieve)
делает его похожим на sizeof
поэтому я думаю, что malloc(length * sizeof(*sieve))
более читабелен.
malloc(length * (sizeof *sieve))
еще более читабельна. ПО МОЕМУ МНЕНИЮ.
Вы делаем, потому что:
type *
versus type **
.#include
соответствующий заголовочный файл пропускает лес для деревьев. Это то же самое, что сказать: "Не беспокойтесь о том, что вы не попросили компилятора жаловаться на то, что не видите прототипов, - что надоедливый stdlib.h - это важная вещь, которую нужно помнить!" malloc()
пойманы намного быстрее, когда есть бросок. Как и в случае с утверждениями, аннотации, которые показывают намерение, уменьшают количество ошибок..c
/ .cpp
для компиляции, так как оба не очень полезны, но один из случаев - это добавление поддержки C ++ throw
при компиляции с помощью компилятора C ++ (но return -1;
при компиляции с помощью компилятора C или чего-то еще).
Как и указано, он не нужен для 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 и С++.
new
в определении C ++?
Из Wikipedia
Преимущества литья
Включение роли может позволить программе или функции C скомпилироваться как С++.
Листинг позволяет использовать версии malloc до 1989 года, изначально возвращенные char *.
Кастинг может помочь разработчику выявить несоответствия в типе, если тип указателя назначения изменится, особенно если указатель объявлен далеко от вызова malloc() (хотя современные компиляторы и статические анализаторы могут предупреждать о таком поведении, не требуя литой).
Недостатки при литье
В стандарте ANSI C литье является избыточным.
Добавление роли может маскировать отказ включения заголовка stdlib.h, в для которого найден прототип malloc. В отсутствие прототип для malloc, стандарт требует, чтобы компилятор C предположим, что malloc возвращает int. Если нет броска, предупреждение выдается, когда этому целому числу присваивается указатель; однако, с бросок, это предупреждение не создается, скрывая ошибку. На определенных архитектуры и модели данных (например, LP64 на 64-битных системах, где long и указатели 64-бит, а int 32-бит), эта ошибка может фактически приводят к поведению undefined, поскольку неявно объявлено malloc возвращает 32-битное значение, тогда как фактически определенная функция возвращает 64-битное значение. В зависимости от соглашений вызова и памяти макета, это может привести к разрыву стека. Этот вопрос менее вероятен оставаться незамеченным в современных компиляторах, поскольку они равномерно производят предупреждения о том, что использовалась незаявленная функция, поэтому предупреждение будет все еще появляются. Например, поведение GCC по умолчанию - показать предупреждение, которое гласит "несовместимое неявное объявление встроенного функции" независимо от того, присутствует ли приведение или нет.
Если тип указателя изменяется при его объявлении, можно также необходимо изменить все строки, в которых malloc вызывается и выполняется.
Хотя malloc без литья является предпочтительным методом, и большинство опытных программистов выбирают его, вы должны использовать то, что вам нравится знать о проблемах.
i.e: Если вам нужно скомпилировать C-программу как С++ (хотя это отдельный язык), вы должны использовать malloc
с кастингом.
malloc()
»? Не могли бы вы привести пример?
p = malloc(sizeof(*p) * count)
автоматически регистрирует изменения в типе, поэтому вам не нужно получать предупреждения и что-либо менять. Так что это не реальное преимущество по сравнению с лучшей альтернативой для не-каста.
В C вы можете неявно преобразовывать указатель void в любой другой указатель, поэтому приведение не требуется. Используя один, вы можете предложить случайному наблюдателю, что есть какая-то причина, по которой требуется одна, что может ввести в заблуждение.
Вы не произносите результат 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-летний компилятор?
В C вы получаете неявное преобразование из void*
в любой другой указатель (data).
Теперь значение значения, возвращаемого malloc()
, не требуется, но я хотел бы добавить одну точку, которая, как кажется, никто не указал:
В древние времена, то есть до ANSI C, void *
в качестве общего типа указателей, char *
является типом такого использования. В этом случае приведение может отключить предупреждения компилятора.
Ссылка: C Часто задаваемые вопросы
Не обязательно выводить результаты malloc
, так как он возвращает void*
, а void*
можно указать на любой тип данных.
Просто добавив свой опыт, изучая компьютерную инженерию, я вижу, что два или три профессора, которые я видел в C, всегда бросали malloc, однако тот, который я попросил (с огромным резюме и пониманием C), сказал мне, что это абсолютно ненужный, но только используемый для того, чтобы быть абсолютно конкретным, и заставить учащихся в менталитете быть абсолютно конкретными. По сути, кастинг ничего не изменит в том, как он работает, он делает именно то, что он говорит, выделяет память, а кастинг не влияет на нее, вы получаете одну и ту же память, и даже если вы производите ее по ошибке (и каким-то образом избегаете компилятора ошибки). C будет обращаться к нему одинаково.
Изменить: У кастинга есть определенная точка. Когда вы используете нотацию массива, генерируемый код должен знать, сколько мест памяти он должен продвинуться, чтобы достичь начала следующего элемента, это достигается путем кастинга. Таким образом, вы знаете, что за двойной вы идете на 8 байт вперед, а для int вы идете 4 и т.д. Таким образом, это не имеет никакого эффекта, если вы используете нотацию указателя, в нотации массива она становится необходимой.
Возвращаемый тип - это void *, который может быть отнесен к нужному типу указателя данных, чтобы быть разыменованным.
void*
может быть приведен к нужному типу, но в этом нет необходимости, поскольку он будет автоматически преобразован. Таким образом, актерский состав не является необходимым и фактически нежелательным по причинам, указанным в ответах с высокой оценкой.
Это то, что в Справочном руководстве библиотеки GNU C:
Вы можете сохранить результат
malloc
в любую переменную указателя без трансляции, потому что ISO C автоматически преобразует типvoid *
в другой тип указателя, когда это необходимо. Но бросок необходим в контексте, отличном от операторов присваивания, или если вы захотите, чтобы ваш код работал в традиционном C.
И действительно, стандарт ISO C11 (p347) говорит так:
Указатель возвращается, если выделение успешно выполняется соответствующим образом, чтобы его можно было назначить указателю на любой тип объекта с фундаментальным требованием к выравниванию, а затем использовать для доступа к такому объекту или массиву таких объектов в выделенном пространстве (до тех пор, пока пространство явно освобождено)
Указатель void является общим указателем, а C поддерживает неявное преобразование из типа указателя void в другие типы, поэтому нет необходимости явно указывать его.
Однако, если вы хотите, чтобы один и тот же код работал полностью совместимым на платформе С++, который не поддерживает неявное преобразование, вам нужно сделать typecasting, поэтому все зависит от удобства использования.
malloc
и друзей в C ++ является хорошим предупреждением о том, что оно заслуживает особого внимания (или переписывания в C).
void *
, поэтому void *
недостаточно для правильного хранения указателя функции.
Это зависит от языка программирования и компилятора. Если вы используете malloc
в C, нет необходимости вводить его, поскольку он будет автоматически набирать cast. Однако, если вы используете С++, тогда вы должны набирать cast, потому что malloc
вернет тип void*
.
В языке 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++) {
...
}
malloc()
.
void*
для / из указателя функции может привести к потере информации, поэтому «указатель void может быть назначен любому указателю» - проблема в этих случаях. Присвоение void*
из malloc()
любому указателю объекта не является проблемой.
Люди, привыкшие к GCC и Clang, испорчены. Это не все так хорошо.
Я ужасно испугался на протяжении многих лет потрясающе составленными компиляторами, которых я должен был использовать. Часто компании и менеджеры принимают ультраконсервативный подход к смене компиляторов и даже не будут проверять, будет ли в их системе новый компилятор (с лучшими стандартами и оптимизацией кода). Практическая реальность для работающих разработчиков заключается в том, что когда вы кодируете, вам нужно покрыть свои базы, и, к сожалению, отличные маллинги - хорошая привычка, если вы не можете контролировать, какой компилятор может быть применен к вашему коду.
Я бы также предположил, что многие организации применяют собственный стандарт кодирования и что это должен быть метод, которым следуют люди, если он определен. В отсутствие явных указаний я склонен скорее всего скомпилировать всюду, а не рабскую приверженность стандарту.
Аргумент о том, что он не нужен в соответствии с действующими стандартами, вполне допустим. Но этот аргумент опускает практичность реального мира. Мы не кодируем в мире, управляемом исключительно стандартом дня, а практикой того, что мне нравится называть "областью локального управления реальностью". И это согнулось и исказилось больше, чем просто пространство.: -)
YMMV.
Я склонен думать о том, чтобы бросать malloc в качестве защитной операции. Не красиво, не идеально, но в целом безопасно. (Честно говоря, если вы не включили stdlib.h, у вас больше проблем, чем при использовании malloc!).
Я положил в литье просто для того, чтобы показать неодобрение уродливой дыры в системе типов, которая позволяет компилировать код, такой как следующий фрагмент, без диагностики, даже если никакие трансляции не используются, чтобы вызвать плохое преобразование:
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
.
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;
Иногда вам делать нужно указывать указатели, но с учетом строгого правила псевдонимов вы должны быть очень осторожны с ним. Таким образом, любое появление указателя, введенного в вашем коде, - это место, где вы должны дважды проверять его достоверность. Поэтому вы никогда не пишете ненужный указатель.
В двух словах: потому что в C, любое появление указателя должно поднять красный флаг для кода, требующего особого внимания, вы никогда не должны писать ненужные приведения указателей.
Боковые заметки:
Бывают случаи, когда вам действительно нужен бросок на void *
, например. если вы хотите напечатать указатель:
int x = 5;
printf("%p\n", (void *)&x);
Приведение необходимо здесь, потому что printf()
является вариационной функцией, поэтому неявные преобразования не работают.
В С++ ситуация другая. Типы указателей заливки несколько распространены (и правильны) при работе с объектами производных классов. Поэтому имеет смысл, что в С++ преобразование в и из void *
не соответствует не. С++ имеет целый набор различных вкусов кастинга.
Я предпочитаю делать актеры, но не вручную. Мой любимый использует макросы g_new
и g_new0
из glib. Если glib не используется, я бы добавил похожие макросы. Эти макросы уменьшают дублирование кода без ущерба для безопасности типа. Если вы ошиблись, вы получите неявный бросок между не-void указателями, что вызовет предупреждение (ошибка в С++). Если вы забудете включить заголовок, который определяет g_new
и g_new0
, вы получите сообщение об ошибке. g_new
и g_new0
оба принимают те же аргументы, в отличие от malloc
, который принимает меньше аргументов, чем calloc
. Просто добавьте 0
для получения нулевой инициализации памяти. Код может быть скомпилирован с помощью компилятора С++ без изменений.
Кастинг предназначен только для С++, а не C. Если вы используете компилятор С++, вы лучше меняете его на компилятор C.
Лучшее, что нужно делать при программировании на C, когда это возможно:
-Wall
, и исправьте все ошибки и предупрежденияauto
-Wall
и -std=c++11
. Исправьте все ошибки и предупреждения.Эта процедура позволяет вам использовать проверку строгих типов С++, тем самым уменьшая количество ошибок. В частности, эта процедура заставляет вас включать stdlib.h
или вы получите
malloc
не был объявлен в этой области
а также заставляет вас отображать результат malloc
или вы получите
неверное преобразование от
void*
доT*
или какой бы тип вашего целевого объекта не был.
Единственные преимущества написания в C вместо С++, которые я могу найти, - это
Обратите внимание на то, что второй недостаток в идеальном случае исчезает при использовании общего подмножества C вместе со статическим полиморфным признаком.
Для тех, кто считает строгие правила С++ неудобными, мы можем использовать функцию С++ 11 с выведенным типом
auto memblock=static_cast<T*>(malloc(n*sizeof(T))); //Mult may overflow...
gcc -c c_code.c
), код C ++ как C ++ (например, g++ -c cpp_code.cpp
), а затем связать их вместе (например, gcc c_code.o cpp_code.o
или наоборот, в зависимости от зависимостей проекта). Теперь не должно быть причин лишать себя каких-либо приятных черт любого языка ...
Концепция указателя void заключается в том, что он может быть применен к любому типу данных, поэтому malloc возвращает void. Также вы должны знать о автоматическом приведении типов. Поэтому не обязательно указывать указатель, хотя вы должны это делать. Это помогает сохранить код чистым и помогает отлаживать
Как и указано, он не нужен для C, но для С++.
Включение роли может позволить программе или функции C скомпилироваться как С++.
В C нет необходимости, поскольку void * автоматически и безопасно продвигается к любому другому типу указателя.
Но если вы затем нажмете, он может скрыть ошибку, если вы забыли включить stdlib.h. Это может привести к сбоям (или, что еще хуже, не вызвать сбой до конца позже в какой-то совершенно другой части кода).
Потому что stdlib.h содержит прототип для malloc. в отсутствие прототипа для malloc, стандарт требует, чтобы C компилятор предполагает, что malloc возвращает int. Если нет броска, предупреждение выдается, когда этому целому числу присваивается указатель; однако, с литой, это предупреждение не создается, скрывая ошибку.
Указатель void является общим указателем, а C поддерживает неявное преобразование из типа указателя void в другие типы, поэтому нет необходимости явно указывать его.
Однако, если вы хотите, чтобы один и тот же код работал полностью совместимым на платформе С++, который не поддерживает неявное преобразование, вам нужно сделать typecasting, поэтому все зависит от удобства использования.
Здесь актерский состав не нужен вообще. Под языком C вы можете неявно конвертировать пустой указатель в любой другой указатель.
Кастинг malloc не нужен в C, но обязателен в C++.
Кастинг не нужен в C из-за:
void *
автоматически и безопасно продвигается к любому другому типу указателя в случае C.<stdlib.h>
. Это может привести к сбоям.malloc
вызывается и выполняется.С другой стороны, кастинг может увеличить переносимость вашей программы. т.е. он позволяет программе или функции C компилироваться как C++.
Пожалуйста, сделайте себе одолжение и, что более важно, пользу для следующего человека, который будет поддерживать ваш код, и предоставить как можно больше информации о типе данных программных переменных.
Таким образом, cast
возвращаемый указатель из malloc
. В следующем коде компилятор может быть уверен, что сите фактически присваивается точка целому числу.
int *sieve = (int *) malloc(sizeof(int) * length);
Это уменьшает вероятность возникновения человеческой ошибки при изменении типа данных для сита.
Мне было бы интересно узнать, есть ли какие-либо "чистые" компиляторы C, которые бы помешали этому утверждению как ошибочные. Если да, сообщите мне, чтобы я мог избежать их, поскольку их отсутствие проверки типов увеличит общий расход на обслуживание программного обеспечения.