GV

GeezerVison

The World Wide Web, restored to 800 pixels of glory.

Home|About|Gaming cabinet|Archives|How it works|Starter sites

On this site

  • Sign in
  • ActionsCI/CD and automation
  • CodespacesCloud development environments
  • All Features
  • Documentation
  • Training
  • Certifications
  • Build with Copilot
  • Customize Copilot
  • Integrations
  • Trending repos
  • GitHub Sponsors
  • Developer articles
  • Enterprises

This view

  • Original page
  • New address

GeezerVison is showing github.com — Musl libc strftime for format strings ending in % · Issue #127527 · python/cpython

Musl libc strftime for format strings ending in % #127527

New issue
Copy link
New issue
Copy link
Open
Open
Musl libc strftime for format strings ending in %#127527
Copy link
Labels
OS-unsupportedextension-modulesC modules in the Modules dirC modules in the Modules dirtype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

Description

@hoodmane
hoodmane
opened on Dec 2, 2024
Issue body actions

In glibc if the format string ends in %, strftime and wcsftime will turn it into a %. In musl libc, if the format string ends in %, both wcsftime and strftime return 0 with errno 0 and leave random stuff in the buffer. There's no way for us to distinguish between this and "out of space" without looking at the format string. The following 7 character patch would fix musl to behave the same as glibc:

--- a/src/time/strftime.c
+++ b/src/time/strftime.c
@@ -225,7 +225,7 @@ size_t __strftime_l(char *restrict s, size_t n, const char
*restrict f, const st
 			s[l] = 0;
 			return l;
		}
-		if (*f != '%') {
+		if (*f != '%' || !f[1]) {
 			s[l++] = *f;
 			continue;
 		}

but it sounds like musl may be against applying this patch because it is their position that the behavior is undefined? See this thread:
https://www.openwall.com/lists/musl/2022/12/19/3

So in this case, we repeatedly get format_string returning 0 and end up here:
https://github.com/python/cpython/blob/main/Modules/timemodule.c?plain=1#L844
Then if HAVE_WCSFTIME we call PyUnicode_FromWideChar(*outbuf, 0) which notices we're making an empty string and returns here:
https://github.com/python/cpython/blob/main/Objects/unicodeobject.c?plain=1#L2004-L2005
On the other hand, if !HAVE_WCSFTIME we call PyUnicode_DecodeLocaleAndSize which checks if str[len] != '\0' and raises ValueError("Embedded null byte") here:
https://github.com/python/cpython/blob/main/Objects/unicodeobject.c?plain=1#L4004

So what to do? Well for one thing, it seems to me that we can tell whether format_time is trying to return an empty string by checking if the string ends in a null byte as it should e.g., *outbuf[buflen] == 0. This can allow us to be a bit more conservative in time_strftime1.

Linked PRs

  • gh-127527: Improve error handling in time_strftime1 #127528

Activity

  1. picnixz
    added
    type-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error
    extension-modulesC modules in the Modules dirC modules in the Modules dir
    on Dec 2, 2024
  2. hoodmane
    added a commit that references this issue on Dec 2, 2024

    pythongh-127527: Improve error handling in time_strftime1

    4615f6d
  3. serhiy-storchaka
    added this to Date and time issues 🕰️on Jun 27, 2025
  4. StanFromIreland
    added
    OS-unsupported
    on Feb 28, 2026
  5. github-project-automation
    added this to Unsupported platformson Feb 28, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    OS-unsupportedextension-modulesC modules in the Modules dirC modules in the Modules dirtype-bugAn unexpected behavior, bug, or errorAn unexpected behavior, bug, or error

    Projects

    • Date and time issues 🕰️
      Status
      No status
      Show more project fields
    • Unsupported platforms
      Status
      No status
      Show more project fields

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

    You are visitor 01402503 — GeezerVison does not store the pages you look up.
    Best viewed with Netscape Navigator 4.7 or Internet Explorer 6 at 800×600. No cookies required.