formatting linux and mac longs as [addrpad]

[GoogleCodeExporter]

a user reported the following output on linux_proc_maps from an x86 ubuntu

http://paste.ubuntu.com/5576450/

Start      End        Flags       Pgoff Major  Minor  Inode      File Path      

---------- ---------- ------ ---------- ------ ------ ---------- 
--------------------------------------------------------------------------------
0x08048000 0x08071000 r-x           0x0      8      1    1054405 /bin/nano      

0x08071000 0x08072000 r--       0x28000      8      1    1054405 /bin/nano      

0x08072000 0x08073000 rw-       0x29000      8      1    1054405 /bin/nano      

0x09262000 0x092b6000 rw-           0x0      0      0          0 [heap]         

-0x4...000 -0x4...000 r--           0x0      8      1     659592 
/usr/lib/i386-linux-gnu/gconv/gconv-modules.cache                               
-0x4...000 -0x4...000 r--           0x0      8      1     662550 
/usr/lib/locale/locale-archive                                                  
-0x4...000 -0x4...000 rw-           0x0      0      0          0                

I think this is happening because long and unsigned long on linux/mac is 8 
bytes but the addrpad thinks it should use 4 bytes since its on an x86 profile. 

andrew initially used a mask_number() function, which we removed in 
http://code.google.com/p/volatility/source/detail?r=3090 because we thought it 
was no longer necessary. now we're wondering if there's a better fix than 
re-implementing mask_number() because then we'd have to call it anytime we try 
to use addrpad on a long/unsigned long. 

Original issue reported on code.google.com by michael.hale@gmail.com on 1 Mar 2013 at 4:38

[GoogleCodeExporter]

addrpad is specifically for using on addresses (hence the addr bit).  You can 
provide any format string in that location (so "#018x" for 8-byte addresses, # 
and 2 additional on the length limit for the 0x at the start).  If it changes 
based on the architecture then you'll have to write a little wrapper script 
based on the native_types of that profile.

It may just be eliding because of the negative sign in front of those values, 
are they signed?  Addresses aren't signed, so there's no space for it at the 
start.  I'd either make sure it's unsigned (& 0xffffffff), but that would 
potentially confuse anyone expecting a negative number, or use a custom format 
specification (there's a helper class available if necessary)...

Original comment by mike.auty@gmail.com on 1 Mar 2013 at 10:17

[GoogleCodeExporter]

Alright, we determined that going with "#018x" is a good solution for this. 

Original comment by michael.hale@gmail.com on 2 Apr 2013 at 2:39

• Changed state: Fixed