From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: warn-maybe-out-of-memory Date: Fri, 11 Jul 2014 09:50:03 +0300 Message-ID: <837g3kbd9g.fsf@gnu.org> References: <83egxtax97.fsf@gnu.org> <83d2ddaw52.fsf@gnu.org> <53BF6B2F.5030701@yandex.ru> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1405061422 19673 80.91.229.3 (11 Jul 2014 06:50:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 11 Jul 2014 06:50:22 +0000 (UTC) Cc: emacs-devel@gnu.org To: Dmitry Antipov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 11 08:50:14 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1X5Ues-0000WS-GD for ged-emacs-devel@m.gmane.org; Fri, 11 Jul 2014 08:50:14 +0200 Original-Received: from localhost ([::1]:42509 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X5Ues-000798-6J for ged-emacs-devel@m.gmane.org; Fri, 11 Jul 2014 02:50:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46101) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X5Uek-00078s-Tv for emacs-devel@gnu.org; Fri, 11 Jul 2014 02:50:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X5Uef-0004vG-5r for emacs-devel@gnu.org; Fri, 11 Jul 2014 02:50:06 -0400 Original-Received: from mtaout29.012.net.il ([80.179.55.185]:45018) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X5Uee-0004ua-Pn for emacs-devel@gnu.org; Fri, 11 Jul 2014 02:50:01 -0400 Original-Received: from conversion-daemon.mtaout29.012.net.il by mtaout29.012.net.il (HyperSendmail v2007.08) id <0N8J00J00BWNB400@mtaout29.012.net.il> for emacs-devel@gnu.org; Fri, 11 Jul 2014 09:49:56 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by mtaout29.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0N8J00DN8CB82M70@mtaout29.012.net.il>; Fri, 11 Jul 2014 09:49:56 +0300 (IDT) In-reply-to: <53BF6B2F.5030701@yandex.ru> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.179.55.185 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:172961 Archived-At: > Date: Fri, 11 Jul 2014 08:42:23 +0400 > From: Dmitry Antipov > CC: emacs-devel@gnu.org > > On 07/10/2014 10:47 PM, Eli Zaretskii wrote: > > >> I wonder if this function should only warn when it is called from > >> commands invoked by the user, as opposed to from a Lisp program. The > >> warning is in find-file-noselect, which AFAIK is widely used in Lisp > >> programs, where displaying this warning might be inappropriate. > > Hm, find-file-noselect also may ask for confirmation to open large file. > If this is undesirable, shouldn't we move all user interaction to top-level > find-file? Maybe. > >> In addition, the function assumes that visiting a file of size N bytes > >> needs N bytes of memory, which is false: we need more, sometimes much > >> more. > > No. This function assumes that visiting a file of size N bytes needs > at least N bytes of memory, and warns if we have even less than N. But if this warning is to be useful, it should catch the majority of the cases, otherwise we are just wasting cycles. With the current test, many cases of visiting files that cannot be accommodated will go undetected, thus rendering all this feature useless. Since it's only a warning that doesn't prevent visiting a file, it is better to err on the other side of the truth. E.g., apply some heuristics as to the average expansion factor, perhaps dependent on the locale. And don't forget that even for plain-ASCII files we allocate the gap in addition to the text itself, so the mere size of the file is simply _never_ the correct value, it is always an underestimation. IOW, this test is always biased towards lower values. If we don't do something like that, then I wonder what exactly is the use case that benefits from this warning? > > Also, is this call to emacs_abort really appropriate? Or is it some > > remnant from debugging this code? > > > > if (sysinfo (&si)) > > emacs_abort (); <<<<<<<<<<<<<<<<<<<<<< > > Here emacs_abort may be called only if &SI points outside of a process' > address space. This is possible only if C stack is smashed and so you > have no way to continue anyway. It is IMO inappropriate for a minor feature like this one to abort Emacs. Who knows what the Linux kernel developers will introduce tomorrow that could possibly fail the function? It is none of this feature's business to be the place where C stack smashing is detected. So my vote is for returning nil and perhaps displaying a warning.