This is the mail archive of the
mailing list for the Cygwin project.
Re: Seg Fault in strftime
- From: Michael Enright <mike at kmcardiff dot com>
- To: cygwin at cygwin dot com
- Date: Mon, 3 Aug 2015 03:54:42 -0700
- Subject: Re: Seg Fault in strftime
- Authentication-results: sourceware.org; auth=none
- 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>
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
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
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple