X-Recipient:	archive-cygwin AT delorie DOT com
DomainKey-Signature:	a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:to:from:subject:date:message-id:references
	:mime-version:content-type:content-transfer-encoding; q=dns; s=
	default; b=QWvaIwW/noZkILWi50Xb3BHoHKOxtTpsNOKNS5DanQMfZV7QEwEv+
	+I+MrpC/1OokOGgiRPsALWDMKxrDFo34DrXYA3UmEOxBh0gusSUWpSIv/LuRH/Na
	0e4hp5m/2QECsFzclHBHS8TqqaeLRuaCWw5LHNaRDwQSCBYzpt9bwY=
DKIM-Signature:	v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:to:from:subject:date:message-id:references
	:mime-version:content-type:content-transfer-encoding; s=default;
	bh=F387y6gSclMfNOZh0tBbq6Z/cZ4=; b=sWBCLkR1kXY7swwBVo7DdZNJzGq/
	2JiJH60bG79hzXOWDXZG0Ofdq03f71JaE+4W6CF/qn6y+sptKskpNe2yAkMrl4vQ
	cdw1ErzjGvyQZNNGvv81HuL7C6PrC3NR5FFN2MK8rhx2r4koNt6F219BmyBEplP9
	06TWUL597YvPgOc=
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Authentication-Results:	sourceware.org; auth=none
X-Virus-Found:	No
X-Spam-SWARE-Status:	No, score=-2.3 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2
X-HELO:	plane.gmane.org
To:	cygwin AT cygwin DOT com
From:	Brian Inglis <Brian DOT Inglis AT SystematicSw DOT ab DOT ca>
Subject:	Re: Seg Fault in strftime
Date:	Mon, 3 Aug 2015 03:36:46 +0000 (UTC)
Lines:	66
Message-ID:	<loom.20150803T052556-690@post.gmane.org>
References:	<CAOC2fq9A1DSjy=7Af=wVCkNEsttpd4Fj-0w_nNwnSb76WFt5WA AT mail DOT gmail DOT com> <loom DOT 20150801T233913-448 AT post DOT gmane DOT org> <CAOC2fq9Uv77EuBDBP=Eywht4DqmZZm05WPhnp4dU1V7cD+CE_g AT mail DOT gmail DOT com>
Mime-Version:	1.0
User-Agent:	Loom/3.14 (http://gmane.org/)
X-IsSubscribed:	yes

Michael Enright <mike <at> kmcardiff.com> writes:

> 
> Brian,
> In reference to your comments below I found this link to a repo of
> SpiderMonkey source code.
> 
>
http://hg.mozilla.org/releases/mozilla-1.9.1/file/920bcf17a9e1/js/src/prmjtime.cpp
> And the function that calls strftime specifically:
>
http://hg.mozilla.org/releases/mozilla-1.9.1/file/920bcf17a9e1/js/src/prmjtime.cpp#l586
> 
> On Sat, Aug 1, 2015 at 2:47 PM, Brian Inglis  wrote:
> >
> > Two problems I have encountered in the past with manually constructed
struct tm:
> > - failing to set struct tm.tm_isdst member to -1, or any negative value, so
> > that mktime(3) will determine whether DST is in effect, and set the struct
> > tm.tzname array from the tzdb
> 
> The code calls strftime after setting tm_isdst from its own struct's
> corresponding flag.
> 
> > - failing to call mktime(3) for each struct tm variable to normalize the
> > struct tm members, determine if DST is in effect if struct tm.tm_isdst
> > member is -1, and set the struct tm.tzname array from the tzdb.
> > Check back in the code to see if struct tm.tm_isdst is set and to what
> > value, and if mktime(3) is called on each struct tm after it is filled.
> 
> The code doesn't call mktime at all.

> There is a section of the code that I believe is meant to be
> configured in but it is not. This code calls localtime_r with a time_t
> of zero and copies the resulting tm_gmtoff and tm_zone into the struct
> tm that the routine will call strftime on. This code starts at line
> 621,
http://hg.mozilla.org/releases/mozilla-1.9.1/file/920bcf17a9e1/js/src/prmjtime.cpp#l621
> to jump to that line.
> 
> The things you advocate doing are super-responsible things to do. I
> have a huge investment in using this particular library and now I'm
> twisting in the wind because someone else appears not to have done all
> the super responsible things they should have done.
> 
> I have found there is tons of code out there manually filling in
> struct tm's and then filing bugs in glibc (not just newlib problem)
> when things go wrong. And then without even the courtesy of a citation
> of a spec these bugs are resolved WONTFIX because these upstreams
> believe they have the right to insist that struct tm's should NEVER
> manually be filled in and why would you do it anyway. I think the
> minimum struct members specified on POSIX should be considered the API
> to any function that reads struct tm, not because POSIX says so but
> because it is the way to keep machines from getting pwned through
> crash bugs.

Looks like the function attempts to duplicate the normalization of
mktime(3), but may not deal correctly with all of the edge cases, 
or handle other settings required to properly deal with time zones;  
and testing may not do all the regressions applied to most library functions. 

I would replace the fiddly code with a call to mktime(3), so all the
library's struct tm requirements are met; then there may be a case for 
filing a bug against the library mktime() or downstream functions if results
are not as expected. 



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -