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: Mon, 24 Jun 2019 23:33:06 +0200 Message-ID: References: <07619925-e367-fb88-2dd8-27addb2e9052@grinta.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="52986"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: Daniele Nicolodi , emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 24 23:33:40 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 1hfWao-000Dga-Fn for ged-emacs-devel@m.gmane.org; Mon, 24 Jun 2019 23:33:38 +0200 Original-Received: from localhost ([::1]:54796 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hfWam-0001XF-Qx for ged-emacs-devel@m.gmane.org; Mon, 24 Jun 2019 17:33:36 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49084) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hfWaP-0001X8-De for emacs-devel@gnu.org; Mon, 24 Jun 2019 17:33:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hfWaO-0001Td-8e for emacs-devel@gnu.org; Mon, 24 Jun 2019 17:33:13 -0400 Original-Received: from quimby.gnus.org ([80.91.231.51]:45298) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1hfWaO-0001RS-1R for emacs-devel@gnu.org; Mon, 24 Jun 2019 17:33:12 -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 1hfWaJ-0007wk-1K; Mon, 24 Jun 2019 23:33:09 +0200 Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAGFBMVEUICAsFBQUDAwMBAQEM Cw8GBghWRxsEBAR3g1qzAAACEklEQVQ4jV2UMW/jMAyFOdjZ1YPqORIC7dYBXV3UyK0y7tSuLuBw l4Oe/n5Jyo6FKkaQ5DOf+KjnwJv3xiSlAaAZqwV3731PJO5gAGj5KsARiQGA7oxtjC2BXwxsToqI prIoqy3AWuOyUmrSMdK72kFvDImpsiZ60YYD/CWQ7ZNhMVlcFcMo4Hz3Jo9Ia2Ed3kuAP38Y40qv U8ekJSnpSpuLIy29NaC5c/Zhef+cOpVUN5V+ASwBbxgolbqko5B2A1KRs0pJNn9UWGMLoBpuV8Bd pAwDdtFFBjAMRcoRcOxQTwwCNAJ6IxXFeqloRga/8XbCK34qth5wQaT5M6Cv+Hpa/r3idaFrxLmA Hv8vmJ9v7zekC29ABRV4nxnMiHODcpIMSKE9bRXXecSBTh/I3jPOV8TPUkGfcBgFcLtJ8wm14QgR g1zciQHYEYH+q3ty3aS0eOaOdnD5yI6zoOV+eEhRRXJr0Wpr4C/ryqMiqRD232UkL5aHm5WutthC 7RInUcfj9wJ83/GRTxEqHyUMZs2c6vgo2ABFlyyK1PHgMKGtz1QRqqeKADfluixKQ1NLrTwrilrg FDzAKllweW+3ejglI6tLk/g7KiQ8FCyndPhh0KyWadrGXjv3LzSW/EV9hb3lDfTWSxR14D+C5gDF ZNrGAqXdGsT4Q6o8ClmFIwwP0PO5U853MP7ZK2jyLDSUdr8B3Pn25jnPh74AAAAASUVORK5CYII= In-Reply-To: (Paul Eggert's message of "Mon, 24 Jun 2019 14:11:31 -0700") 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:238121 Archived-At: Paul Eggert writes: > * The patch also needs a FIXME comment saying it fixes only "message" > output, not the other uses of stderr in Emacs. Well... that's kinda unusual. The commit message may say so, but having that in the code would be odd. > * The patched code has undefined behavior if the string length is > INT_MAX, and messes up in other ways if the string length exceeds > INT_MAX. This bug is unlikely but should be fixed. Yup. > * The second and third arguments to fwrite should be > interchanged. This makes a difference on some non-POSIX platforms, and > we might as well do it right here. I agree, but I just wanted to keep the code as similar as the previous one as possible. > * More important, the patched code shouldn't call xmalloc. Having to > allocate a buffer as part of an error diagnostic is a recipe for > trouble. (Suppose the diagnostic is related to being low on memory?) > Instead, the patched code should just use a fixed-size buffer that is > guaranteed to exist and be big enough. This is a basic design > principle for error diagnostics (I vaguely recall Dijkstra did this > back in the 1960s). It is, but the code also calls code_convert_string, so I thought one more xmalloc didn't make much difference. > * The buffer should contain only PIPE_BUF bytes, since writes larger > than that can be split by the operating system anyway so any excess > size is wasted. On POSIX platforms you can use fpathconf to calculate > PIPE_BUF for stderr. I don't know how to calculate it on MS-Windows > platforms, but maybe it doesn't matter and you can just pretend it's > 1024 or whatever. I don't think it's important -- if the buffer is larger than PIPE_BUF, we still might get multiprocess output interleaved, but I don't think we care that much. On modern OS-es it's 4096, and we seldom output things that are bigger than that via `message', to put it mildly. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no