Shouldn't the '^' (bitwise xor) on line 6 be a '|' (bitwise or) instead?
The left shift makes enough room for 'v' (which is always >= 0 and <= 31) so xoring into zeros seems a little odd to me.
In GF(2^n) the '^' operation is addition.
The algorithm is effectively reading base-32 digits into a big number mod some polynomial, so at each step you add the current digit. (The gen[] part below handles the carry/modular reduction).
It does so happen that either would work for that operation, but I would say that ^ is operation that is more consistent with a formal description of the algorithm.
Down below where the modular reduction is handled at line 8 the same addition (^) is used, and '|' wouldn't work there.
Of course, since it works correctly for all values, if someone had a reason to use | instead in the place it works I don't see any reason why they shouldn't. As a reviewer I'd be briefly confused as to what '|' was doing, while (when looking at code working in GF(2)) '^' is obviously addition. Though I doubt I'd raise any issue with either construction.
One could also argue that it would be algorithmically more clear to write the *shift* as a multiplication, but the multiplication operation needed in GF(2^n) is a carryless multiplication. Languages don't provide clmul as a native operation and it would be silly to write one out because the only multiplication we need is the special case of a multiplication by a hamming-weight 1 number whos base-2 log we know-- for that special case multiplication both in GF(2^n) and the integers can be accomplished by a shift. Plus if compiled as written the shift will be actually faster than a GF2 or integer multiplication on devices that people actually use (vs | vs ^ which broadly have identical or close to identical performance). Plus every programmer should be familiar with using shifts to multiply by powers of two.