Re: [nmap-svn] r34034 - nmap

[jah <jah () zadkiel plus com>]

On 20/02/2015 15:33, Daniel Miller wrote:
> On Fri, Feb 20, 2015 at 8:27 AM, jah <jah () zadkiel plus com <mailto:jah () zadkiel plus com>> wrote:
>
>
>     I'm seeing strange differences between the string representation of a coroutine on windows and linux, e.g.:-
>
>     win: "thread: 02D6E640"
>     lin "thread: 0x1e7c050"
>
>     Linux prefixes the ID with "0x" and the unprefixed ID is usually 7 (but sometimes 6) lower case hex chars. The 
> last char is invariably "0".
>     Windows doesn't prefix the ID, it's invariably 8 upper case hex chars and the last char is either "0" or "8".
>
>
> This is because the tostring method for threads is defined internally with a call to sprintf(3) using a "%p" format 
> string. POSIX [1] states that this format specifier converts a pointer to "a sequence of printable characters, in an 
> implementation-defined manner." No guarantee these are hex chars at all, though that's a popular convention. GLIBC's 
> man page [2] says, "The void * pointer argument is printed in hexadecimal (as if by %#x or %#lx)." MSDN [3] says that 
> %p "Displays the argument as an address in hexadecimal digits."
>  
>
>     Leaving aside the length and low byte weirdness, the attached patch will deal with the prefix and case 
> differences.
>
>
> I'm not sure such a patch is needed. These strings are not output in the XML, which is where we would require 
> identical canonical output for machine-parsing purposes. Normal output can vary based on locale and other factors. 
> The only real requirement here is that these ID numbers be unique within a running Nmap process (and that may not 
> even be the case entirely: depending on garbage collection, an address may be reused after the thread is done). Can 
> you give an example of why the presentation of the thread IDs should be unified from platform to platform?
>
> Dan
>
> [1] http://pubs.opengroup.org/onlinepubs/9699919799/functions/fprintf.html
> [2] http://linux.die.net/man/3/sprintf
> [3] https://msdn.microsoft.com/en-us/library/hf4y5e3w.aspx

Currently the pattern used to capture the interesting part of the thread id, for the thread.info property, does not 
match on windows: the result is thread.info contains "M:nil" (or "W:nil" for a worker_thread).
This patch fixes that (and so makes consistent the captured part of the string representation of a coroutine).  Making 
thread.info consistent seems entirely reasonable, but the main thing is to correct the defect.

jah

_______________________________________________
Sent through the dev mailing list
https://nmap.org/mailman/listinfo/dev
Archived at http://seclists.org/nmap-dev/