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: Fri, 16 Feb 2018 16:50:55 +0000 Message-ID: References: <1775923222.898447.1518559575706@mail.libero.it> <83inb0xkfx.fsf@gnu.org> <87o9krdftc.fsf@gmail.com> <83a7wby1x4.fsf@gnu.org> <83r2pnwftj.fsf@gnu.org> <08ac43fb-0b13-8a51-4571-11a21b8ffbdc@dancol.org> <83h8qiw7cd.fsf@gnu.org> <837erddpqb.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1518799826 17431 195.159.176.226 (16 Feb 2018 16:50:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 16 Feb 2018 16:50:26 +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 Fri Feb 16 17:50:22 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 1emjCg-0001ug-M8 for ged-emacs-devel@m.gmane.org; Fri, 16 Feb 2018 17:49:42 +0100 Original-Received: from localhost ([::1]:39706 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1emjEi-0003NH-Nx for ged-emacs-devel@m.gmane.org; Fri, 16 Feb 2018 11:51:48 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59365) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1emjET-0003Kf-DY for emacs-devel@gnu.org; Fri, 16 Feb 2018 11:51:34 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1emjEO-00023C-NA for emacs-devel@gnu.org; Fri, 16 Feb 2018 11:51:31 -0500 Original-Received: from [195.159.176.226] (port=41621 helo=blaine.gmane.org) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1emjEO-00022S-G4 for emacs-devel@gnu.org; Fri, 16 Feb 2018 11:51:28 -0500 Original-Received: from list by blaine.gmane.org with local (Exim 4.84_2) (envelope-from ) id 1emjC8-0008In-G3 for emacs-devel@gnu.org; Fri, 16 Feb 2018 17:49:08 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 35 Original-X-Complaints-To: usenet@blaine.gmane.org Cancel-Lock: sha1:gOAIuxHj94aCAyUk4uhpngxe+zY= 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:222828 Archived-At: On Fri 16 Feb 2018, Eli Zaretskii wrote: >> From: Andy Moreton >> This appears to be because sys_read() and _read() take an unsigned int >> for count rather than size_t. > > Yes. Angelo already reported this a few days ago. > >> Changing the code to: >> >> read (fd, (char*) buf + bytes_read, (int)(bytes_to_read - bytes_read)); > > This cannot be the right solution, because you will lose bits in the > cast, when bytes_to_read is greater than INT_MAX. Agreed - it was a quick and dirty hack to get the build to complete. > When Angelo reported this, I said I didn't understand how a similar > code in sysdep.c:emacs_intr_read does compile without a problem, > although it seems to feed a ptrdiff_t value (which should be 64-bit > wide in the 64-bit Windows build, just like size_t, except for the > signedness), similarly to the above. Can you spot why that works? > Maybe look at the preprocessed source? Maybe then we will know how to > fix that properly (or maybe we will discover one more subtle bug ;-). No idea - I'll take a look over the weekend. > In general, breaking the read into chunks of INT_MAX should work as > well, but I'd like to know first what's going on in emacs_intr_read, > because perhaps there's a more elegant solution we have available. Given the mismatch between sys_read/_read and read, doesn't the smae problem exist elsewhere in emacs also ? AndyM