From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-2.8 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id C0C5F245CB for ; Tue, 26 Mar 2024 13:46:17 +0100 (CET) Received: (qmail 14319 invoked by uid 550); 26 Mar 2024 12:41:29 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 14287 invoked from network); 26 Mar 2024 12:41:29 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pm.me; s=protonmail3; t=1711457164; x=1711716364; bh=Z4RtB0HjPvA8mMjaLNd/rYKtvDaLPERZv4nmMiQs5iQ=; h=Date:To:From:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=fx9FBrCaC8DqH71UN1J3fyCVwiZKo4+8/IEaD/2SgT02nWExkW6lIiESAwYThlpy5 ++NztLmJoXSTECdB/urYonEHuMW91pwONz6nmV//c8/0rbWCw5MpEoeJTyjq0dPdO0 K2Upn/TPVUhZlKBYZb9N6wN3qpP7RN2Bb+22f5wXeBPmLsvEXOtd+npLeSdEgZe21J 6+5yi46Gh4HLPXXWp6WAm8qjaSVkMBBV+FnmpZrf0nhIyIHWM1PMXZudMQ8vlzT7qx DV7GNcFn2l5xuSQ1li0uBwkheGKnyrhUXmiMnAauZL8sKuTTiPJDRjHnfi8m6t7MMC HPG72re5NpN/A== Date: Tue, 26 Mar 2024 12:45:46 +0000 To: musl@lists.openwall.com From: Alexander Weps Message-ID: In-Reply-To: References: <4YlR0YRqzZlDIOVv6SP8UDoop89n8u7BvQl_7eXNTvDZnogXMxG1z-TLGIBf-O4edUphddXGfADbk_d7Uzb37g5JoH7vOIvvNRMFDxPWZok=@pm.me> <20240325122113.GB4163@brightrain.aerifal.cx> Feedback-ID: 20507743:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] Broken mktime calculations when crossing DST boundary See below. AW On Tuesday, March 26th, 2024 at 00:34, Thorsten Glaser wrote= : > Alexander Weps dixit: > > > And all of this works in glibc. > > > Not at all, glibc=E2=80=99s mktime just throws the towel with > EOVERFLOW saying that the requested time does not exist. How is this not compliant with POSIX? This is perfectly valid behavior, that is both expected and can be handled = in code easily. I have to ask, but have you actually used mktime from the application end? > (It is only not permitted to change the input struct tm > member tm_wday if it returns EOVERFLOW but that doesn=E2=80=99t > mean that the output struct tm is correct.) > I am not sure what you mean by correct. Struct tm is neither correct nor in= correct. It can be in three states: 1) Set by user. 2) Normalized by mktime. 3) Not fully normalized by mktime. If I get -1, I know the struct tm does not represent valid time_t and I han= dle it and move on. This is perfect example (TZ=3DPacific/Apia): before: 2011-12-31 00:00:00 +14 0 after1: 2011-12-31 00:00:00 +14 1325239200 after1: 2011-12-30 00:00:00 +14 -1 after1: 2011-12-29 00:00:00 -10 1325152800 after2: 2011-12-28 00:00:00 -10 1325066400 after2: 2011-12-29 00:00:00 -10 1325152800 after2: 2011-12-30 00:00:00 -10 -1 after3: 2011-12-31 00:00:00 +14 1325239200 I am enumerating midnighta of each day. If I get -1, I ignore that date and= move along. Musl instead of giving sane results starts running in the circle at some po= int: after2: 2011-12-29 00:00:00 -10 1325152800 after3: 2011-12-29 00:00:00 -10 1325152800 > > > That=E2=80=99s because your application violates the constraints > > > that bind both, not just the libc, to the spec. > > > > Specify those constraints. > > > My wording here was badly, as dalias mentioned: > > > It's not a constraint violation. mktime is required to accept inputs > > where the fields of the broken-down time don't fall within their > > respective ranges, and normalize them. > > > > Rather, the calling code is just making incorrect assumptions about > > the unspecified way that happens, [=E2=80=A6] > > > The =E2=80=9Cconstraint=E2=80=9D (wrong word) I meant was that your progr= am > must not make assumptions about which of the two possible > conflict resolutions the libc chooses. > > > Show me a function implementation that produces same time next day > > under this behavior you assume to be correct. > > > It is not possible to do that with mktime. You=E2=80=99ll have to do > that yourself. POSIX even says so. > > It does indicate that on implementations (their word for libcs > here) that follow its recommendation to not normalise tm_sec, > you can achieve the desired effect by adding 86400 to it, though > that will not work right in the presence of a leap second on > systems honouring them (which is a deviation from POSIX, of > course). > > Adding 86400 to the time_t value, under the same leap second > caveat, can work if your code can rely on POSIX (ISO C does not > specify the internal structure of time_t). > > bye, > //mirabilos > -- > 22:20=E2=8E=9C The crazy that persists in his craziness becomes a= master > > 22:21=E2=8E=9C And the distance between the craziness and geniali= ty is > > only measured by the success 18:35=E2=8E=9C "Psychotics are consi= stently > > inconsistent. The essence of sanity is to be inconsistently inconsistent