Вам не нужен % pow(2,64)
, и фактически он вводит ошибки, так как он преобразует результат в double
. Арифметика типа uint64_t
уже по модулю 2 ^ 64.
Проблема чтения 8 байтов как uint64_t
в основном о том, над какими реализациями C вы хотите, чтобы он работал, и о формате 8 байтов в вашем массиве символов.
Если вы знаете, что 8 байтов в массиве char имеют тот же самый порядок байтов, что и ваша система (то есть самый старший байт сначала, если ваша система имеет старший-байтовый цикл, самый старший байт последний, если ваша система имеет младший порядок байтов) ), то, что вы делаете, вероятно, в порядке. Кто бы ни поставлял буфер, он должен убедиться, что он правильно выровнен, хотя, если в вашей системе есть ограничения на uint64_t
.
Если данные поступили из какого-либо файла или через Интернет, то порядковый номер может не соответствовать системе и, вероятно, не будет правильно выровнен.
Если 8 байтов с прямым порядком байтов, этот код не будет работать в системе с прямым порядком байтов, поэтому, если вы хотите, чтобы ваш код был переносимым, вам нужно было бы сделать что-то еще. Существуют системы, в которых unit64_t
не занимает 8 байт, и даже memcpy
не работает. Спецификация вашей функции может означать, что она полностью неприменима к таким системам, но в некоторых случаях имеет смысл преобразовать массив из 8 символов в uint64_t
, независимо от того, действительно ли CHAR_BIT больше 8.
Для надежного базового решения: считывайте по одному байту за раз и складывайте части вместе (сдвиг влево на 0, затем на 8 и т. Д.). Если вам это не нравится, сделайте несколько предположений о том, какие платформы вам нужно поддерживать, и оптимизируйте.
Как бы вы ни читали данные, если вы хотите получить результат обратно в массив символов, затем выполните обратный процесс - в случае вашего кода *((uint64_t*)output_buffer) = kp[0] + kp[1];
.