From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Greg Troxel Newsgroups: gmane.lisp.guile.devel Subject: Re: 1.6.8 release candidate 0 available for testing. Date: 19 Oct 2005 13:18:19 -0400 Message-ID: References: <87u0fipkio.fsf@trouble.defaultvalue.org> <87y84taxzo.fsf@zip.com.au> <87fyqy8f3f.fsf@zip.com.au> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1129743223 31806 80.91.229.2 (19 Oct 2005 17:33:43 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 19 Oct 2005 17:33:43 +0000 (UTC) Cc: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Oct 19 19:33:41 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1ESHnu-0003Id-64 for guile-devel@m.gmane.org; Wed, 19 Oct 2005 19:32:42 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ESHnt-0007Vf-MX for guile-devel@m.gmane.org; Wed, 19 Oct 2005 13:32:41 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1ESHa1-0000Cp-JZ for guile-devel@gnu.org; Wed, 19 Oct 2005 13:18:21 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1ESHa0-0000CR-TT for guile-devel@gnu.org; Wed, 19 Oct 2005 13:18:21 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ESHZz-0000CL-V1 for guile-devel@gnu.org; Wed, 19 Oct 2005 13:18:20 -0400 Original-Received: from [192.1.100.210] (helo=fnord.ir.bbn.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1ESHZz-0003tO-UB for guile-devel@gnu.org; Wed, 19 Oct 2005 13:18:20 -0400 Original-Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id 5F88A5286; Wed, 19 Oct 2005 13:18:19 -0400 (EDT) Original-To: Kevin Ryde In-Reply-To: <87fyqy8f3f.fsf@zip.com.au> Original-Lines: 51 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:5313 Archived-At: Kevin Ryde writes: > Greg Troxel writes: > > The bit about %Z is > > %Z is replaced by the locale's time zone name or > abbreviation, or by no characters if no time zone is > determinable. [tm_isdst] > > which I suppose is because struct tm is speced without tm_zone. Probably. NetBSD libc uses the environment variable or /etc/localtime. > You'd think a system with tm_zone should use it, but yes no sense > demanding what doesn't work. Yes, but the point (from the PR) is that a conforming program doesn't have to set it, so libc reading it causes undefined behavior, and thus libc can't read it. > > Perhaps libguile/strftime.c needs to not assume that strftime(3) > > will examine fields not specified by the standard, or perhaps that > > Scheme strftime should define what it does more precisely. A > > problem here is that guile uses a structure which is bigger than > > C89 says. > > Since we initialize tm_zone if it exists we should be safe, but a note > in the docs about what guile tm:zone might or might not do could be in > order. Sure, guile sets it. Options I see are 1) declare the Scheme proc strftime has extended semantics beyond C99, document them, and make the implementation set TZ before calling strftime (perhaps unless an implementation which guarantees to read tm_zone is detected). 2) Document that the scheme proc strftime conforms, after langauge mapping, to C99, and point out that thus tm_zone is expected to be ignored because it isn't part of the standard. Perhaps don't set the non-C99 fields in what is used for the libc call to avoid nonportable expectations. The meta-issue I see here is about guile providing consistent behavior on all platforms. On some points it seems to do this, but it also at times just wraps OS libraries. One of the wins of guile is portability, and I'd like to keep as much of that as possible. -- Greg Troxel _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://lists.gnu.org/mailman/listinfo/guile-devel