From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23452 invoked by alias); 3 Oct 2011 20:05:35 -0000 Received: (qmail 23440 invoked by uid 22791); 3 Oct 2011 20:05:34 -0000 X-SWARE-Spam-Status: No, hits=-7.2 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 03 Oct 2011 20:05:21 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p93K5Bhr015961 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 3 Oct 2011 16:05:11 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id p93K5A6t027516; Mon, 3 Oct 2011 16:05:11 -0400 Received: from barimba (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id p93K59xt024038; Mon, 3 Oct 2011 16:05:09 -0400 From: Tom Tromey To: John Spencer Cc: gdb-patches@sourceware.org Subject: Re: [RFC] Crash sourcing Python script on Windows References: <1317251996-12146-1-git-send-email-brobecker@adacore.com> <09787EF419216C41A903FD14EE5506DD03098D555B@AUSX7MCPC103.AMER.DELL.COM> <4E83D440.6000702@barfooze.de> Date: Mon, 03 Oct 2011 20:05:00 -0000 In-Reply-To: <4E83D440.6000702@barfooze.de> (John Spencer's message of "Thu, 29 Sep 2011 04:13:20 +0200") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain 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-10/txt/msg00046.txt.bz2 >>>>> "John" == John Spencer writes: John> FILE is supposed to be an opaque type and as such noone except of the John> libc which defines it is supposed to "poke" at its internals. Which is exactly what GDB does. John> however it is common practice in GNU software to assume everybody uses John> GLIBC and poke around in internal stuff thats not supposed to be John> accessibly at all in userland. another example of such illegal John> behaviour is libevent, which does illegal things with fd_set internals John> to allow more than FD_SETSIZE file descriptors to be used with John> select(). I don't even know what libevent is. It isn't part of gdb. I'm guessing you are referring back to the libthread_db discussion. If so, please separate the streams. Thanks. Tom