[Python-Dev] datetime's strftime implementation: by design or bug

[Tim Peters]

[Eric V. Smith]
> [I hope this belongs on python-dev, since it's about the design of
> something.  But if not, let me know and I'll post to c.l.py.]
>
> I'm willing to file a bug report and patch on this, but I'd like to know
> if it's by design or not.
>
> In datetimemodule.c, the function wrap_strftime() insists that the
> length of a format string be <= 127 chars, by forcing the length into a
> char.  This seems like a bug to me.  wrap_strftime() calls time's
> strftime(), which doesn't have this limitation because it uses size_t.

Yawn ;-)  I'm very surprised the code doesn't verify that the format
size fits in a C char, but there's nothing deep about the assumption.
I expect it would work fine to just change the declarations of
`totalnew` and `usednew` from `char` to `Py_ssize_t` (for 2.5.1 and
2.6; to something else for 2.4.4 (I don't recall which C type
PyString_Size returned then -- probably `int`)), and /also/ change the
resize-and-overflow check.  The current:

 			int bigger = totalnew << 1;
 			if ((bigger >> 1) != totalnew) { /* overflow */
 				PyErr_NoMemory();
 				goto Done;
 			}

doesn't actually make sense even if it's certain than sizeof(int) is
strictly larger than sizeof(totalnew) (which C guarantees for type
`char`, but is plain false on some boxes if changed to Py_ssize_t).
Someone must have been on heavy drugs when writing that endlessly
tedious wrapper ;-)

> ...