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 707829 - do not assume time_t is long
do not assume time_t is long
Status: RESOLVED FIXED
Product: evolution
Classification: Applications
Component: Calendar
3.10.x (obsolete)
Other OpenBSD
: Normal minor
: ---
Assigned To: evolution-calendar-maintainers
Evolution QA team
Depends on:
Blocks:
 
 
Reported: 2013-09-10 07:17 UTC by Antoine Jacoutot
Modified: 2013-09-21 13:34 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
cast time_t printf to long long (1.41 KB, patch)
2013-09-10 07:17 UTC, Antoine Jacoutot 		reviewed Details | Review
cast time_t printf gint64 (1.41 KB, patch)
2013-09-10 18:09 UTC, Antoine Jacoutot 		accepted-commit_now Details | Review

Description Antoine Jacoutot 2013-09-10 07:17:11 UTC 
Created attachment 254553 [details] [review]
cast time_t printf to long long

Hi.

On Linux time_t is long, on OpenBSD time_t is long long... and on other OSes it can even be different.
So printf statements using %lu on 32-bit platforms have a chance to break on !Linux.
The only portable way to print a time_t is using a cast and casting to
"long long" is probably the most portable way.

Thoughts?

PS: if this is alright to push I have a similar diff for e-d-s for which I will open a new BZ.
Comment 1 Matthew Barnes 2013-09-10 18:01:33 UTC 
Review of attachment 254553 [details] [review]:

I'd prefer gint64 since that's what GLib uses for "seconds since Unix epoch".
Comment 2 Antoine Jacoutot 2013-09-10 18:09:28 UTC 
Created attachment 254616 [details] [review]
cast time_t printf gint64

Indeed gint64 would make more sense here, thanks.
Comment 3 Matthew Barnes 2013-09-10 19:17:12 UTC 
Review of attachment 254616 [details] [review]:

The format string should be "%" G_GINT64_FORMAT instead of "%lld", but otherwise looks fine.

Fix that and go ahead and commit.  Thanks for catching that.
Comment 4 Antoine Jacoutot 2013-09-11 07:19:50 UTC 
Thank you Matthew. It's in: 44a2cb9886223df8ee497f5ecd19123f7a3ca5ea