Начало » Использование СУБД » Firebird, HQbird, InterBase » CRC32 (чтобы как у всех) 
	
		
		
			| CRC32 [сообщение #3859] | 
			Thu, 30 November 2023 15:57   | 
		 
		
			
				
				
				
					
						  
						shalamyansky
						 Сообщений: 150 Зарегистрирован: August 2022 
						
					 | 
					Senior Member  | 
					 | 
		 
		 
	 | 
 
	
		Firebird 4.0.3 
SQL> select
CON>     hash( 'Z' using CRC32 )
CON>   from
CON>     rdb$database;
        HASH
============
  1733803097  (0x6757BC59)
  
"Руководство по языку SQL СУБД Firebird 4.0" утверждает, что для расчета берется полином 0x04C11DB7.  
Однако вот здесь, например, 
     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 и сравнил с аналогичными функциями других платформ, возвращающих такой же integer. Оказалось, что не такой же. Здесь нет числа в памяти, здесь есть значение целого числа "в воздухе", записанное цифирками 1733803097 (0x6757BC59). А должны быть цифирки 1505515367 (0x59BC5767). 
 
Извините, но хеш-функции должны для одинаковых входных данных возвращать одинаковые результаты независимо от платформы. Здесь нет места расизму. 
		
		
		[Обновления: 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  | 
					 | 
		 
		 
	 | 
 
	| 
		Параметр конфига с депрекацией в следующей версии - более типичное решение.
		
		
		
 |  
	| 
		
	 | 
 
 
 |   
Переход к форуму:
 
 Текущее время: Tue Nov 04 13:24:22 GMT+3 2025 
 Общее время, затраченное на создание страницы: 0.00989 секунд 
 |