From mboxrd@z Thu Jan 1 00:00:00 1970 From: 7heo@7heo.tk Subject: Re: [PATCH] FIX: Cast the time_t values to avoid warnings Date: Sun, 28 Apr 2013 00:27:29 +0200 Message-ID: <20130427222729.GA32177@7heo.tk> References: <1367092353-22130-1-git-send-email-7heo@7heo.tk> <20130427201803.GA17211@quantz> <20130427213235.GA28121@7heo.tk> <20130427220349.GB29754@quantz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: <20130427220349.GB29754@quantz> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org On Sat, Apr 27, 2013 at 11:03:49PM +0100, Patrick Welche wrote: > On Sat, Apr 27, 2013 at 11:32:35PM +0200, 7heo@7heo.tk wrote: > > On Sat, Apr 27, 2013 at 09:18:03PM +0100, Patrick Welche wrote: > > > On Sat, Apr 27, 2013 at 09:52:33PM +0200, 7heo wrote: > > > > I added 4 casts from time_t to unsigned long int > > > > in the libxl_sprintf functions, so there is no > > > > warning at compilation time (and no failing with > > > > -Werror). > > > > > > > > The casting format has been discuted, and since > > > > there is no system having a 8 byte time_t format > > > > yet; unsigned long int should be sufficient. > > > > Also, it matches the libxl_sprintf syntax (%lu). > > > > > > I thought that earlier in the thread someone pointed > > > out that unsigned long long would be a better plan? > > > (long could just be 32 bits long) > > > > > > Cheers, > > > > > > Patrick > > > > As explained in the second paragraph of the git commit > > message (even if I did a typo); this has been discussed > > already. > > Is the typo in the part which says "since there is no system having > a 8 byte time_t format yet", which should read "most systems which > want to keep going beyond 2038 have 8 byte time_t format"? > The box I'm sitting in front of certainly has sizeof(time_t)==8. > > The point is that all that is guaranteed is that > sizeof(long long) >= sizeof(long) >= sizeof(int) > > Just checked on a 32-bit OS: > > % cat foo.c > #include > #include > > int main() > { > printf("time_t: %u int: %u long: %u long long: %u\n", > sizeof(time_t), sizeof(int), sizeof(long), sizeof(long long)); > > return 0; > } > % ./foo > time_t: 8 int: 4 long: 4 long long: 8 > > so long long is a better choice. > > > Cheers, > > Patrick Thanks for having taken the time to check. Then it would maybe make sense to check the size of time_t at compilation time (with cpp instructions) in order to chose the cast that fits, wouldn't it? Also, this surprises me, I wouldn't have imagined that people would care about the 32bit time overflow before 2035... Regards, 7heo.