| Начало » Использование СУБД » Firebird, HQbird, InterBase » CRC32 (чтобы как у всех) Переход к форуму:
	| 
		
			| CRC32 [сообщение #3859] | Thu, 30 November 2023 15:57  |  
			| 
				
				
					|  shalamyansky Сообщений: 150
 Зарегистрирован: August 2022
 | Senior Member |  |  |  
	| Firebird 4.0.3 
 "Руководство по языку SQL СУБД Firebird 4.0" утверждает, что для расчета берется полином 0x04C11DB7.
SQL> select
CON>     hash( 'Z' using CRC32 )
CON>   from
CON>     rdb$database;
        HASH
============
  1733803097  (0x6757BC59)
Однако вот здесь, например,
 https://crccalc.com/?crc=Z&method=crc32&datatype=asc ii&outtype=0
 среди разных вариантов полученный результат не находится, а хотелось бы. Встроенный в Java алгоритм, тоже отталкивающийся от 0x04C11DB7, дает результат 0x59BC5767, как и в первой строке таблицы калькулятора. Уже 2 против 1, другие источники тоже встали на сторону большинства.
 
 Это баг, фича или я чего-то не понимаю? Хотелось бы получить контрольную сумму, согласующуюся с внешними генераторами.
 
 P.S.
 О, сорри, увидел! Это же зеркальное отражение! Не знаю, насколько правильно интерпретируется здесь integer, во-всяком случае, понятно, как добиться нужного результата.
 
 P.P.S.
 По-моему, все-таки неправильно. Но менять теперь нельзя, это уже сакральное знание.
 [Обновления: Thu, 30 November 2023 16:07] Известить модератора |  
	|  |  |  
	|  |  
	|  |  
	|  |  
	|  |  
	|  |  
	| 
		
			| Re: CRC32 [сообщение #3865 является ответом на сообщение #3864] | Thu, 30 November 2023 20:22   |  
			| 
				
				
					|  shalamyansky Сообщений: 150
 Зарегистрирован: August 2022
 | Senior Member |  |  |  
	| sim_84 писал(а) Thu, 30 November 2023 19:09 ТС никак не интерпретировал. Функция возвращает integer, и ТС просто взял этот integer и сравнил с аналогичными функциями других платформ, возвращающих такой же integer. Оказалось, что не такой же. Здесь нет числа в памяти, здесь есть значение целого числа "в воздухе", записанное цифирками 1733803097 (0x6757BC59). А должны быть цифирки 1505515367 (0x59BC5767).Я к тому что функция возвращает integer. Как тс интерпретировал число в байтах уже другой вопрос
 
 
 Извините, но хеш-функции должны для одинаковых входных данных возвращать одинаковые результаты независимо от платформы. Здесь нет места расизму.
 
 [Обновления: Thu, 30 November 2023 20:23] Известить модератора |  
	|  |  |  
	|  |  
	|  |  
	|  |  
	| 
		
			| Re: CRC32 [сообщение #3872 является ответом на сообщение #3869] | Fri, 01 December 2023 15:25   |  
			| 
				
				
					|  SD Сообщений: 452
 Зарегистрирован: August 2022
 | Senior Member |  |  |  
	| Если функция выдаёт целое число, то на клиента это число должно приходить в нативном формате. Никто не станет использовать isc_portable_integer() на содержимое MessageBuffer. Если с CRC это не так - трекер ждёт. 
 PS: ТомКрипт вообще местами дурная библиотека со странными правилами.
 PPS: Поэтому у себя я вообще его изничтожил, заменив на гораздо более простой и предсказуемый (Фаст)ТомМатч.
 [Обновления: Fri, 01 December 2023 15:32] Известить модератора |  
	|  |  |  
	| 
		
			| Re: CRC32 [сообщение #3873 является ответом на сообщение #3872] | Fri, 01 December 2023 16:16   |  
			| 
				
				
					|  shalamyansky Сообщений: 150
 Зарегистрирован: August 2022
 | Senior Member |  |  |  
	| Результат выполнения подобной функции никак не должен зависеть от платформы и реализации. Может, но не должен. Ни от способа представления числа, ни от порядка байт в памяти, ни от протокола передачи, ни от порядка дырочек в перфокарте, ни от чего. Поскольку сейчас хеши для проверки целостности и подлинности используют не только лишь все, а на разных концах каналов работают реализации от совершенно разных провайдеров на совершенно разных платформах, легко представить последствия подобных вольностей. Вообще от наличия компьютера не должен зависеть. Если взять бумагу с ручкой, описание алгоритма, и делить в столбик, должны получить ровно те же цифирки, что и компьютерные реализации. Прошу простить за лирику. 
 Посмотрел обсуждение тикета. Еще в 17 году обнаружили, что хеш от строки "libtomcrypt" выдает OxEF7673B3, в то время как должен быть OxB37376EF. По этому тикету тут же внесли исправление, однако воз и ныне там, выдается OxEF7673B3, как и до революции. Есть подозрение, что такая неприятность происходит на моей Wintel платформе, а на других, возможно, иначе. Ибо в коде замечены defines ENDIAN_LITTLE и ENDIAN_BIG, которые выставляются, скорее всего, в зависимости от платформы. Если у кого есть под рукой Firebird 3.0 и выше не на Windows и не на Intel, проверьте, пожалуйста, просто любопытно. Должно быть
 
 hash( 'libtomcrypt' using CRC32 ) = 3010688751 (а не -277449805)
 
 По факту констатируем, что Firebird 4.0.3 (Windows+IA) при расчете CRC32 возвращает инвертированное значение. Этот факт подлежит исправлению или, по-крайней мере, фиксации и документированию. В тикеты Firebird пока еще ни разу не писал, ну да лиха беда начало.
 |  
	|  |  |  
	|  |  
	|  |  
	|  |  
	|  |  
	|  |  
	| 
		
			| Re: CRC32 [сообщение #3885 является ответом на сообщение #3884] | Mon, 04 December 2023 15:22  |  
			| 
				
				
					|  SD Сообщений: 452
 Зарегистрирован: August 2022
 | Senior Member |  |  |  
	| Параметр конфига с депрекацией в следующей версии - более типичное решение. |  
	|  |  | 
 
 
 Текущее время: Fri Oct 31 10:57:54 GMT+3 2025 
 Общее время, затраченное на создание страницы: 0.01563 секунд |