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 59570 - FreeBSD doesn't have localtime() side-effect
FreeBSD doesn't have localtime() side-effect
Status: VERIFIED FIXED
Product: libxslt
Classification: Platform
Component: general
unspecified
Other FreeBSD
: Normal normal
: ---
Assigned To: Daniel Veillard
Daniel Veillard
Depends on:
Blocks:
 
 
Reported: 2001-08-26 15:10 UTC by lev
Modified: 2009-08-15 18:40 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description lev 2001-08-26 15:10:11 UTC
lixbslt/extra.c use sideffect of localtime() at line 238:

    local_tm = localtime(&gmt);                     

    /*
     * Calling localtime() has the side-effect of setting timezone.
     * After we know the timezone, we can adjust for it
     */

FreeBSD doesn't have global variable 'timezone' and any side-effect of 
localtime().
Comment 1 Daniel Veillard 2001-08-26 15:59:39 UTC
Is there a preprocessor define exported by FreeBSD to
not compile this function on that system.

I hardly see this as a major bug this function is an
extension function used by some DocBook stylesheets

Daniel
Comment 2 lev 2001-08-26 19:43:06 UTC
1) Of course, you could check __FreeBSD__ symbol.
2) Are you sure, `timezone' presents in SunOs and other non-Linux 
OSes? and what's about Win32?
3) On FreeBSD here is additional field in `struct tm': tm_gmtoff.
So, code could be changed as:

lmt = gmt - local_tm->tm_gmtoff;

On FreeBSD. Youc could check tm_gmtoff field with these configure 
code (I'm using it in my projects):

dnl Check for tm_gmtoff
AC_MSG_CHECKING([for tm_gmtoff field in struct tm])
AC_TRY_COMPILE([#include <sys/types.h>
#include <$ac_cv_struct_tm>], [ struct tm t; t.tm_gmtoff = 0; ],
HAVE_GMTOFF=yes, HAVE_GMTOFF=no )
if test "${HAVE_GMTOFF}x" = "yesx"; then
	AC_DEFINE(TM_HAVE_GMTOFF)
	AC_MSG_RESULT(yes)
else
	AC_MSG_RESULT(no)
fi
Comment 3 lev 2001-08-26 19:45:01 UTC
And one more question: I want to implement full `date' category from 
exslt. Is there somebody, who are doing it right now? I don't want to 
do work, which is already in progress.
Comment 4 Daniel Veillard 2001-08-26 20:13:27 UTC
  Okay you should *really* subscribe to the list [1] and post this kind of
questions there. I don't know who may work on this, the only think I'm
pretty sure about is that if there is a person doing this already they
are subscribed and listening on xslt@gnome.org

  The OpenBSD portability of the date functions has already been debated
there, and I'm really suprized that FreeBSD would behave differently
than OpenBSD, so please check:

    http://mail.gnome.org/archives/xslt/2001-August/msg00099.html

  and following mails.
  Concerning portability of this code, yes this worked out of the box
on Linux, Solaris an other OSes,

  so please read the archives and followup on the list, thanks !

Daniel

[1] http://mail.gnome.org/mailman/listinfo/xslt

Comment 5 Daniel Veillard 2001-09-11 10:44:16 UTC
Well if FreeBSD decided to not provide the timezone libc
varaible the simplest and easiest to maintain is to
simply comment this function out on that platform. It's
not part of XSLT standard nor EXSLT.

Daniel
Comment 6 rmg 2001-09-15 01:03:28 UTC
NetBSD doesn't have a timezone libc variable either. It does
have a timezone() libc function, though, which the manpage
says was present in Version 7 AT&T UNIX. Since it's hard to
subtract a function from an integer, the special-case for
FreeBSD needs to be extended to at least NetBSD to build.
Comment 7 Daniel Veillard 2001-09-15 15:31:05 UTC
Okay since this part is definitely not portable
and break on a number of platform, and is not part
of the spec but an extra specific function, I will
activate it only on Sun and Linux platforms where this
is known to work.

  thanks

Daniel
Comment 8 Daniel Veillard 2001-10-30 18:44:56 UTC
Okay the last 2 realses should hev this bug closed,

Daniel