Легенда:
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
Я ж не про ошибки на этапе компиляции. Ну пусть это не... 13.06.06 13:45 Число просмотров: 3179
Автор: DPP <Dmitry P. Pimenov> Статус: The Elderman Отредактировано 13.06.06 13:48 Количество правок: 2
|
> > 2. buffer, указатель, указывающий на константу. При > > ожидаемой модификации будет segmentation fault. > > Не факт. Принимаемое значение скорее всего (char *), а не > (char[]) и не (const char *). Очень многие библиотечные
Я ж не про ошибки на этапе компиляции. Ну пусть это не константная строка, описание char * еще не признак того, что она меняется. Указатель на константу лишь будет говорить то, что она заведомо не меняется. Указатель не на константу вполне можно проинициализировать указателем на контстанту, как, впрочем, если сделать все наоборот - тоже. Компилятор не даст ничего изменить по адресу соответствующего указателя (на константу), что избавляет от ошибок программиста и RunTimeError при выполнении на определенных системах. Та же система выдаст предупреждение или сообщит об ошибке, если в параметрах функции char *, а передавать пытаешся указатель на константу. Замечал, что практически все компиляторы считают, что если параметр не постоянный, то в функции он будет менятся.
> функции для возвращаемого значения используют вот такую вот > пару буфер/длина. То что на самом деле буфер - константа - > это не проблема библиотеки, а проблема клиента этой > библиотеки (вполне возможно где то в описалове это указано)
Это точно, как говорится - сам дурак. Если в качестве буфера для возврата передаешь константную строку.
Если функция работает со строкой, то либо она ее не изменяет (не использует для возврата результата), либо конвертирует ее в такую же по длине и функции преобразования кодировки тому пример. Все остальное будет резать глаз/слух.
> > 3. Шифровка будет соизмерима с длиной ключа, а не с > > исходным текстом. Так что она просто не поместится в > > buffer, если > strlen(buffer)<sizeof(cryptContext->key) > > (извиняюсь за корявое неравенство). > > Вот это 100%. Причем вполне возможно, что шифрование не > происходит именно по этой причине. Просто переданный буфер > меньше размера ключа и библиотека возвращается с ошибкой.
Это же не просто проблема, а проблема номер 1. А именно важно не просто передать килобитные данные, а что численно они были меньше N. Поэтому даже обменом массивами/структурами фиксированного размера пользоваться ндо очень осторожно.
Как все просто с симметричным блочным шифрованием. Полагаю библиотечная функция не должна возвращать ошибку, а дробить заданный текст на блоки подходящего размера, их шифровать и возвращать серию блоков.
> > 4. По хорошему функция шифрования должна возвращать > > шифровку и (полагаю) должна быть описана примерно так: > char > > *cryptEncrypt( cryptContext, buffer, strlen(buffer) ); > > Возможно и другие варианты, например > cryptContext->cifer > > и будет указателем на зашифрованый текст. > > Как по мне возврат буфера - плохая идея, а вот возврат > шифровки в контексте - вполне возможный вариант. Если так, > то скорее всего должна быть еще и функция-getter для > сокрытия внутренностей контекста.
По мне тоже плохая, так как где-то должно быть описаны правила очистки буфера. То есть скорее всего он будет выделяться обычным malloc'ом, а высвобождать после использования должен пользователь(программист) библиотеки.
Возможет вариант (как sprintf), когда программист передает и буфер для результата плюс его длина или он обязан передать буфер достаточного размера.
Короче даже (тем более) для собственного самообразования рекомендуется написать все это самостоятельно, а не пользоваться чужой библиотекой.
|
|
|