On Sun, Jul 29 2018, Michael wrote: > On 29/07/2018 22:06, brian m. carlson wrote: >> On Sun, Jul 29, 2018 at 09:48:43PM +0200, Michael wrote: >>> On 29/07/2018 21:27, brian m. carlson wrote: >>>> Well, that explains it. I would recommend submitting a patch to >>>> https://github.com/cr-marcstevens/sha1collisiondetection, and the we can >>>> pull in the updated submodule with that fix. >>> Not sure I am smart enough to do that. I'll have to download, build, and see >>> what it says. >> The issue is that somewhere in lib/sha1.c, you need to cause >> SHA1DC_BIGENDIAN to be set. That means you need to figure out what >> compiler macro might indicate that. > I remember - roughly - a few decades back - having an assignment to > write code to determine endianness. PDP and VAC were different iirc, > and many other micro-processors besides the 8088/8086/z85/68k/etc.. > > If you are looking for a compiler macro as a way to determine this - > maybe you have one for gcc, but not for xlc. I do not know it - currently :) I'm not familiar with AIX, but from searching around I found this porting manual from IBM: http://www.redbooks.ibm.com/redbooks/pdfs/sg246034.pdf There they suggest either defining your own macros, or testing the memory layout at runtime (see section "2.2.2.3 Technique 3: Testing memory layout" and surrounding sections). Perhaps it's worth taking a step back here and thinking about whether this whole thing is unworkable. It was hard enough to get this to work on the combination of Linux, *BSD and Solaris, but I suspect we'll run into increasingly obscure platforms where this is hard or impossible (AIX, HP/UX etc.) The reason we're in this hole is because we use this sha1collisiondetection library to do SHA-1, and the reason we have issues with it specifically (not OpenSSL et al) is because its only method of detecting endianness is at compile time. This didn't use to be the case, it was changed in this commit: https://github.com/cr-marcstevens/sha1collisiondetection/commit/d597672 Dan Shumow: Since the commit message doesn't say why, can you elaborate a bit on why this was done, i.e. is determining this at runtime harmful for performance? If not, perhaps it would be best to bring this back, at least as an option. And, as an aside, the reason we can't easily make it better ourselves is because the build process for git.git doesn't have a facility to run code to detect this type of stuff (the configure script is always optional). So we can't just run this test ourselves. Junio: I've barked up that particular tree before in https://public-inbox.org/git/87a7x3kmh5.fsf@xxxxxxxxxxxxxxxxxxx/ and I won't bore you all by repeating myself, except to say that this is yet another case where I wish we had a hard dependency on some way of doing checks via compiled code in our build system.
