Re: [PATCH] block-sha1: Windows declares ntohl() in winsock2.h

From: Brandon Casey <brandon.casey.ctr@nrlssc.navy.mil>
Date: Aug 18, 2009, 19:56 UTC
Message-ID: <XJM0H8pTiCJpryS-arPltHCHwsm0djqVixaH1NwBqT2pci2MA9karw@cipher.nrlssc.navy.mil>
In-Reply-To: <7vk511dk11.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:

> Another issue, especially with your "openssl sha1 removal" patch, is if we
> can assume gcc everywhere.  As far as I can tell, block-sha1/sha1.c will
> be the first unconditional use of inline asm or statement expression on
> i386/amd64.  Are folks on Solaris and other platforms Ok with this?

The SUNWspro compiler doesn't set __i386__. Instead it sets __i386, and I think __x86_64 and __amd64 where appropriate. So, compilation with the SUNWspro compiler on x86 is currently unaffected by these changes and falls back to the generic routines.

It seems that v5.10 of the compiler can grok both the __asm__ statements and the ({...}) naked block notation and passes all of the tests when the block_sha1 code is modified to add defined(__i386) to each of the macro statements.

The 5.8 version cannot grok the naked block, and requires spelling __asm__ as __asm for inline assembly. Even then it appears that there is a bug in the assembly that is produced (a google search told me so), so the assembly code does not successfully compile.

I haven't had much time to think about how or whether to address this.

Adding something like the following would get ugly real quick:

   (defined(__i386) && defined(__SUNPRO_C) && (__SUNPRO_C >= 0x5100))

For now, the code compiles fine using the SUNWspro compiler on x86 even if it is suboptimal compared to gcc. It is still an improvement over the mozilla code.

-brandon