From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.devel Subject: Re: `message' not outputting the newline "atomically" Date: Thu, 27 Jun 2019 13:03:17 +0200 Message-ID: References: <07619925-e367-fb88-2dd8-27addb2e9052@grinta.net> <68b398b1-3790-b32f-535d-6ea2518f79b8@cs.ucla.edu> <83pnn1lkej.fsf@gnu.org> <83tvccjrpo.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="123002"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: eggert@cs.ucla.edu, daniele@grinta.net, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Jun 27 13:15:15 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 1hgSN1-000VpH-1S for ged-emacs-devel@m.gmane.org; Thu, 27 Jun 2019 13:15:15 +0200 Original-Received: from localhost ([::1]:48682 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hgSMz-0006lq-UR for ged-emacs-devel@m.gmane.org; Thu, 27 Jun 2019 07:15:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:56537) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hgSBn-0008IM-Q6 for emacs-devel@gnu.org; Thu, 27 Jun 2019 07:03:57 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hgSBY-0007zV-Us for emacs-devel@gnu.org; Thu, 27 Jun 2019 07:03:37 -0400 Original-Received: from quimby.gnus.org ([80.91.231.51]:34168) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hgSBY-0007y0-NT; Thu, 27 Jun 2019 07:03:24 -0400 Original-Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=stories) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hgSBS-0004La-3Y; Thu, 27 Jun 2019 13:03:20 +0200 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAJFBMVEUzW6g+a7bj2c1DUHXX zMAsISEvWaicnalYdKju69o6ZK0NBQMYayvVAAACSUlEQVQ4jZ1Sv2vbQBR+WW7w1CPYGG1VFUy2 CkU40O2qIEKWUiESyGIoyJkthVPJZFqqa0djMLfJDXjQWJPJ/1zfO0mW3dKlH/p13/fe934gSFoM 8J4AS5g5MXiQeTJ5kIyRgArUAkCiijyfWvNvm+QQmKuUlFP5kx0LCVQoqKkqjjIAwTm3fpyoweBP QfEGg5ZlDCv0IJ/X/KaLZniXkKs5SVbXjlFYbWWVnX05MZNg8aqEalNPjQWqCmczggVgODahcat1 VZXMzEERdTL0qoqMK9Z0TOEJsTWPHo2AKHuw5nuUSY8Ta2KrZ7fl0b03RN7Q3Hp3O28VC7ORrj36 u1+vOW/9lNxbD7aX+wxeXGswH2Yp/JBHYa74sIslDDONwjAvlPqb11CEhUQB+MmnVy5/PuWnxXe9 0iu4fDNW6OTzD17f5X7f9ccfrx/1FdzdjO++cH6/3kZ91436b/3o9rOnnyDyva3veb4XeTWi2Bt7 MgWsc64XThAEwiboBmC3OF/Q2bYpBtEIzYnQZEFM8NsCiLgG7P6B/xDkMVKcQaap50FInWQyyIIQ ry4CgkOMTFQQGEEIx6FL2MJe4kEIFMMQmk0sBL2X9CnMtK1gHwg2+dU1RCMsSHhvFmBWEgn7AGnX lcAlzgK77kiM6u1Swko42UxmmZT4A4jRMm5W8uJ/dTKRFTKX4YWchct75AAf0WPkZGiUZQ4OL0L9 tHuJwEer1J9Rlw49bDvUN8iZjCC9wHYDxzTthPoqjreAhbwFlqBNkCBQOEPhN9BGbrQ4f8T3AAAA AElFTkSuQmCC In-Reply-To: <83tvccjrpo.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 26 Jun 2019 18:23:31 +0300") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 80.91.231.51 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:238188 Archived-At: Eli Zaretskii writes: > Sorry, I've probably misunderstood what was being discussed. I thought > you were talking about the conversion itself. The target string is of > course created via xmalloc. B ut that could hardly infloop. So, that function is a function that will commonly already call xmalloc, so adding another one doesn't substantially change the guarantees or behaviour of that function, which was my point (because that's the `message' path). However, as Paul points out, there are other uses of stderr, which are indeed low-level error reporting paths -- but they never call the function I modified. Paul wants these to also not interleave in a multi-process environment, and I think that's a nice goal to have, but I think we're into somewhat theoretical areas there. The practical problems with interleaving (that is, the only ones I see with any regularity) are the ones that stems from using `message' in a batch Emacs, and the other uses of stderr aren't problems in practice. (Because they're only used for errors that "shouldn't happen".) But I'm all for fixing those things if that can be done in a way that doesn't break anything, and then (of course) the `message' path could also use that machinery. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no