Trouble with 7bae7c8e and radsec clients causing mutex crash
hartmans at mit.edu
Thu Jul 10 15:03:46 CEST 2014
I guess a bit less opacity is in order:
> 0xb7f94702 <fr_inaddr_mask+34>: mov $0x20,%ecx
> 0xb7f94707 <fr_inaddr_mask+39>: sub %edx,%ecx
> 0xb7f94709 <fr_inaddr_mask+41>: mov $0xffffffff,%edx
0xb7f9470e <fr_inaddr_mask+46>: shl %cl,%edx
> => 0xb7f94710 <fr_inaddr_mask+48>: bswap %edx
> 0xb7f94712 <fr_inaddr_mask+50>: and (%esi),%edx
That's disassembley of the interesting part of fr_inaddr_mask. $cl
contains 32-prefix, and $edx contains the mask we're going to and
against the address.
>I'm not an expert enough in the C standard to figure out why I get a different answer when I run
>(gdb) p ~((0x00000001UL << (32 - 0)) - 1)
>$36 = 0
that's running the same expression from the C that generates the
assembley above, with 0 subsubstituted for prefix.
That will have us anding 0 with the address which is what we want.
More information about the Freeradius-Devel