Commit 93fb2c1
committed
Bring minimum precision inline with spprintf
The precision "minimum" for spprintf was changed in
3f23e6b 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
3f23e6b 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.1 parent fe9b622 commit 93fb2c1
1 file changed
+2
-2
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
580 | 580 | | |
581 | 581 | | |
582 | 582 | | |
583 | | - | |
584 | | - | |
| 583 | + | |
| 584 | + | |
585 | 585 | | |
586 | 586 | | |
587 | 587 | | |
| |||
0 commit comments