We have code that tries to do intelligent things if we have gmtime_r: http://mxr.mozilla.org/mozilla-central/source/js/src/vm/DateTime.cpp#34 but we don't have a configure check for gmtime_r: http://mxr.mozilla.org/mozilla-central/search?string=gmtime_r it's worth noting that we do check for localtime_r: http://mxr.mozilla.org/mozilla-central/source/configure.in#3014 http://mxr.mozilla.org/mozilla-central/source/js/src/configure.in#2437 so I'm not sure how we missed gmtime_r. bug 850300 suggests that we might have checked for gmtime_r once upon a time, but the configure test was busted, or something?
It looks like we use gmtime_r in several places without configure checks, so maybe we can just declare victory and use it everywhere?
I don't know whether we *really* need this; we have unguarded uses of gmtime_r in the tree, but we also have guarded uses of gmtime_r. The Linux man page says that gmtime_r is specified in SUSv2 (!) and it also sounds like it was specified for POSIX Threads as well. I've opted to be safer here; we could try ripping checks out in a different bug?
Attachment #8549770 - Flags: review?(mshal)
(In reply to Nathan Froyd [:froydnj] [:nfroyd] from comment #1) > It looks like we use gmtime_r in several places without configure checks, so > maybe we can just declare victory and use it everywhere? Keeping in mind everywhere != Windows, it might be fine? It looks like code that is also used on Windows already has #ifdef on _WIN32 anyway. Though one other oddball is other-licenses/android/res_debug.c, which uses HAVE_TIME_R instead of HAVE_GMTIME_R.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla38
You need to log in before you can comment on or make changes to this bug.