Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 7 Jul 2012 23:44:07 +0200
From: Frank Dittrich <>
Subject: Re: Build error for generic

On 07/07/2012 06:00 PM, jfoug wrote:
>> From: Frank Dittrich []
>> Now that this has arrived in magnum-jumbo, building generic on my 32bit
>> Linux system fails:
> I have changed the macro, from using the uintptr_t to using ARCH_WORD.   I
> am pretty sure this will be adequate, since we are already properly (I hope)
> using the proper machine sized int for ARCH_WORD.  The proper machine sized
> int was what uintptr_t was supposed to be.

With just the common.h change applied, generic build works again.
gcc 4.6.3 just produces two new warnings:
sha2.c: In function ‘sha256_final’:
sha2.c:240:2: warning: suggest parentheses around comparison in operand
of ‘&’ [-Wparentheses]
sha2.c: In function ‘sha512_final’:
sha2.c:564:2: warning: suggest parentheses around comparison in operand
of ‘&’ [-Wparentheses]

Line 240 is the same as line 564:
	if (is_aligned(output,sizeof(ARCH_WORD_32))) {

is_aligned is defined in line 26 of common.h:
#define is_aligned(PTR, CNT) (((ARCH_WORD)(const void *)(PTR))&(CNT-1)==0)

With your common.h patch applied I get:

$ md5sum ../run/john
fda225c12f885de488ba1a9dbbf9f547  ../run/john

$ md5sum sha2.o
1f13dd90240316f69efb2b96d3cda1bc  sha2.o

I am sure you must have meant
#define is_aligned(PTR, CNT) ((((ARCH_WORD)(const void *)(PTR))&(CNT-1))==0)

But if I change common.h that way, remove sha2.o, and
make generic again, I get:

$ md5sum ../run/john
5eac3b277c908a4caadcf8095be1d708  ../run/john

$ md5sum sha2.o
19c76d0c62d06fe0ab66eeafefacc4eb  sha2.o

After a make clean generic, I get
$ md5sum ../run/john
b4d06ed3712d184b7b464275a8f7f2e4  ../run/john

$ md5sum sha2.o
19c76d0c62d06fe0ab66eeafefacc4eb  sha2.o

Even though sha2.o remains unchanged and sha2.c is currently the only .c
file using is_aligned, the resulting binary changed!

Only when I change the #define to
#define is_aligned(PTR, CNT) (((ARCH_WORD)(const void *)(PTR))&((CNT-1)==0))
I do get the same sha2.o file as with your original patch:

$ md5sum sha2.o
1f13dd90240316f69efb2b96d3cda1bc  sha2.o

But the resulting binary is different from the first one:

$ md5sum ../run/john
f44bbfd159c0198538b1a61c3b78239d  ../run/john

I love reproducible results.
No wonder I got totally confused when at first I tried to compare just
the ../run/john binaries.

Looking at the operator precedence of & vs. ==, this should have ben
I am, however, quite sure this is not what you meant.
But may be I am confused.

Needless to say, the resulting john binaries all passed --test=0 runs,
no matter which way I changed the #define.

> I also changed code in the non-aligned CPU part of memory.c (in the
> non-aligned CPU's alter endianity), to use the is_aligned macro.   This
> should help any problems show up faster.

Here you had a typo:

$ make generic > /dev/null
memory.c: In function ‘alter_endianity_w’:
memory.c:229:2: warning: implicit declaration of function ‘isaligned’
memory.o: In function `alter_endianity_w':
memory.c:(.text+0x6aa): undefined reference to `isaligned'
collect2: ld returned 1 exit status
make[1]: *** [../run/john] Error 1
make: *** [generic] Error 2

This should have been is_aligned instead of isaligned.

After fixing this, john can be built and passes --test=0.


Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.