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.
| Author | belopolsky |
|---|---|
| Recipients | amaury.forgeotdarc, belopolsky, jnferguson |
| Date | 2008年04月09日.01:11:53 |
| SpamBayes Score | 0.013312819 |
| Marked as misclassified | No |
| Message-id | <1207703517.41.0.346526856624.issue2588@psf.upfronthosting.co.za> |
| In-reply-to |
| Content | |
|---|---|
As long as snprintf is used with a fixed size buffer using an idiom snprintf(buffer, sizeof(buffer), ..) there is no issue because sizeof(buffer) cannot be zero. AFAICT, this is how python uses PyOS_vsnprintf wrapper. On the other hand, may this is a good opportunity to revisit the decision to make PyOS_vsnprintf semantics different from C99 vsnprintf. C99 defines snprintf semantics as follows: int snprintf(char *restrict s, size_t n, const char *restrict format, ...); The snprintf() function shall be equivalent to sprintf(), with the addition of the n argument which states the size of the buffer referred to by s. If n is zero, nothing shall be written and s may be a null pointer. Otherwise, output bytes beyond the n-1st shall be discarded instead of being written to the array, and a null byte is written at the end of the bytes actually written into the array. <http://www.opengroup.org/onlinepubs/000095399/functions/printf.html> |
|
| History | |||
|---|---|---|---|
| Date | User | Action | Args |
| 2008年04月09日 01:11:58 | belopolsky | set | spambayes_score: 0.0133128 -> 0.013312819 recipients: + belopolsky, amaury.forgeotdarc, jnferguson |
| 2008年04月09日 01:11:57 | belopolsky | set | spambayes_score: 0.0133128 -> 0.0133128 messageid: <1207703517.41.0.346526856624.issue2588@psf.upfronthosting.co.za> |
| 2008年04月09日 01:11:55 | belopolsky | link | issue2588 messages |
| 2008年04月09日 01:11:54 | belopolsky | create | |