GNOME Bugzilla – Bug 707900
do not assume time_t is long
Last modified: 2013-09-21 13:37:29 UTC
Created attachment 254656 [details] [review] printf: cast time_t to gint64 Hi. Same as https://bugzilla.gnome.org/show_bug.cgi?id=707829 On Linux time_t is long, on OpenBSD time_t is long long... so printf statements using %lu on 32-bit platforms will break on !Linux. The only portable way to print a time_t is using a cast and casting to "long long" (gint64) is probably the most portable way. The only part I am not 100% sure is addressbook/backends/file/e-book-backend-file.c Thanks.
Review of attachment 254656 [details] [review]: Yeah, e-book-backend-file.c looks like it's explicitly treating time_t as 32-bits to generate some hexadecimal ID string (if I'm reading this right). That's kind of broken, but I suppose the lower 32-bits are more important in that case anyway so if we truncate we truncate. Small code style nitpick: we prefer a space after a type cast. - (gint64)start + (gint64) start I have an awk script which fixes that automatically, but would be better if you could do so before committing. Also, while you're at it, can you remove the weird unnecessary parentheses in camel-lock.c? Rest of the patch looks good.
Thanks Matthew. I fixed them as you requested, it's in fa37efaf26d366a3d0d5256283455a28025ddbde I also tweak my previous evolution commit to add a space after the type casts I added.