python

Код (Text):

1. def  hash_xor(s)
2.       ln = len(s)
3.       tmp = 0
4.        
5.       i = 0
6.       while  i<ln:
7.              tmp = tmp ^ ( ord(s[i]) )
8.              i = i +1
9.      return tmp
10.  
11. print( hash_xor ("asdfasdfasd12421") )

Нужно чтоб число которое возвращает функция было длинной в 4 байта.
А возвращает очень длинное число....

В общем хочу сделать еквивалент такого кода на С

Код (Text):

1. DWORD CalcHash(char *Str )
2. {
3.     DWORD dwHash = 0;
4.     char *CopyStr = Str;
5.  
6.     while ( *CopyStr != 0)
7.     {
8.         dwHash = dwHash ^ ( *CopyStr );
9.         CopyStr++;
10.     }
11.  
12.     return dwHash;
13. }

 

Java, теперь Python - скриптоводы наступают

 

return tmp % 0xFFFFFFFF

 

Так вы только результат обрежете до 4-х байт. А топикстартер похоже подразумевал, что и вычисления должны выполняться над 4-хбайнтными числами. А это не так. В Питоне целые числа не имеют ограничения на длину, длина у них в битах строго такая, какая необходима для двоичного представления этого числа (для положительных чисел - количество битов до первой старшей единички, для отрицательных - количество битов до самого старшего нолика плюс один бит).

Пока дело касается только операций and, or, сложений или умножений целых чисел - разницы с представлением фиксированой длиной практически нет (пока длина не превышает фиксированную). А вот если дело касается операций побитовой инверсии или xor над числами с разными знаками - вот тут то разница сразу же вылезает даже для более коротких чисел.

 

пичалька(
Как быть? Можно создать свой тип данных и для него определить операции xor,and и тп?..

 

Стоп. Не надо печалиться, вся жизнь впереди.

Я, похоже, погорячился насчет жуткой разницы. Нет, в Питоне действительно битовая длина целых чисел изменяется на лету и не ограничена. Но Питон корректно использует расширение знака при операциях над числами разной битовой длины, и из-за этой подгонки численные результаты битовых операций оказываются в любых случаях соответствующими операциям над числами фиксированной длины, пока нет влияния старших битов на младшие (сдвиги вправо) совместно с переполнением

У вас вроде сдвигов вправо нет, так что похоже GorluM прав, и достаточно просто преобразовать конечный результат к фиксированной длине.