Re: [nmap-svn] r34034 - nmap

[Daniel Miller <bonsaiviking () gmail com>]

On Fri, Feb 20, 2015 at 10:17 AM, jah <jah () zadkiel plus com> wrote:

>  On 20/02/2015 15:33, Daniel Miller wrote:
>
> On Fri, Feb 20, 2015 at 8:27 AM, jah <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,

Sorry for the late reply. I see what you are saying. Do you think that we
could just tweak the pattern instead of adding the function, though? I'm
thinking something like this:

 info = format("%s M:%s", self.id, match(tostring(co), "^thread:
0?[xX]?(.*)"))

This clarifies the format that we expect tostring(co) to return, strips any
leading 0x (lower or uppercase) and then captures the rest of the ID.
Regardless, you can go ahead and commit either this or your second patch,
since we've solved the problem with the original one.

Dan

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