From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19871 invoked by alias); 17 Sep 2011 01:23:06 -0000 Received: (qmail 19859 invoked by uid 22791); 17 Sep 2011 01:23:05 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-yx0-f169.google.com (HELO mail-yx0-f169.google.com) (209.85.213.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 17 Sep 2011 01:22:49 +0000 Received: by yxi19 with SMTP id 19so3889936yxi.0 for ; Fri, 16 Sep 2011 18:22:48 -0700 (PDT) MIME-Version: 1.0 Received: by 10.236.145.10 with SMTP id o10mr191706yhj.90.1316222568764; Fri, 16 Sep 2011 18:22:48 -0700 (PDT) Received: by 10.236.201.33 with HTTP; Fri, 16 Sep 2011 18:22:48 -0700 (PDT) In-Reply-To: <4E73F1A4.2020606@barfooze.de> References: <4E73D06F.603@barfooze.de> <201109170000.43306.pedro@codesourcery.com> <4E73D806.2040302@barfooze.de> <201109170130.42276.pedro@codesourcery.com> <4E73F1A4.2020606@barfooze.de> Date: Sat, 17 Sep 2011 02:29:00 -0000 Message-ID: Subject: Re: wrong assumptions about pthread_t being numeric From: Matt Rice To: John Spencer Cc: gdb-patches@sourceware.org, Pedro Alves Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-09/txt/msg00334.txt.bz2 On Fri, Sep 16, 2011 at 6:02 PM, John Spencer wrote: > On 09/17/2011 02:30 AM, Pedro Alves wrote: >> >> On Saturday 17 September 2011 00:13:10, John Spencer wrote: >>> >>> On 09/17/2011 01:00 AM, Pedro Alves wrote: >>>> >>>> These are only built natively on solaris and aix respectively, so >>>> let's just leave them alone. >>>> >>> I expected it to be desirable for a product in industrial use to be >>> standard-compliant and not invoking undefined behavior. >> >> Those files are tied to those platforms' thread_db/libc implementations. >> There's absolutely no need to handle some other hipotetical libc that >> defines pthread_t diferently there. =A0If it appears, we'll handle it. > >> Chances are, some other changes would be necessary to make it really >> work, not just build. >> > > exactly. for example in musl's case it is wrong to compare the underlying > type (which is a struct pointer) with 0. FWIW, hurd used to do something similar (well, in its case 0 was a valid, pthread_t, the first one in fact), I believe that enough things broke gthr from gcc, libobjc, possibly gdb (don't remember it though..) that they eventually changed their pthread_t even though it was compliant...