Nmap Development mailing list archives
Re: [nmap-svn] r34034 - nmap
From: Daniel Miller <bonsaiviking () gmail com>
Date: Wed, 25 Feb 2015 14:13:32 -0600
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/
Current thread:
- Re: [nmap-svn] r34034 - nmap Daniel Miller (Feb 19)
- Re: [nmap-svn] r34034 - nmap jah (Feb 20)
- Message not available
- Re: [nmap-svn] r34034 - nmap jah (Feb 20)
- Re: [nmap-svn] r34034 - nmap Daniel Miller (Feb 25)
- Message not available
- Re: [nmap-svn] r34034 - nmap jah (Feb 20)