From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Andy Moreton Newsgroups: gmane.emacs.devel Subject: Re: Preview: portable dumper Date: Mon, 19 Feb 2018 22:23:17 +0000 Message-ID: <86eflg8vqi.fsf@gmail.com> 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> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1519078977 2354 195.159.176.226 (19 Feb 2018 22:22:57 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 19 Feb 2018 22:22:57 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.91 (windows-nt) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Feb 19 23:22:53 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 1entpP-0007cm-ST for ged-emacs-devel@m.gmane.org; Mon, 19 Feb 2018 23:22:31 +0100 Original-Received: from localhost ([::1]:52633 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1entrQ-0002oE-CC for ged-emacs-devel@m.gmane.org; Mon, 19 Feb 2018 17:24:36 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44453) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1entqq-0002o8-8B for emacs-devel@gnu.org; Mon, 19 Feb 2018 17:24:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1entqm-0002lE-9o for emacs-devel@gnu.org; Mon, 19 Feb 2018 17:24:00 -0500 Original-Received: from [195.159.176.226] (port=60399 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1entqm-0002kC-2k for emacs-devel@gnu.org; Mon, 19 Feb 2018 17:23:56 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1entoU-0004IP-Ri for emacs-devel@gnu.org; Mon, 19 Feb 2018 23:21:34 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 40 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:+1A3wI0Th7q6m3LUcWuB05ARdVA= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 195.159.176.226 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:223468 On Sat 17 Feb 2018, Eli Zaretskii wrote: > Since MAX_RW_COUNT is less than INT_MAX, we have no real problem here > for MS-Windows, as 'nbyte' will never overflow an unsigned int. We > could add an eassert there, for Windows only, though, to make this > assumption explicit. 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. > 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. > . 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. > Daniel, which of these 2 alternatives do you prefer? Or does anyone > have a better proposal? (I already considered rewriting the code in > w32.c:sys_read so that it accepts a size_t last argument, and decided > it was unjustified for this single caller, as all the other direct > calls to 'read' in Emacs either use fixed small byte counts, or are > not compiled in the Windows build.) Is there a gnulib replacement for read() that works for emacs, so that we could use the proper prototype even on Windows ? If so we could get rid of sys_read etc. AndyM