From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Preview: portable dumper Date: Tue, 20 Feb 2018 06:03:53 +0200 Message-ID: <83bmgk8fyu.fsf@gnu.org> References: <1775923222.898447.1518559575706@mail.libero.it> <277032065.898859.1518560883271@mail.libero.it> <1456022824.1085831.1518815658356@mail.libero.it> <46535781-d5c2-fee8-05aa-37a29988ce86@dancol.org> <83a7w8c7yg.fsf@gnu.org> <86eflg8vqi.fsf@gmail.com> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1519099329 23119 195.159.176.226 (20 Feb 2018 04:02:09 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 20 Feb 2018 04:02:09 +0000 (UTC) Cc: emacs-devel@gnu.org To: Andy Moreton Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 20 05:02:04 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1enz7u-0004m3-EN for ged-emacs-devel@m.gmane.org; Tue, 20 Feb 2018 05:01:58 +0100 Original-Received: from localhost ([::1]:53514 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1enz9o-0000da-IC for ged-emacs-devel@m.gmane.org; Mon, 19 Feb 2018 23:03:56 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55353) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1enz9g-0000dL-50 for emacs-devel@gnu.org; Mon, 19 Feb 2018 23:03:49 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1enz9d-0000Dc-2K for emacs-devel@gnu.org; Mon, 19 Feb 2018 23:03:48 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46788) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1enz9c-0000DX-Ui; Mon, 19 Feb 2018 23:03:44 -0500 Original-Received: from [176.228.60.248] (port=3220 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1enz9c-0000zO-3M; Mon, 19 Feb 2018 23:03:44 -0500 In-reply-to: <86eflg8vqi.fsf@gmail.com> (message from Andy Moreton on Mon, 19 Feb 2018 22:23:17 +0000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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:223477 > From: Andy Moreton > Date: Mon, 19 Feb 2018 22:23:17 +0000 > > Comments mentioning MAX_RW_COUNT show that somebody checked an invariant > when writing the comment, but they do not guarantee that the invariant > will continue to be maintained in future versions of emacs. A check that > can be enforced by the compiler is preferable. I added an assertion there (on master) that should make the code more future-proof. > > As for pdumper, we could do one of 2 things: > > > > . make a reasonable assumption that no .pdmp file will ever be larger > > than 2GB, change the assertion there which checks against SSIZE_MAX > > to check against UINT_MAX instead, and work internally with > > unsigned int instead of size_t counts; or > > This seems perfectly reasonable, and is the current implementation, > albeit checking for INT_MAX. No, the current code actually breaks the reads into chunks no larger than INT_MAX. So it doesn't assume a .pdmp file cannot be at most 2GB. > > . write a separate Windows-specific version of dump_read_all, which > > in the 64-bit build would limit to UINT_MAX the number of bytes we > > read on each iteration through the loop. > > This offers more opportunity for divergent implementations, so the other > option is preferable. I presumed that we will not want to punish other platforms by making them read piecemeal. But if that's not an issue, I agree that the second alternative is less elegant. > Is there a gnulib replacement for read() that works for emacs, so that > we could use the proper prototype even on Windows ? No, because sys_read does much more than just fix the Windows _read.