From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13056 invoked by alias); 18 Jul 2014 11:23:36 -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 13044 invoked by uid 89); 18 Jul 2014 11:23:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-vc0-f171.google.com Received: from mail-vc0-f171.google.com (HELO mail-vc0-f171.google.com) (209.85.220.171) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 18 Jul 2014 11:23:33 +0000 Received: by mail-vc0-f171.google.com with SMTP id hq11so5538030vcb.16 for ; Fri, 18 Jul 2014 04:23:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=k+sZJ3LamO7j7UAsG1rki59WyPCWAmnFgjTsMwZDK30=; b=NETuWraSVO0PgwbFLjGeogTmb49fo7ha0TQ2i8GnPVEtcIGSyjkVdCMA5O178VwvZh sofZcort7FSFNm6jRXbN11vS7jWyndxP+Ynq0uIHHSYp9fLDe01Yag1+W8fjX8lLMwAK HYERPKmRWl78d/8rs4mZ/1YzQuvn7ZzbLkpnfhu2VNbQXHQFiNy6A+qX4UgDpnN5f8SA NLF5y2QYXx1IBvkZsHo3BC1og5qcYM+83eEHAX1SVCSubltYak7wKIIq2i8ooaAnIJua c65zyix22cLBeYmdSISmWsRHz0bQH6NppElovFc+07vPpDq7s5saHN8UK8bCbsrwKrH+ fFSA== X-Gm-Message-State: ALoCoQmcQkXicThg5b/dDuZCnC7HfE+PH6znsEUHTNhHrI/clGZmSODHC5OdBI0qqk4jUg3EKMPH MIME-Version: 1.0 X-Received: by 10.52.243.135 with SMTP id wy7mr3858012vdc.82.1405682611851; Fri, 18 Jul 2014 04:23:31 -0700 (PDT) Received: by 10.52.28.233 with HTTP; Fri, 18 Jul 2014 04:23:31 -0700 (PDT) In-Reply-To: <20140718104447.GA21385@blade.nx> References: <1405520243-17282-1-git-send-email-gbenson@redhat.com> <1405520243-17282-2-git-send-email-gbenson@redhat.com> <20140717134728.GB31916@blade.nx> <53C7E6AB.4080703@redhat.com> <20140717153957.GA1921@blade.nx> <53C7F5D6.6060102@redhat.com> <20140718090630.GA17917@blade.nx> <20140718104447.GA21385@blade.nx> Date: Fri, 18 Jul 2014 12:31:00 -0000 Message-ID: Subject: Re: [PATCH 01/15 v3] Introduce common/errors.h From: Doug Evans To: Gary Benson Cc: Pedro Alves , gdb-patches , Tom Tromey Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-07/txt/msg00494.txt.bz2 On Fri, Jul 18, 2014 at 11:44 AM, Gary Benson wrote: > Doug Evans wrote: >> On Fri, Jul 18, 2014 at 10:06 AM, Gary Benson wrote: >> > [...] >> > /* Throw a fatal error, constructing the message using a printf-style >> > format string and a printf- or vprintf-style argument list. This >> > function does not return. The application will exit. */ >> > >> > extern void fatal (const char *fmt, ...) >> > ATTRIBUTE_NORETURN ATTRIBUTE_PRINTF (1, 2); >> > >> > extern void vfatal (const char *fmt, va_list args) >> > ATTRIBUTE_NORETURN ATTRIBUTE_PRINTF (1, 0); >> > [...] >> >> Remember gdb doesn't exit on fatal(). >> fatal() in gdb is essentially ^c (quit() calls fatal()!). >> >> Can I repeat my request to please document this in the function >> comment. > > I wanted to avoid putting implementation details here, I realize that. > but I see this > isn't going to happen. Is the attached ok? I'm trying to not impose on you too much churn and back-and-forth in what is clearly a stepping stone. Eventually I think fatal needs to disappear from the gdb side (renamed or whatever). Until that happens (i.e., *if* you just want to keep the patch basically as is), then at the least I don't want to lie to the reader, and I want to make the reader aware of the issue. That's the high order bit for me as far as "fatal" goes (within the context of trying to keep the patch basically as is). If you want to take on the task of getting this 100% correct in this pass (or at least within some fraction thereof :-)), then we can take a different route. Your choice IMO. [And I mean that sincerely - I *am* trying to help you make progress here without being too pedantic.] > /* Throw a fatal error, constructing the message using a printf-style > format string and a printf- or vprintf-style argument list. This > function does not return. Fatal errors cause GDB to return to the > command level. Fatal errors cause gdbserver to exit. */ > > extern void fatal (const char *fmt, ...) > ATTRIBUTE_NORETURN ATTRIBUTE_PRINTF (1, 2); > > extern void vfatal (const char *fmt, va_list args) > ATTRIBUTE_NORETURN ATTRIBUTE_PRINTF (1, 0); I would tweak that a little, and instead just point out that gdb's usage of the name "fatal" is broken. I don't care too much about the wording, I just want to make sure we don't lie to the reader and make the reader aware of the issue. /* Throw a fatal error, constructing the message using a printf-style format string and a printf- or vprintf-style argument list. This function does not return. Fatal errors cause the app to exit, except in the case of gdb where it just throws a RETURN_QUIT exception. */