From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Daniele Nicolodi Newsgroups: gmane.emacs.devel Subject: Re: `message' not outputting the newline "atomically" Date: Wed, 26 Jun 2019 13:36:54 -0600 Message-ID: References: <07619925-e367-fb88-2dd8-27addb2e9052@grinta.net> <68b398b1-3790-b32f-535d-6ea2518f79b8@cs.ucla.edu> <83r27hlkix.fsf@gnu.org> <1d550142-8d66-485b-6796-981351718b53@cs.ucla.edu> <83blykjijy.fsf@gnu.org> <65c60a70-311d-bf9f-b509-d3dd80ddc511@cs.ucla.edu> <83a7e4jh5d.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="208004"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.7.2 Cc: larsi@gnus.org, emacs-devel@gnu.org To: Eli Zaretskii , Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jun 26 21:38:10 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 1hgDk7-000rtb-6y for ged-emacs-devel@m.gmane.org; Wed, 26 Jun 2019 21:38:07 +0200 Original-Received: from localhost ([::1]:44562 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hgDk6-00060Y-5U for ged-emacs-devel@m.gmane.org; Wed, 26 Jun 2019 15:38:06 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57816) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hgDjP-00060N-8u for emacs-devel@gnu.org; Wed, 26 Jun 2019 15:37:24 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hgDjO-00082b-14 for emacs-devel@gnu.org; Wed, 26 Jun 2019 15:37:23 -0400 Original-Received: from zed.grinta.net ([109.74.203.128]:33104) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hgDjI-0007ne-Sx; Wed, 26 Jun 2019 15:37:17 -0400 Original-Received: from black.hsd1.co.comcast.net (c-98-245-163-4.hsd1.co.comcast.net [98.245.163.4]) (Authenticated sender: daniele) by zed.grinta.net (Postfix) with ESMTPSA id 49341E0E4F; Wed, 26 Jun 2019 19:36:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=grinta.net; s=mail; t=1561577817; bh=1y9e9cuqPIbN/3oUQamZAyau2xpLVnVnBghNrs5e9E0=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=etaN15xdwY6/dHRDys/Gc03Rvi/CJ2aqp0xe+NBo7zhEf3cps1aTd7sjQRrO9zd1e fDuhONEYlbPf7GDxddPyK84SDywRTQhR4eO2HPtEwiStsP5XGkCj6C9vyY94yZjE2C C+sz1SV/fl6Wffu8PEdaiQf07uSmbeQZGOn/WHEo= Openpgp: preference=signencrypt In-Reply-To: <83a7e4jh5d.fsf@gnu.org> Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 109.74.203.128 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:238179 Archived-At: Not that I care much about this, I feel that defending the use case of debugging Emacs through printf() statements is rooted in believes akin to religious ones, and religious arguments cannot be won with logic. However, people keeps putting me in Cc so... On 26/06/2019 13:11, Eli Zaretskii wrote: >> Cc: larsi@gnus.org, daniele@grinta.net, emacs-devel@gnu.org >> From: Paul Eggert >> Date: Wed, 26 Jun 2019 11:58:26 -0700 >> >> Emacs contains many fprintf calls like this: >> >> fprintf (stderr, "Using %s\n", term); >> >> Here, TERM is typically a short string. On AIX and Solaris, this fprintf is >> implemented via three 'write' syscalls - one for "Using ", one for the contents >> of TERM, and one for "\n". These outputs will be broken up and hard-to-read on >> AIX and Solaris, if Emacs runs in parallel with other programs also generating >> stderr output. Using line-buffering fixes this. > > Can't we also fix that by replacing the above with 'sprintf' followed > by 'write'? Why is re-implementing line buffering in Emacs any better than using libc line buffering? For your main argument in the thread, we would be loosing crucial debug information if something goes irreparably wrong between the string preparation and the write(). And given how error-prone is string manipulation in C, there are much higher chances that this will happen if we start doing that for every function that want to print something on stderr. > Or some other similar solution? Any solution requires buffering of the output till the first newline. And you are opposed to buffering. Are you proposing that we selectively apply buffering in some occasions but not others? I am looking forward to the discussion to decide which functions should use home-grown buffering and which ones should no... However, if that is the route you are suggesting, it is much easier to enable line buffering unconditionally ad place fflush() calls where it matters, than the other way around. Cheers, Dan