sscanf c conversion specifier

[hakre]

Description

The following code:

<?php

$r = sscanf('     ', '%c%n', $c, $n)
and var_dump(compact('r', 'c', 'n'));

Resulted in this output:

array(3) {
  'r' =>
  int(2)
  'c' =>
  string(0) ""
  'n' =>
  int(0)
}

But I expected this output instead:

array(3) {
  'r' =>
  int(2)
  'c' =>
  string(1) " "
  'n' =>
  int(1)
}

---

Expectation by fscanf, scanf, sscanf - convert formatted input, cf. Revision of IEEE Std 1003.1-2008, via Open Group Base Specifications Issue 7, 2018 edition, specifically "[CX] The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of POSIX.1-2017 defers to the ISO C standard", quoting:

The following conversion specifiers are valid:

[...]

• c
  • Matches a sequence of bytes of the number specified by the field width (1 if no field width is present in the conversion specification). No null byte is added. The normal skip over white-space characters shall be suppressed in this case.

For PHP versions older of that date, please refer to the equally older documentation for these dates.

Why is the expectation important?

The c conversion specifier is important to scan over white space characters, so that it adjoins the s conversion specifier (supported by PHP sscanf(), compare #11201 (comment) ) and/or leaving a space character in the $format string (supported by PHP sscanf()).

---

https://3v4l.org/9E2d1

8.4.10

https://3v4l.org/9E2d1	9E2d1

1:	<?php
2:	
3:	$r = sscanf('     ', '%c%n', $c, $n)
4:	and var_dump(compact('r', 'c', 'n'));
5:	
output [versions: 8.4.10 | released 2025-07-03 | took 29 ms, 18.55 MiB]
	O: array(3) {
	O:   ["r"]=>
	O:   int(2)
	O:   ["c"]=>
	O:   string(0) ""
	O:   ["n"]=>
	O:   int(0)
	O: }

+eol:

https://3v4l.org/9E2d1	9E2d1

1:	<?php
2:	
3:	$r = sscanf('     ', '%c%n', $c, $n)
4:	and var_dump(compact('r', 'c', 'n'));
5:	
output [versions: 4.3.2 - 4.3.11, 4.4.0 - 4.4.9, 5.0.0 - 5.0.5, 5.1.0 - 5.1.6, 5.2.0 - 5.2.17, 5.3.0 - 5.3.29, 5.4.0 - 5.4.45, 5.5.0 - 5.5.38, 5.6.0 - 5.6.40, 7.0.4 - 7.0.33, 7.1.0 - 7.1.33, 7.2.0 - 7.2.34, 7.3.0 - 7.3.33, 7.4.0 - 7.4.33, 8.0.0 - 8.0.30, 8.1.0 - 8.1.33, 8.2.0 - 8.2.29, 8.3.0 - 8.3.23, 8.4.1 - 8.4.10]
	O: array(3) {
	O:   ["r"]=>
	O:   int(2)
	O:   ["c"]=>
	O:   string(0) ""
	O:   ["n"]=>
	O:   int(0)
	O: }
output [versions: 7.0.0 - 7.0.3]
	O: array(3) {
	O:   ["r"]=>
	O:   int(2)
	O:   ["c"]=>
	O:   &string(0) ""
	O:   ["n"]=>
	O:   &int(0)
	O: }
output [versions: 4.3.0 - 4.3.1]
	O: array(3) {
	O:   ["r"]=>
	O:   int(2)
	O:   ["c"]=>
	O:   string(0) ""
	O:   ["n"]=>
	O:   string(0) ""
	O: }

PHP Version

PHP 8.4.10 (cli) (built: Jul  3 2025 12:41:53) (NTS)
Copyright (c) The PHP Group
Built by Debian
Zend Engine v4.4.10, Copyright (c) Zend Technologies
    with Zend OPcache v8.4.10, Copyright (c), by Zend Technologies
    with Xdebug v3.4.4, Copyright (c) 2002-2025, by Derick Rethans

Operating System

No response

[hakre]

Only an educated guess looking at the 3v4l.org outputs provided above, it looks to me in my layman view that originally there was primary format scanning, less conversion, which makes somewhat sense in string-typed-mixed. Have not yet located and looked into the implementation, my nose guesses some benefits of %c sharing with %s and then %c inherits the space scanning behaviour from %s. (early only)

[nielsdos]

On first sight, the implementation indeed shares code to skip spaces between 'c' and 's'.
Also, why is the return value 2? In C it's 1 because %n doesn't count as a field.

[nielsdos]

Likely caused by width handling, as comments in this file state:

we differ here with the TCL implementation in allowing for a character width specification, to be more consistent with ANSI.

[nielsdos]

This is not fixable without breaking the width specifier behaviour for '%c'...
That's because the minimum width by definition is 1 (0 gets mapped to "unlimited"), and 1 means that 1 space can be skipped...
EDIT: actually, I may be wrong, let me double check...

[nielsdos]

The problem is indeed the width and white space skipping. The code loops until it finds the first space and cuts the string there. If you have all spaces then both 's' and 'c' will return an empty string. Similarly, using '%c' on ' x' will also give an empty string. This is all a consequence of allowing width specifiers (and consequently whitespace skipping) on '%c'. Diverging from that is a BC break as some people may rely on that.
It seems reasonable to me however that a '%c' specifier consumes at least 1 character. The following patch would do but I'm not sure if that makes the weirdness worse or not. Now you have the weirdness in that both '%c' and '%2c' on ' x' return ' '

diff --git a/ext/standard/scanf.c b/ext/standard/scanf.c
index 408e5ede888..38235783d95 100644
--- a/ext/standard/scanf.c
+++ b/ext/standard/scanf.c
@@ -779,7 +779,7 @@ PHPAPI int php_sscanf_internal( char *string, char *format,
 				break;
 
 			case 'c':
-				op = 's';
+				op = 'c';
 				flags |= SCAN_NOSKIP;
 				/*-cc-*/
 				if (0 == width) {
@@ -843,6 +843,10 @@ PHPAPI int php_sscanf_internal( char *string, char *format,
 					   break;
 					}
 				}
+				if (op == 'c' && end == string) {
+					/* Consume a minimum of 1 character */
+					end++;
+				}
 				if (!(flags & SCAN_SUPPRESS)) {
 					if (numVars && objIndex >= argCount) {
 						break;

[hakre]

@nielsdos thanks for picking this up so quickly and taking care from the current implementations side with which I'm weak.

In my understanding it is important that %[*][<max-len>]c works immune to whitespace as otherwise there is no gain over s and ' ' (zero or more white space characters.)

But I must admit I still have not looked into the implementation, so if this crosses current abstractions it may indeed demand an own path (perhaps early) solely for c. IMHO this would make sense as there effectively is no need to deal with any kind of character classes. As the width specifier (number in front of c, allowing 0 would be a benefit in my book, but I don't demand this as a feature/extension) "the width specifier" is maximum length, from my rudimentary understanding this should™ be straight forward to inline, doesn't it?

I can hardly imagine anyone is relying on the (indeed longtime) flawed behaviour, because all other format specifiers are only useful as %c ain't (because it's broken). This rationale also underlined by various online resources where everyone either resonates about %s not scanning over white-space (which is actually long-time documented behaviour for what s is actually for) or giving the advice to use a character class with a single negated character to achieve that (can confirm this is working, but only %c allows all characters, not all - 1 characters as in the negated class; e.g. %[^\n] for PHP fscanf() or %[^\1] for PHP sscanf() in roughly ~20 years old comments in our beloved docs.)

[!BREAKOUT-DOCS]
Mentioning docs slightly, I'm already thinking about aligning sscanf() / fscanf() to be better en-par with sprintf() etc. as currently the docs create the impression (at least to me) too much that format specifiers for scanning would be 1:1 the same as for printing, but that is absolutely not the case. Some characters may look the same or similar, and their meaning may transpose over context of use, but their role/consequence is effectively driven by the functionality and formatting is not scanning after all (sprintf() got more love, so I write it this way round, but equality demands to write it the other way round as well.)

Given I'm already able to write regression tests as .phpt files, when actually considering to do so, then what would be a good branch name for that in your opinion/workflow? @nielsdos

[hakre]

so we can see two different defects at first glance

1. %c skips over white-space characters (what drove me to create the report)

   • c
     • Matches a sequence of bytes of the number specified by the field width (1 if no field width is present in the conversion specification). No null byte is added. The normal skip over white-space characters shall be suppressed in this case.

2. %n adds to result count (unnoticed so far by me)

   • n
     • No input is consumed. The application shall ensure that the corresponding argument is a pointer to the integer into which shall be written the number of bytes read from the input so far by this call to the fscanf() functions. Execution of a %n conversion specification shall not increment the assignment count returned at the completion of execution of the function. No argument shall be converted, but one shall be consumed. If the conversion specification includes an assignment-suppressing character or a field width, the behavior is undefined.

from my own understanding, the parts about the memory management can be ignored in PHP because for both %c and %s for example the function assigns PHP strings (or NULL) to the related parameter-out (if returning) or a member in the returned array. also adding null bytes or not are not a thing in PHP strings as the size of a string is not marked with a null bytes IIRC.

my guess on the second defect is that perhaps one count on the array is done, but that is speculation.

it is perhaps worth to address the numbering problem first, just thinking loud. and for that there should be a concrete report with at least one case. and likely more bug clustering.

[hakre]

Diverging from that is a BC break as some people may rely on that.

Yes, we have behavioral change when fixing these. Additionally the format specifiers in PHP are little documented, that is not only a BC break but also requires some good preparation already before changing. I'll do some experiments in PHP to find out more.

[nielsdos]

In my understanding it is important that %[*][]c works immune to whitespace as otherwise there is no gain over s and ' ' (zero or more white space characters.)

Yeah I agree, the current behaviour is very weird, but I wonder how big the BC break is to change this.

As the width specifier (number in front of c, allowing 0 would be a benefit in my book, but I don't demand this as a feature/extension) "the width specifier" is maximum length, from my rudimentary understanding this should™ be straight forward to inline, doesn't it?

Yes

I can hardly imagine anyone is relying on the (indeed longtime) flawed behaviour

This is something I learned the hard way when doing maintenance on PHP: people rely on all sorts of weird and buggy behaviour. Sometimes they don't even realize they rely on that.

Given I'm already able to write regression tests as .phpt files, when actually considering to do so, then what would be a good branch name for that in your opinion/workflow? @nielsdos

The name really doesn't matter. Nowadays I name my branches fix-ghissuenr

it is perhaps worth to address the numbering problem first, just thinking loud. and for that there should be a concrete report with at least one case. and likely more bug clustering.

I think at least this can be fixed separately without too much issues. The fix should likely still only target master though.