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:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:content-type; q=dns; s=default; b=dH
	vkE1lbvfE+SLDiVYtMBBh9wvXYqPmAfeVRWkcmVEP/LXXt2t9qHbKhFtKYKUmB5k
	CGeeFCZBjRd5KsuRoLv2vcWP8UfloJRw9/5/9zI/sIFiYHoAG8mxCCf5wriDs87L
	Al3JkJxszaSZjfEWjFNmVm67AE4KvKuzjjMHWMEjk=
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:mime-version:in-reply-to:references:date
	:message-id:subject:from:to:content-type; s=default; bh=x0wjEiyC
	DI8/hd7VMPYtAKxYANI=; b=IvPNWR/ClR1/R440jBVQJcHDVDJxHYiYrN5aCgZe
	liAw8K7ta46pJVvm4/MwOZ3wmr0zMrTwRxUSLB29eisso5NSYu1fvlm+OSmv6Dua
	Ih/PdsCHMWu34q2KAVkmsW3HW11J8y6ogOooY7Wb9ppPxxIfBiNrXmm4eH2fQyUI
	O88=
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=-0.7 required=5.0 tests=BAYES_20,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2
X-HELO:	mail-la0-f44.google.com
X-Google-DKIM-Signature:	v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=jF2F2p/U053q7uB1NUU3Dja1l5zlKcnmKMQ4+dfLMag=; b=UXjsTAS/1DjT9SxSoV9MV+m9EnJ/sHZX24UuluoV7Zk+Pjaxl5VgLwkI1HNfmS6grA u8dFXBc/8/tafOch5dtQnHuzHRgSFVlte8lYHEfvnCPWfyZUK9iPmlB1JAV0oZzd2Des 7eq19iR7e+CYhbRFRzggzQ0PCfT6QCxX3XwJP77j0ZdaM0kwCD8wogaTZGMA1ySJAP/E 2z4n31l9pJMD819CL0oeKu1XNUQu7bRWlUn9YBgdG7atsnsmnQy4Kf2UNJPY5x3izts5 Cx3G/EY2WgLGKGAoB5qJXbRKBTGyhwfjXWU+o1spForsHoeP3cYtCvgYqX/dZe874AzI 1j4g==
X-Gm-Message-State:	ALoCoQlINiZNxd4rxkZyPjMHjvIAM34AQ9gL0NySw3N434wNbcMt6eMqEnHAXDwOVcIupf4hYl2W
MIME-Version:	1.0
X-Received:	by 10.152.28.105 with SMTP id a9mr10712039lah.9.1438480029785; Sat, 01 Aug 2015 18:47:09 -0700 (PDT)
In-Reply-To:	<loom.20150801T233913-448@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>
Date:	Sat, 1 Aug 2015 18:47:09 -0700
Message-ID:	<CAOC2fq9Uv77EuBDBP=Eywht4DqmZZm05WPhnp4dU1V7cD+CE_g@mail.gmail.com>
Subject:	Re: Seg Fault in strftime
From:	Michael Enright <mike AT kmcardiff DOT com>
To:	cygwin AT cygwin DOT com
X-IsSubscribed:	yes

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.
>
> - failing to call mktime()
>

See above.

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.

I originally did my project with a bespoke build of SpiderMonkey
because libmozjs didn't exist on any platform (it also can be found
for Debian which is convenient for me and my some-day customers) but
maintaining a library when it's available prebuilt is not supposed to
be the better option.

--
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 -