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=PB
	8Lv8EyS5s1LpSw+ss3Z3lPsl9JdI3crruDw7zv6FUPZuuaZzjB8QprpkTB/NLuaT
	nk3K5iCAExx1TsEBS2+YbvILyEoTukWOqWMpAijGojz1MfyyaMTV0MKR8xhqN5ec
	tvi/Afk0Ly4okHnXYX3BFz09rjdxdYsuJBs5MV3z0=
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=NvYXX1IO
	kJ2bOo4MDa0o22WEt5w=; b=yS7kr8OsuWnW4p7dEaFkM+EiUf6FbiBPvqVWYjcM
	2R5GCwJMFCqGWZRMvwjCpkd2jkGUhDNufaPf2bDpCDONGZO9fF3trKtwQhOKGmy7
	q0uU9VhWbw6gacPC9M/roZc6N0ne5BY2CTl8Z6Rc0Zw2kdhtx6GBeWwKKH7ajCyd
	NzA=
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.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2
X-HELO: mail-lb0-f171.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=PLJ0R2fH8JGYst+f3OhDpnq7fXGgjanoRujFUpF+KxM=;        b=hYQgBwwgNOhufdWlbbhLBHzDEsc40zh/Vos7101383Y+Z0z9Ofj1wfFKaT0oZQyEKQ         M9chMUJmsjNnLkAecZdYJvSZ/Wfnfd6PhL+RYrPzDWjHpFIwYQjkDG02R7W/l9YtSiT9         HcMTshqWODvIQtA7bOA71X/DEqPGT1geNXUSr87EYUg1M5IdMzBqsODyKlZ/GTrBBV9K         K3XdWBC7lUxdA5tkYK6e3whd38f19Ywd9+LmWGkJmrh45u5V21EOhUO0NK6Ua6bViHBA         YL3J2pNgPIulkJFreyO/MNul1kyCUf/zOFxZs+oZ/pZrK3UHiXROymlQQKYNDfUpiqVn         qdpA==
X-Gm-Message-State: ALoCoQnFVPNWmFTYgw7AkwvUu9zeHHDxhEhXB/jgay/b7vde6TdpOYrEMJDc4N3aNXUSqCh90r2y
MIME-Version: 1.0
X-Received: by 10.112.219.70 with SMTP id pm6mr15802259lbc.41.1438599282443; Mon, 03 Aug 2015 03:54:42 -0700 (PDT)
In-Reply-To: <20150803083634.GE17917@calimero.vinschen.de>
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>	<20150803083634 DOT GE17917 AT calimero DOT vinschen DOT 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 AT kmcardiff DOT com>
To: cygwin AT cygwin DOT com
Content-Type: text/plain; charset=UTF-8
X-IsSubscribed: yes

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