From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from scc-mailout-kit-02.scc.kit.edu (scc-mailout-kit-02.scc.kit.edu [129.13.231.82]); by fantadrom.bsd.lv (OpenSMTPD) with ESMTP id 799bd650; for ; Tue, 10 Mar 2015 20:10:36 -0500 (EST) Received: from asta-nat.asta.uni-karlsruhe.de ([172.22.63.82] helo=hekate.usta.de) by scc-mailout-kit-02.scc.kit.edu with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (envelope-from ) id 1YVVAO-0003Br-S0; Wed, 11 Mar 2015 02:10:34 +0100 Received: from donnerwolke.usta.de ([172.24.96.3]) by hekate.usta.de with esmtp (Exim 4.77) (envelope-from ) id 1YVVAO-0004ZR-Mw; Wed, 11 Mar 2015 02:10:32 +0100 Received: from athene.usta.de ([172.24.96.10]) by donnerwolke.usta.de with esmtp (Exim 4.80) (envelope-from ) id 1YVVAO-000112-Ib; Wed, 11 Mar 2015 02:10:32 +0100 Received: from localhost (1031@localhost [local]); by localhost (OpenSMTPD) with ESMTPA id 01f20707; Wed, 11 Mar 2015 02:10:32 +0100 (CET) Date: Wed, 11 Mar 2015 02:10:32 +0100 From: Ingo Schwarze To: Joerg Sonnenberger Cc: tech@mdocml.bsd.lv Subject: Re: mdocml: The st_size member of struct stat is off_t, which is signed, all Message-ID: <20150311011032.GB22101@athene.usta.de> References: <1281237932347383369.enqueue@fantadrom.bsd.lv> <20150310214738.GA20964@britannica.bec.de> X-Mailinglist: mdocml-tech Reply-To: tech@mdocml.bsd.lv MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150310214738.GA20964@britannica.bec.de> User-Agent: Mutt/1.5.23 (2014-03-12) [ Moving this to tech@ ] Hi Joerg, Joerg Sonnenberger wrote on Tue, Mar 10, 2015 at 10:47:38PM +0100: > On Tue, Mar 10, 2015 at 09:18:22AM -0500, schwarze@mdocml.bsd.lv wrote: >> Log Message: >> ----------- >> The st_size member of struct stat is off_t, which is signed, >> all required by POSIX. So don't compare it against against >> an unsigned constant. > Well, the change truncates the value. How so? The actual width of size_t will hardly be narrower than the width of off_t on any sane platform, or am i mistaken? The values of off_t are positive, so the range of size_t completely covers the range of off_t that can occur. > Wouldn't it make more sense to use just use 0x7fffffff > as constant instead? I think POSIX ensures that int is 32bit. That seems completely equivalent to me, but maybe i'm missing something? Arguably, a comparison to 0x7fffffff is easier to understand than a cast plus a comparison to (1 << 31), though - hmm... Yours, Ingo -- To unsubscribe send an email to tech+unsubscribe@mdocml.bsd.lv