After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 707900 - do not assume time_t is long
do not assume time_t is long
Status: RESOLVED FIXED
Product: evolution-data-server
Classification: Platform
Component: general
3.10.x (obsolete)
Other OpenBSD
: Normal normal
: ---
Assigned To: Evolution Shell Maintainers Team
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2013-09-11 09:21 UTC by Antoine Jacoutot
Modified: 2013-09-21 13:37 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
printf: cast time_t to gint64 (8.94 KB, patch)
2013-09-11 09:21 UTC, Antoine Jacoutot
accepted-commit_now Details | Review

Description Antoine Jacoutot 2013-09-11 09:21:12 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.
Comment 1 Matthew Barnes 2013-09-11 11:36:46 UTC
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.
Comment 2 Antoine Jacoutot 2013-09-11 13:59:23 UTC
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.