как реализовать такую контрольную сумму на питоне ?

get_crc(const std::string& message, int pos, int len)
{
uint8 crc = 0;
for(int i=pos;i<len+pos;i++)
{
crc+=message;
}
return ~crc;
}

в питоне на вход тоже будет строка подаваться

?

from binascii import crc32

что то у меня не получается ничего толкового. можно пример рабочий ?
для данных 7b 3f 47 29 контрольная сумма должна получится d5.

Что-то я не могу сообразить, что это за спецификация CRC. похоже на какой-то “велосипед”.

Похоже автор имеет в виду просто “контрольную сумму”. Безо всяких спецификаций. Просто складываем все байты сообщения по модулю 256 - и всё.

Только интересно посмотреть, что у него получится, если message будет юникодным. Там же так просто к байту не прибавится. Не должно, по крайней мере.

На питоне надо перевести строку в bytearray (через encode()) и для него уже посчитать эту сумму.
что-то вроде следующего (data - уже encoded string):

def get_crc(data)
res = 0
for b in data:
res += b
if b>256: b -= 256
return res

Тут, очевидно, неправильно.

def get_crc(data)
  res = 0
  for b in data:
    res += b
    if b>256: b -= 256 # << это не имеет смысла здесь
  return res

Но, в любом случае, такой crc бесполезен из-за слишком высокой вероятности коллизии.

Хм… А почему вычитание не имеет смысла? Int будет же расти пока exception не будет, что число слишком длинное. И вернётся - не пикнет.

В принципе, потом можно остаток от деления на 256 вернуть (или последний байт), а так вернётся сумма, которая на длинном тексте может большой набежать. Поэтому лучше сразу число уменьшать, чтобы большого не было: с БЧ и операции дольше и память перевыделять надо.

Про коллизии - это уж автор вопроса пусть решает. Теоретически, любая контрольная сумма длиной меньше текста подвержена коллизиям. Могу представить себе пару ситуаций, когда короткая сумма вполне приемлема на практике: например, когда проверка crc - первая и за ней делается ещё одна на полное соответствие. Но всё равно “правильный CRC” и тут выиграет у велосипеда: с его помощью будет отсеяно куча вариантов, на которые не придётся тратить дополнительное время.

Вообще лучший CRC - разрядности процессора. Может, у автора как раз 8ми битный :-)

Я так и не понял - зачем тут вычитание? b-то в каждой итерации другое - следующее значение из data. На кой нужна проверка с вычитанием прямо перед сменой значения переменной?

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

еще вопрос. crc получается больше байта, как всётаки взять последний байт напрямую? или только divmod(res,256) ?