From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: `message' not outputting the newline "atomically" Date: Wed, 03 Jul 2019 12:30:06 +0300 Message-ID: <831rz7cvoh.fsf@gnu.org> References: <07619925-e367-fb88-2dd8-27addb2e9052@grinta.net> <68b398b1-3790-b32f-535d-6ea2518f79b8@cs.ucla.edu> <83pnn1lkej.fsf@gnu.org> <83tvccjrpo.fsf@gnu.org> <83zhm3i285.fsf@gnu.org> <7a39d680-6234-1301-74e5-62d599f500f6@cs.ucla.edu> <838stfd0pp.fsf@gnu.org> <835zojd0fx.fsf@gnu.org> <834l43czz8.fsf@gnu.org> <5c979663-9ded-4273-11d1-483345053a6f@cs.ucla.edu> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="216983"; mail-complaints-to="usenet@blaine.gmane.org" Cc: larsi@gnus.org, daniele@grinta.net, emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jul 03 11:33:53 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hibeC-000uHu-3s for ged-emacs-devel@m.gmane.org; Wed, 03 Jul 2019 11:33:52 +0200 Original-Received: from localhost ([::1]:34242 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hibeA-0000om-KV for ged-emacs-devel@m.gmane.org; Wed, 03 Jul 2019 05:33:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37248) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hibap-0000Ym-L9 for emacs-devel@gnu.org; Wed, 03 Jul 2019 05:30:25 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:37451) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hiban-0002zi-U8; Wed, 03 Jul 2019 05:30:21 -0400 Original-Received: from [176.228.60.248] (port=2924 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hibal-0002Vd-2z; Wed, 03 Jul 2019 05:30:19 -0400 In-reply-to: <5c979663-9ded-4273-11d1-483345053a6f@cs.ucla.edu> (message from Paul Eggert on Wed, 3 Jul 2019 01:45:51 -0700) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:238320 Archived-At: > Cc: larsi@gnus.org, daniele@grinta.net, emacs-devel@gnu.org > From: Paul Eggert > Date: Wed, 3 Jul 2019 01:45:51 -0700 > > Eli Zaretskii wrote: > > I want all our diagnostic/debug messages to go outside without > > buffering as much as possible. > > To do that we would have to outlaw plain fprintf too, as it buffers on GNU/Linux > and most other platforms. For example: > > char *p = "hello"; > char *q = (char *) 1; > fprintf (stderr, "p=%s q=%s\n", p, q); > > This dumps core on GNU/Linux without producing any output. This dumps core because the invalid pointer is dereferenced before fprintf is called, right? If so, this is not relevant to the issue at hand; just because there's a call to fprintf somewhere near the crash locus doesn't yet mean there's a problem with that fprintf. I said "as much as possible", and I meant that. I don't see any reasons to outlaw fprintf, just because some platforms buffer stderr, or because Emacs might crash without even starting to print anything, that'd be too unreasonable. But I don't want us to invent a whole new family of functions just to avoid fprintf, like your patch did. > I know you prefer unbuffered stderr for debugging, so here's a simple > compromise: let's leave stderr unbuffered if ENABLE_DEBUG is defined. Sorry, no: these messages are important in production builds as well (those which aren't should be under some DEBUG cpp conditional already). Even out of people who track the master branch there seem to be a fair amount of those who don't build with --enable-checking. > > Whoa! Is it really worth all that? Including exposing this to Lisp? > > I thought it was worth it, or I wouldn't have written the patches. 'message' is > not the only place where Emacs issues diagnostics that can interleave, and it > shouldn't be hard to fix the other places. What other places are those? Let's discuss them one by one, please.