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: Fri, 16 Feb 2018 15:32:44 +0200 Message-ID: <837erddpqb.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1518788535 29459 195.159.176.226 (16 Feb 2018 13:42:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 16 Feb 2018 13:42:15 +0000 (UTC) Cc: emacs-devel@gnu.org To: Andy Moreton Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 16 14:42:10 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 1emgHA-0007Dx-Id for ged-emacs-devel@m.gmane.org; Fri, 16 Feb 2018 14:42:08 +0100 Original-Received: from localhost ([::1]:49130 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1emgJC-00077A-KY for ged-emacs-devel@m.gmane.org; Fri, 16 Feb 2018 08:44:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55746) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1emg8B-0006qA-D1 for emacs-devel@gnu.org; Fri, 16 Feb 2018 08:32:52 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1emg86-0007Z9-DH for emacs-devel@gnu.org; Fri, 16 Feb 2018 08:32:51 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34639) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1emg86-0007Yz-9p; Fri, 16 Feb 2018 08:32:46 -0500 Original-Received: from [176.228.60.248] (port=2081 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1emg85-00037U-NG; Fri, 16 Feb 2018 08:32:46 -0500 In-reply-to: (message from Andy Moreton on Fri, 16 Feb 2018 11:33:35 +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:222812 Archived-At: > From: Andy Moreton > Date: Fri, 16 Feb 2018 11:33:35 +0000 > > On Thu 15 Feb 2018, Eli Zaretskii wrote: > > C:/emacs/git/emacs/pdumper/src/pdumper.c: In function 'dump_read_all': > C:/emacs/git/emacs/pdumper/src/pdumper.c:4784:45: error: conversion to 'unsigned int' from 'size_t {aka long long unsigned int}' may alter its value [-Werror=conversion] > read (fd, (char*) buf + bytes_read, bytes_to_read - bytes_read); > ^~~~~~~~~~~~~ > In file included from C:/emacs/git/emacs/pdumper/src/character.h:27:0, > from C:/emacs/git/emacs/pdumper/src/buffer.h:27, > from C:/emacs/git/emacs/pdumper/src/pdumper.c:18: > C:/emacs/git/emacs/pdumper/src/pdumper.c: In function 'dump_object_1': > C:/emacs/git/emacs/pdumper/src/lisp.h:206:5: warning: this statement may fall through [-Wimplicit-fallthrough=] > (suppress_checking || (cond) \ > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > ? (void) 0 \ > ~~~~~~~~~~~~~~~~~~ > : die (# cond, __FILE__, __LINE__)) > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > C:/emacs/git/emacs/pdumper/src/pdumper.c:2915:11: note: in expansion of macro 'eassert' > eassert ("should not be dumping int: is self-representing" && 0); > ^~~~~~~ > C:/emacs/git/emacs/pdumper/src/pdumper.c:2916:9: note: here > default: > ^~~~~~~ > cc1.exe: some warnings being treated as errors > > > 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. 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 ;-). 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.