Если вызываемая функция всегда проверяет размер массива в C?

Это скорее вопрос о стиле программирования, чем о техничности: Должна ли моя функция C всегда требовать аргумента для длины массива, хотя функция не зависит от нее?

Итак, либо как это void foo(int* a, int size), либо как void foo(int* a)

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

Я новичок в C, поэтому я боюсь, что возможно переполнение буфера. Техническое обоснование того, почему одно лучше другого, было бы здорово. Спасибо!

ОТВЕТЫ

Ответ 1

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

Ответ 2

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

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

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

Ответ 3

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

Позвольте мне дать вам мою точку зрения. Код считается здоровым, если он соответствует следующему.

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

Понятие включения длины в сигнатуру функции падает на первые 2 балла выше.

Как автор функции/логики, вы точно знаете, чего собираетесь достичь, и, следовательно, вы не хотите добавлять длину. Однако подумайте о случае, через некоторое время появляется ошибка, и вас больше нет в проекте, а кто-то другой берет на себя роль обслуживания. Инженер потребует значительных усилий, чтобы понять, что вы написали и выполнить исправление.

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

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

Если вы хотите внести свой вклад в любой из проектов с открытым исходным кодом, вы должны обязательно принять эту концепцию: -)

Удачи!

Ответ 4

Короткий ответ: Да, ты должен.: D Длительный ответ: Поскольку ваш массив на самом деле является указателем на память, вы не можете легко получить реальный размер. Итак, если ваша функция должна изменить данные массива, целесообразно проверить, действительно ли это возможно, без перезаписи памяти, которая не выделяется для вашего массива. Как правило, рекомендуется проверять пределы памяти перед тем, как записывать данные в указатель!;)

Ответ 5

Я расскажу, как Суврав сказал, что это не обязательно, а это означает, что если вы на 100% уверены, что длина "правильная", вы можете пропустить чек, однако он не рекомендуется, даже если вы на 120% что переполнения не будет. Кроме того, добавление этой проверки делает функцию полезной для случаев, когда вы не уверены в ее длине, поэтому лучше добавить ее, даже если вы считаете, что вам это не нужно, она может пригодиться, когда и если ваш код будет расти.

Ответ 6

Так как это C, вы должны "доверять программисту".

Невозможно гарантировать, что параметр size - это фактическая длина массива. Это может быть любое произвольное число. Так зачем беспокоиться (и загромождать интерфейс) (и замедлять работу программы)?