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=PB
	8Lv8EyS5s1LpSw+ss3Z3lPsl9JdI3crruDw7zv6FUPZuuaZzjB8QprpkTB/NLuaT
	nk3K5iCAExx1TsEBS2+YbvILyEoTukWOqWMpAijGojz1MfyyaMTV0MKR8xhqN5ec
	tvi/Afk0Ly4okHnXYX3BFz09rjdxdYsuJBs5MV3z0=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
MIME-Version: 1.0
In-Reply-To: <20150803083634.GE17917@calimero.vinschen.de>
References: <CAOC2fq9A1DSjy=7Af=wVCkNEsttpd4Fj-0w_nNwnSb76WFt5WA@mail.gmail.com>	<loom.20150801T233913-448@post.gmane.org>	<CAOC2fq9Uv77EuBDBP=Eywht4DqmZZm05WPhnp4dU1V7cD+CE_g@mail.gmail.com>	<20150803083634.GE17917@calimero.vinschen.de>
Date: Mon, 3 Aug 2015 03:54:42 -0700
Message-ID: <CAOC2fq-xQh8ThcvJBOMkWMfz0Y7b7FnhuHgBLaLSufLQY4qXGA@mail.gmail.com>
Subject: Re: Seg Fault in strftime
From: Michael Enright <mike@kmcardiff.com>
To: cygwin@cygwin.com
Content-Type: text/plain; charset=UTF-8

On Mon, Aug 3, 2015 at 1:36 AM, Corinna Vinschen wrote:
>
> The core thingy in POSIX is "The <time.h> header shall declare the tm
> structure, which shall include at least the following members:"
>                                ^^^^^^^^

I saw this language myself.

>
> A conforming application does not use such a structure which isn't
> *at least* initialized to all 0 (memset).
>

I did NOT see any language that said anything about doing that. In any
case, the code I'm using is in another Cygwin package, libmozjs185.


> If your executable has been built prior to releasing this new code,
> Cygwin won't require tm_zone and tm_gmtoff anyway.

I have no idea how to interpret "has been build prior" in this case.

>  However, for later
> built executables it will, and then there's no way around the crash
> if tm_zone is uninitialized.  If it's NULL, you'll get the current
> timezone.  But if it's not NULL it's suppsoed to be a pointer to
> a valid string.  How is a library supposed to know that the pointer
> value is just garbage?

In the case where the spec does not say anything except the members
shall include at least so-and-so, the library probably ought not to
assume that it gets its implementation-defined members defined as
inputs.

In the case where the POSIX spec uses "at least" language to define
visiible members AND specifically says that code layering on top of
that struct has to use memset or some other specific means to control
the unknown implementation-defined members, then of course the
implementation can assume that such things were done.

So the reason I'm twisting in the wind is because the implementation
has chosen to depend on the state of implementation-defined members,
the spec doesn't say anything about requiring applications to control
their values, and a library in Cygwin did not control their values,
and my application cannot work around it.

Also as an experiment I've tried to build v8. This has lead to the
subject of a new thread.

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