From 93fb2c12b90dc5bec261ae7150ba219d748db1de Mon Sep 17 00:00:00 2001 From: Derick Rethans Date: Mon, 30 Jan 2023 18:57:12 +0000 Subject: [PATCH] Bring minimum precision inline with spprintf MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The precision "minimum" for spprintf was changed in 3f23e6bca90545a180ac4dbc80712065b1281d74 with the cryptic comment "Enable 0 mode for echo/print". Since then the behaviour of spprintf and snprintf has not been the same. This results in some APIs handling precision differently than others, which then resulted in the following Xdebug issue: https://bugs.xdebug.org/view.php?id=2151 The "manpage" for snprinf says about precision: An optional precision, in the form of a period ('.') followed by an optional decimal digit string. Instead of a decimal digit string one may write "*" or "*m$" (for some decimal integer m) to specify that the precision is given in the next argument, or in the m-th argument, re‐ spectively, which must be of type int. If the precision is given as just '.', the precision is taken to be zero. A negative precision is taken as if the precision were omitted. However, the snprintf implementation never supported this "negative precision", which is what PHP's default setting is in PG(precision). However, in 3f23e6bca90545a180ac4dbc80712065b1281d74 spprintf was made to support this. Although this techinically can break BC, there is clearly a bug here, and I could not see any failing tests locally. --- main/snprintf.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/main/snprintf.c b/main/snprintf.c index 3c379c5c2ce..9acd4efe6d7 100644 --- a/main/snprintf.c +++ b/main/snprintf.c @@ -580,8 +580,8 @@ static size_t format_converter(buffy * odp, const char *fmt, va_list ap) /* {{{ } else if (*fmt == '*') { precision = va_arg(ap, int); fmt++; - if (precision < 0) - precision = 0; + if (precision < -1) + precision = -1; } else precision = 0; } else