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 12:52:36 +0200 Message-ID: References: <07619925-e367-fb88-2dd8-27addb2e9052@grinta.net> <68b398b1-3790-b32f-535d-6ea2518f79b8@cs.ucla.edu> <83r27hlkix.fsf@gnu.org> <83v9wsjrru.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="21040"; 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 12:53:37 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 1hgS24-0005EK-Ak for ged-emacs-devel@m.gmane.org; Thu, 27 Jun 2019 12:53:36 +0200 Original-Received: from localhost ([::1]:48542 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hgS23-0006Lr-8a for ged-emacs-devel@m.gmane.org; Thu, 27 Jun 2019 06:53:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54454) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hgS1E-0006Jl-LJ for emacs-devel@gnu.org; Thu, 27 Jun 2019 06:52:45 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hgS1D-0005Yl-FO for emacs-devel@gnu.org; Thu, 27 Jun 2019 06:52:44 -0400 Original-Received: from quimby.gnus.org ([80.91.231.51]:33882) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hgS1D-0005XA-8H; Thu, 27 Jun 2019 06:52:43 -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 1hgS16-0004G8-TM; Thu, 27 Jun 2019 12:52:39 +0200 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAD1BMVEVhUk6XpXhDNDcsHiYQ ChAS8+0TAAACU0lEQVQ4jW1TgZHrOgiUcAqQnStAh1yAPlBARtB/TW+xc5d5f54y41haEMuyLvFe 2nescq+Kt1d54BgPL5+VIfFVHhRfy+NzXm+AWo1GT/8rIYGtdGQ8vf0POO2kKLR876WW9r4JwM9y KiD2Ad7/e9s31lo/wP5ex64yywXsd0a7I3hTwWtv7Q4sraJm3Rup1kfWf9+APO6FLoDC5ec8AeJO lfqzW8Ti34xxLJ7UmesGysw89GZ1tEfMga0gQRk/vTOOc4ulCDQ/XdRV+Qb6ICMXZp2ob7hM/7v7 GLy285vZaG6vr6xyAxXhNliGbyFjGzIUt1XQnSAj5uonAJQOAJJXkS4TAarhAXZeejYDzVihq+tC pLOojn7NvHUibPu2ZKCTTrJB31YTKDp0t1XIwnsR4YIcqN73WUchUTbwQfmb1QCD4b7xMzq4XYBI AlDAXESLERqXBPg7zTD23TkbmJuB8XXVTNlhjWgM8eREE3GlzEurfV/t4djYLCMiFU7gEAJns5gd cwkwHq4C6w1t+6uADRdFtFpoTrjkbntROjEgmeZI4JdDoaHGRM+pIrTXlDfFgiyn954cOzFuwflA 0w2ioKtxfWO1ZCLypHc477iiLgce18cIp1AC6Rp31NZ+3t8DZoDsJGd5fEXbhRTq30VMsBVPvsp4 PjB7+q5FCLaw9fK1Ypq5wymDOhqEsOVcmPiMuU52TJoOAHECCkd3ouLniAG7cgJsv9/n+w31EoDV VsQLUsHV9kZdAYxT4/TBth5LjccvoALgsqktt6E/wL+X/wHMhaYzLu0gzQAAAABJRU5ErkJggg== In-Reply-To: <83v9wsjrru.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 26 Jun 2019 18:22:13 +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:238187 Archived-At: Eli Zaretskii writes: > The commit message mentions PIPE_BUF etc., something that was > discussed, but is not in the code. I attempted to describe the rationale in the commit message, and PIPE_BUF had to be mentioned (because most people don't seem to know that there's something magical about writes below that length)... >> That's an intriguing idea. But is there a possibility that the fwrite >> would fail in such a way that we'd not get back control in such a way >> that we could guarantee that we could replace the newline with a null >> byte again? > > How would that happen? If fwrite crashes, we are going down in flames > anyway, so no one will have the opportunity to miss that null byte. > Any other failure means fwrite returns with an error code, and we then > put the null byte back as usual. It's more an instinctual reaction. :-) When there's IO, things can go wrong in ways difficult to imagine, so it's just... scary. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no