From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 2286 invoked from network); 10 Aug 2020 13:36:51 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 10 Aug 2020 13:36:51 -0000 Received: (qmail 9436 invoked by uid 550); 10 Aug 2020 13:36:48 -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 5351 invoked from network); 10 Aug 2020 13:31:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=z2nyqlRMyh7WQptV3t+iCk1E8brSPNlS4cUsLWo1C54=; b=Gg601m5+8pMeydcdO3F99Y/t2lCiK3BLIrM1NnBrj1McvwAhvPPlIh6mnZO0LloY54 gAJ0/2dQomTX9rrthEjxtFTNq4O/KtLgQWLMvzznBRl+K4UBsk6ruDMK0J4ArJlunSky OgSjAxtiUD3n/JtqXy3Y4zHO558bH9cIR+ev93jVvCg0KFgZq8Z4fAkCkve03MUHAt4P nfjMd9uLqeVmaskSnfnyKuJOzcF5WO7SyX0e8sS5UFo/sXfUeT30+h7+lpHlxMOROMo2 XWazpB7NkOjqA3YDu6ICSM+ko8DDG7lian55A4flu3Yp+f52g8orr9DPxhwhJMmIjJiX skTg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=z2nyqlRMyh7WQptV3t+iCk1E8brSPNlS4cUsLWo1C54=; b=baatkTdpu2T2GrDfLlC4nYDoFfhAIUQmEi9bpdc2QTWrpUKezLTkcG4AB7B2i0nrgy qiJvNlHVar1ZImtgKr6S4xRMNtRTaSj8CXDqsJsxobNUIpDbVmDF54Ki6vjYhh2RL2qm fctT3riEUHnpqY7Iq4kZH7OuvtzDe3/HhahoEvqp58WuIUTYuCaUg3Ku8XwdqYAJ2lFj mZNhnM4c6juDEu9kJcJfJCzJpo8cSbwTjqOrNdEeDP3bPcXh9lzSYpACX3Fp7L+Ql9OW +gcXRfm5grqE72Flfy+r1r0/f2zz9iqecHBzCIWuQ/O0LrHiTPAlgvPE7o+nvEh10aEn PtrA== X-Gm-Message-State: AOAM532QsXtzpHhZ3d11JjuNss7OcuW1x0E9BSIyrP73f1/hDxyj0JdA 6FE0pwzMPC+7p4rizYaeUrOtoTbCtBEGAaghjOx2quL0vh4J2w== X-Google-Smtp-Source: ABdhPJxBatVampSVUZzeVsfW3zjsCFNWLeI7YndxO6UjPcnVaL37X2QoMqgkEuBJ/IjAZ3I3TrTwAoA89R/KTGqJ2LE= X-Received: by 2002:a05:6512:14d:: with SMTP id m13mr582533lfo.173.1597066299504; Mon, 10 Aug 2020 06:31:39 -0700 (PDT) MIME-Version: 1.0 From: Nikita Popov Date: Mon, 10 Aug 2020 15:31:23 +0200 Message-ID: To: musl@lists.openwall.com Content-Type: multipart/alternative; boundary="00000000000076fcca05ac85f92f" Subject: [musl] strftime %Z behavior with manually populated struct tm --00000000000076fcca05ac85f92f Content-Type: text/plain; charset="UTF-8" Hi, Currently, strftime() %Z will print an empty string if the provided tm_zone does not originate from musl. It appears that this behavior is explicitly implemented in __tm_to_tzname(). Would it be possible to instead print any non-NULL tm_zone as provided? For consumers manually populating the struct tm structure, it is non-trivial to work around the current behavior. Python introduced a work around in https://github.com/python/cpython/commit/163eca34c48f1b25e1504e37f4656773fd0fdc78, but it is not easy to generalize. >From what I gathered, the original concern here was that a consumer manually initializing struct tm may not initialize the tm_zone field. As struct tm is only specified to contain "at least" certain members, manual initialization of this structure is already on shaky ground anyway and I think it is more useful to assume the initialization is correct than try to deal with garbage data. Because other libc implementation do not try to validate the pointer either (beyond being non-NULL), incorrect initialization is unlikely in practice. Regards, Nikita --00000000000076fcca05ac85f92f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Currently, strftime() %Z= will print an empty string if the provided tm_zone does not originate from= musl. It appears that this behavior is explicitly implemented in __tm_to_tzname(). Would it be possible to instead print any non-NULL t= m_zone as provided?

For consumers manually populating the struct tm s= tructure, it is non-trivial to work around the current behavior. Python int= roduced a work around in https://github.com/python/cpyth= on/commit/163eca34c48f1b25e1504e37f4656773fd0fdc78, but it is not easy = to generalize.

=
From what I gathered, the original concern here wa= s that a consumer manually initializing struct tm may not initialize the tm= _zone field. As struct tm is only specified to contain "at least"= certain members, manual initialization of this structure is already on sha= ky ground anyway and I think it is more useful to assume the initialization= is correct than try to deal with garbage data. Because other libc implemen= tation do not try to validate the pointer either (beyond being non-NULL), i= ncorrect initialization is unlikely in practice.

Regards,
Nikita
--00000000000076fcca05ac85f92f--