From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30324 invoked by alias); 3 Dec 2004 21:48:19 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 30296 invoked from network); 3 Dec 2004 21:48:14 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 3 Dec 2004 21:48:14 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id iB3LmEL0015341 for ; Fri, 3 Dec 2004 16:48:14 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id iB3LmEr20596; Fri, 3 Dec 2004 16:48:14 -0500 Received: from redhat.com (dhcp-172-16-25-137.sfbay.redhat.com [172.16.25.137]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id iB3LmCso022965; Fri, 3 Dec 2004 16:48:12 -0500 Message-ID: <41B0DF1C.2080800@redhat.com> Date: Fri, 03 Dec 2004 21:54:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.3) Gecko/20040924 MIME-Version: 1.0 To: Jim Blandy CC: gdb-patches@sources.redhat.com Subject: Re: RFA: remote.c: parse thread ID's as unsigned values References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-12/txt/msg00087.txt.bz2 Jim Blandy wrote: > One month ping. Well heck, I'm not the remote.c maintainer, but I'm the thread maintainer (or one of them). Your change certainly seems reasonable to me. Can't think why we would want thread ids to be sign extended... Under the assumption that you've run into a situation where this is applicable, and the change tests out well, I'll give it the nod. Michael > > Jim Blandy writes: > > >>The GDB manual isn't clear on whether thread ID's carried in the >>responses to the qfThreadInfo and the qC packet may have a sign; I'm >>assuming that they're just a series of hex digits. >> >>2004-10-27 Jim Blandy >> >> * remote.c (remote_threads_info, remote_current_thread): Use >> strtoul to parse thread ID numbers. >> >>Index: gdb/remote.c >>=================================================================== >>RCS file: /cvs/src/src/gdb/remote.c,v >>retrieving revision 1.134 >>diff -c -r1.134 remote.c >>*** gdb/remote.c 26 Apr 2004 09:02:41 -0000 1.134 >>--- gdb/remote.c 27 Oct 2004 21:26:40 -0000 >>*************** >>*** 1755,1761 **** >> putpkt ("qC"); >> getpkt (buf, (rs->remote_packet_size), 0); >> if (buf[0] == 'Q' && buf[1] == 'C') >>! return pid_to_ptid (strtol (&buf[2], NULL, 16)); >> else >> return oldpid; >> } >>--- 1755,1766 ---- >> putpkt ("qC"); >> getpkt (buf, (rs->remote_packet_size), 0); >> if (buf[0] == 'Q' && buf[1] == 'C') >>! /* Use strtoul here, so we'll correctly parse values whose highest >>! bit is set. The protocol carries them as a simple series of >>! hex digits; in the absence of a sign, strtol will see such >>! values as positive numbers out of range for signed 'long', and >>! return LONG_MAX to indicate an overflow. */ >>! return pid_to_ptid (strtoul (&buf[2], NULL, 16)); >> else >> return oldpid; >> } >>*************** >>*** 1802,1808 **** >> { >> do >> { >>! tid = strtol (bufp, &bufp, 16); >> if (tid != 0 && !in_thread_list (pid_to_ptid (tid))) >> add_thread (pid_to_ptid (tid)); >> } >>--- 1807,1819 ---- >> { >> do >> { >>! /* Use strtoul here, so we'll correctly parse values >>! whose highest bit is set. The protocol carries >>! them as a simple series of hex digits; in the >>! absence of a sign, strtol will see such values as >>! positive numbers out of range for signed 'long', >>! and return LONG_MAX to indicate an overflow. */ >>! tid = strtoul (bufp, &bufp, 16); >> if (tid != 0 && !in_thread_list (pid_to_ptid (tid))) >> add_thread (pid_to_ptid (tid)); >> } > > >