[PATCH] sscanf.3: Document exact matching for %c

[PATCH] sscanf.3: Document exact matching for %c

[Florian Weimer]

The glibc manual has always documented this behavior, but the
implementation differed, treating the field width as an upper limit.

Signed-off-by: Florian Weimer <fweimer@redhat.com>

---
 man/man3/sscanf.3 | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/man/man3/sscanf.3 b/man/man3/sscanf.3
index f0b248518..fa4cd0db7 100644
--- a/man/man3/sscanf.3
+++ b/man/man3/sscanf.3
@@ -172,6 +172,9 @@ and these discarded characters don't count toward the maximum field width.
 String input conversions store a terminating null byte (\[aq]\[rs]0\[aq])
 to mark the end of the input;
 the maximum field width does not include this terminator.
+Some conversions require exactly
+the number of characters specified in the maximum field width,
+or they fail.
 .TP
 \[bu]
 An optional
@@ -480,6 +483,10 @@ and there must be enough room for all the characters
 (no terminating null byte is added).
 The usual skip of leading white space is suppressed.
 To skip white space first, use an explicit space in the format.
+.\" glibc commit 2b16c76609350ec887d49afd4447743da38f7fab
+This conversion only succeeds
+if the number of characters specified by the maximum field
+can be matched.
 .TP
 .B \&[
 Matches a nonempty sequence of characters from the specified set of

base-commit: 081d4f6779ac39da0265cac6e67d1c9a281e6990

Re: [PATCH] sscanf.3: Document exact matching for %c

[Carlos O'Donell]

On 11/28/25 10:50 AM, Florian Weimer wrote:
> The glibc manual has always documented this behavior, but the
> implementation differed, treating the field width as an upper limit.
> 
> Signed-off-by: Florian Weimer <fweimer@redhat.com>

LGTM and is better than before.

Reviewed-by: Carlos O'Donell <carlos@redhat.com>

> ---
>   man/man3/sscanf.3 | 7 +++++++
>   1 file changed, 7 insertions(+)
> 
> diff --git a/man/man3/sscanf.3 b/man/man3/sscanf.3
> index f0b248518..fa4cd0db7 100644
> --- a/man/man3/sscanf.3
> +++ b/man/man3/sscanf.3
> @@ -172,6 +172,9 @@ and these discarded characters don't count toward the maximum field width.
>   String input conversions store a terminating null byte (\[aq]\[rs]0\[aq])
>   to mark the end of the input;
>   the maximum field width does not include this terminator.
> +Some conversions require exactly
> +the number of characters specified in the maximum field width,
> +or they fail.

OK. Correct, in particular "%c" operates this way.

>   .TP
>   \[bu]
>   An optional
> @@ -480,6 +483,10 @@ and there must be enough room for all the characters
>   (no terminating null byte is added).
>   The usual skip of leading white space is suppressed.
>   To skip white space first, use an explicit space in the format.
> +.\" glibc commit 2b16c76609350ec887d49afd4447743da38f7fab
> +This conversion only succeeds
> +if the number of characters specified by the maximum field
> +can be matched.

OK. Adds clarifying text to the "c" specificer text later in the page.

>   .TP
>   .B \&[
>   Matches a nonempty sequence of characters from the specified set of
> 
> base-commit: 081d4f6779ac39da0265cac6e67d1c9a281e6990
> 
> 


-- 
Cheers,
Carlos.

Re: [PATCH] sscanf.3: Document exact matching for %c

[Alejandro Colomar]

[-- Attachment #1: Type: text/plain, Size: 2109 bytes --]

Hi Florian, Carlos,

On Mon, Dec 01, 2025 at 08:32:18AM -0500, Carlos O'Donell wrote:
> On 11/28/25 10:50 AM, Florian Weimer wrote:
> > The glibc manual has always documented this behavior, but the
> > implementation differed, treating the field width as an upper limit.
> > 
> > Signed-off-by: Florian Weimer <fweimer@redhat.com>
> 
> LGTM and is better than before.
> 
> Reviewed-by: Carlos O'Donell <carlos@redhat.com>

Thanks!  I've applied the patch, and appended the tag.

Have a lovely day!
Alex

> 
> > ---
> >   man/man3/sscanf.3 | 7 +++++++
> >   1 file changed, 7 insertions(+)
> > 
> > diff --git a/man/man3/sscanf.3 b/man/man3/sscanf.3
> > index f0b248518..fa4cd0db7 100644
> > --- a/man/man3/sscanf.3
> > +++ b/man/man3/sscanf.3
> > @@ -172,6 +172,9 @@ and these discarded characters don't count toward the maximum field width.
> >   String input conversions store a terminating null byte (\[aq]\[rs]0\[aq])
> >   to mark the end of the input;
> >   the maximum field width does not include this terminator.
> > +Some conversions require exactly
> > +the number of characters specified in the maximum field width,
> > +or they fail.
> 
> OK. Correct, in particular "%c" operates this way.
> 
> >   .TP
> >   \[bu]
> >   An optional
> > @@ -480,6 +483,10 @@ and there must be enough room for all the characters
> >   (no terminating null byte is added).
> >   The usual skip of leading white space is suppressed.
> >   To skip white space first, use an explicit space in the format.
> > +.\" glibc commit 2b16c76609350ec887d49afd4447743da38f7fab
> > +This conversion only succeeds
> > +if the number of characters specified by the maximum field
> > +can be matched.
> 
> OK. Adds clarifying text to the "c" specificer text later in the page.
> 
> >   .TP
> >   .B \&[
> >   Matches a nonempty sequence of characters from the specified set of
> > 
> > base-commit: 081d4f6779ac39da0265cac6e67d1c9a281e6990
> > 
> > 
> 
> 
> -- 
> Cheers,
> Carlos.
> 
> 

-- 
<https://www.alejandro-colomar.es>
Use port 80 (that is, <...:80/>).

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]