Apologies if these already got mentioned for the next release.. I don't think I
can be too specific about these (ITAR grumble grumble), else I'd just attach
the patches. But I think it should be pretty clear what needs fixing.
checks/mds.test: the $(foo) syntax requires bash. Using `foo` works fine
in this case because there are no really weird shell
expansions inside.
checks/run-gpg: solaris fgrep cannot take patterns from stdin. I moved
the patterns to a file "run-gpg.patterns" and -f that
instead of using "-f -" and a here-doc.
cipher/tiger.c: the byte array in TIGER_CONTEXT is accessed as a 64 bit
quantity at some point. This crashes processors that require
64 bit alignment on those accesses. Shuffling the members
to allow buf[] to be aligned solves the problem.
That's it for the fixes that shouldn't break anything else. The key generation
timeout in checks/genkey1024.test is too fast for my machine by a factor of 5
(sigh.. and I thought UltraSparcs were supposed to be fast..). I still haven't
come up with a portable way of dealing with the missing __muldi3. Maybe just
throw in a dummy multiply (of the same type used in.. was it tiger.c? one of
the extension modules.. u32 * u32?) in g10.c somewhere and hope it doesn't get
optimized away?
thanks,
-Brian
can be too specific about these (ITAR grumble grumble), else I'd just attach
the patches. But I think it should be pretty clear what needs fixing.
checks/mds.test: the $(foo) syntax requires bash. Using `foo` works fine
in this case because there are no really weird shell
expansions inside.
checks/run-gpg: solaris fgrep cannot take patterns from stdin. I moved
the patterns to a file "run-gpg.patterns" and -f that
instead of using "-f -" and a here-doc.
cipher/tiger.c: the byte array in TIGER_CONTEXT is accessed as a 64 bit
quantity at some point. This crashes processors that require
64 bit alignment on those accesses. Shuffling the members
to allow buf[] to be aligned solves the problem.
That's it for the fixes that shouldn't break anything else. The key generation
timeout in checks/genkey1024.test is too fast for my machine by a factor of 5
(sigh.. and I thought UltraSparcs were supposed to be fast..). I still haven't
come up with a portable way of dealing with the missing __muldi3. Maybe just
throw in a dummy multiply (of the same type used in.. was it tiger.c? one of
the extension modules.. u32 * u32?) in g10.c somewhere and hope it doesn't get
optimized away?
thanks,
-Brian