From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15457 invoked by alias); 25 Jul 2014 08:51:41 -0000 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 Received: (qmail 15440 invoked by uid 89); 25 Jul 2014 08:51:41 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 25 Jul 2014 08:51:39 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s6P8paja024845 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 25 Jul 2014 04:51:36 -0400 Received: from blade.nx (ovpn-116-66.ams2.redhat.com [10.36.116.66]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s6P8pZAW006908; Fri, 25 Jul 2014 04:51:36 -0400 Received: by blade.nx (Postfix, from userid 1000) id 06CE72640C8; Fri, 25 Jul 2014 09:51:34 +0100 (BST) Date: Fri, 25 Jul 2014 09:34:00 -0000 From: Gary Benson To: Doug Evans Cc: gdb-patches@sourceware.org, Pedro Alves , Tom Tromey Subject: Re: [PATCH 1/3 v4] Introduce common/errors.h Message-ID: <20140725085134.GB4812@blade.nx> References: <1406206287-6817-1-git-send-email-gbenson@redhat.com> <1406206287-6817-2-git-send-email-gbenson@redhat.com> <21457.17973.551020.113918@ruffy.mtv.corp.google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <21457.17973.551020.113918@ruffy.mtv.corp.google.com> X-IsSubscribed: yes X-SW-Source: 2014-07/txt/msg00658.txt.bz2 Doug Evans wrote: > ...it's odd to then not have just one copy of perror_with_name and > malloc_failure given that their function comment says: > > perror_with_name: > /* A special case of "error" which constructs the error message by ... > > and > > malloc_failure: > /* A special case of internal error used to handle memory allocation ... > > When I read "special case of ..." the first thing that comes to mind > is that the function is a utility wrapper around the corresponding > function, and given that it's not I'm left wondering "Why not?". [snip] > So, *if* you want to keep *this* part of the patch basically as-is > (which is fine by me) I would rephrase this comment to something > like: > > /* Call this function to handle memory allocation failures. > This function does not return. */ > > I don't have too strong opinion on the wording. If someone wants a > different wording, go for it. I pretty much agree with you 100% here. I wasn't happy with the comments for either of these, and I'll gladly change them. > In the case of malloc_failure, it's not really an *internal* error, No--and certainly not by the description of internal_error earlier in the file. > even if in the case of gdb it calls internal_error, though arguably > it should do something different - it's more of a "fatal". :-) > Though I'm not suggesting trying to go down that path. :-) I spoke with Pedro about this in Cambridge. malloc failure is a funny one: sometimes it's fatal, other times it's not an issue; it depends entirely on what the memory you were trying to allocate was for. > It might be possible come up with a name other than "fatal" that > could apply to both gdb and gdbserver so that malloc_failure could > call it, but no need to try to do that now. I don't know if you saw but I removed "fatal" from GDB the other day (http://tinyurl.com/k6neuwd) so the path is clear to add a "fatal" if we want one. It would be nice if such a function were smart enough to work even if called before exceptions and cleanups were set up. It might be a nice general thing if all error-handling functions worked that way (error and internal_error could work like gdbserver's "fatal" if called early.) That might even be a prerequisite to moving exceptions and cleanups into common code and making gdbserver use them. (I'm not planning to do any of this now, this is just thinking aloud!) Cheers, Gary -- http://gbenson.net/