This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: detect %zd format for PY_FORMAT_SIZE_T
Type: Stage:
Components: Build Versions:
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: brett.cannon Nosy List: brett.cannon, loewis
Priority: normal Keywords: patch

Created on 2006-04-23 06:18 by brett.cannon, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
zd_printf.diff brett.cannon, 2006-04-23 06:18 patch configure.in to detect if printf() supports %zd
zd_printf.diff brett.cannon, 2006-04-27 04:59 version 2, now with strchr() checks!
zd_printf.diff brett.cannon, 2006-04-27 05:16 version 3, using strncmp()
zd_printf.diff brett.cannon, 2006-04-28 04:51 version 4, using a char array
Messages (7)
msg50094 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2006-04-23 06:18
The patch modifies configure.in to add PY_FORMAT_SIZE_T
to configure.in (meaning you need to run autoheader on
configure.in) so that if %zd is supported for size_t it
sets PY_FORMAT_SIZE_T to "z", otherwise it goes
undefined and the preprocessor trickery in
Include/pyport.h kicks in.

This fix removes compiler warnings on OS X 10.4.6 with
gcc 4.0.1 thanks to PY_FORMAT_SIZE_T being set to "".

Initially assigned to Martin v. Loewis since he said
this would be good to do and the Py_ssize_t stuff is
his invention.
msg50095 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2006-04-26 16:15
Logged In: YES 
user_id=21627

The patch seems to rely on printf returning <0 for the
unrecognized format. That seems unreliable: atleast on
Linux, printf just outputs the format as-is for unrecognized
formats. Instead, I think it should use sprintf, and then
check whether the result is the string "0" (in addition to
checking whether the printf call itself failed).
msg50096 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2006-04-27 04:59
Logged In: YES 
user_id=357491

OK, uploaded a new version that uses strchr to check for
'%', 'z', and 'd'.  If it looks reasonable I will apply it
and hope I don't break the buildbot.  =)
msg50097 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2006-04-27 05:16
Logged In: YES 
user_id=357491

Realized there is a better way: just strncmp() for the
expected result.  Uploaded a new version.
msg50098 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2006-04-27 05:29
Logged In: YES 
user_id=21627

Looks fine to me, although it has "unusual" style of C:

- sizeof(char) is guaranteed to be 1 by the C standard. The
C standard defines "char" and "byte" as synonyms, even if
that means that "byte" has more than 8 bits. sizeof gives
the number of bytes, so for char, it is always 1.

- for a fixed-size array, people would normally make this an
automatic (stack) variable, instead of bothering with
explicit memory allocation, i.e.

  char str_buffer[4]

Just out of fear of buffer overruns, many people would also
add some horrendous overallocation, such as str_buffer[1024] :-)
msg50099 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2006-04-28 04:51
Logged In: YES 
user_id=357491

Yeah, I tried to use a string constant as a stack value, but
that didn't work.  =)  My brain just was not thinking in C
when I first came up with the patch.

I have a new version that uses a char array as the buffer. 
I am on vacation so I don't have the time to apply it and
break buildbot, so I will hold off on applying if no one
finds problems with this version.
msg50100 - (view) Author: Brett Cannon (brett.cannon) * (Python committer) Date: 2006-05-11 05:15
Logged In: YES 
user_id=357491

Applied in r45960 .
History
Date User Action Args
2022-04-11 14:56:17adminsetgithub: 43264
2006-04-23 06:18:12brett.cannoncreate