guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 1.6.8 release candidate 0 available for testing.


From: Greg Troxel
Subject: Re: 1.6.8 release candidate 0 available for testing.
Date: 24 Oct 2005 21:29:38 -0400
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4

Kevin Ryde <address@hidden> writes:

> Greg Troxel <address@hidden> writes:
> 
> Straight "pass through" to libc sounds good to me.
> 
> >    and make the implementation set TZ before calling
> >    strftime (perhaps unless an implementation which guarantees to read
> >    tm_zone is detected).
> 
> That might be slow.  I notice what localtime does changing TZ is a
> noticable slowdown with glibc.  (It re-reads the timezone file(s) on
> every TZ change.)
> 
> I wonder if munging the global tzname[] variable would be enough.  Bad
> for multi-threading, but we've got issues with that in the time funcs
> already.

If we munge the variable or set TZ, then scheme strftime will have
stricter semantics than C99.  Also, I wonder if setting the variable
is safe according to the standard which defines it; that seems
dangerous.

> >    Perhaps don't set
> >    the non-C99 fields in what is used for the libc call to avoid
> >    nonportable expectations.
> 
> I wouldn't deliberately break something just because it's not
> portable.
> 
> > The meta-issue I see here is about guile providing consistent behavior
> > on all platforms.
> 
> Though I see your point.

I realize this is a tough call, but declining to provide more behavior
than the relevant standard ensures that the original programmer finds
the 'bug', rather than it later being a portability problem.

> PS. I added "man 3 strftime" to the manual.

Thanks, that will be helpful to some I think.


-- 
        Greg Troxel <address@hidden>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]