* [Bug 215844] New: scanf manpage incorrectly says that ll (ell-ell) is equivalent to L
@ 2022-04-16 10:58 bugzilla-daemon
2022-04-16 18:21 ` [Bug 215844] " bugzilla-daemon
0 siblings, 1 reply; 2+ messages in thread
From: bugzilla-daemon @ 2022-04-16 10:58 UTC (permalink / raw)
To: linux-man
https://bugzilla.kernel.org/show_bug.cgi?id=215844
Bug ID: 215844
Summary: scanf manpage incorrectly says that ll (ell-ell) is
equivalent to L
Product: Documentation
Version: unspecified
Hardware: All
OS: Linux
Status: NEW
Severity: normal
Priority: P1
Component: man-pages
Assignee: documentation_man-pages@kernel-bugs.osdl.org
Reporter: rootkea@gmail.com
Regression: No
Hello!
manpage of scanf says that "Specifying two l characters is equivalent to L".
But that's not true.
Please check the following code snippet:
#include <stdio.h>
int main(void)
{
long double ld;
long long n;
scanf("%Lf", &ld);
scanf("%llf", &ld);
scanf("%Ln", &n);
scanf("%lln", &n);
return 0;
}
gcc throws these warnings correctly:
warning: use of ‘ll’ length modifier with ‘f’ type character has either no
effect or undefined behavior [-Wformat=]
9 | scanf("%llf", &ld);
| ^
warning: use of ‘L’ length modifier with ‘n’ type character has either no
effect or undefined behavior [-Wformat=]
11 | scanf("%Ln", &n);
| ^
I think, we need to add separate entry for `ll` (ell-ell) like printf(3).
Also, another related issue is that scanf(3) doesn't mention that conversion
specifiers like `%Ld`, `%Li` etc. are GNU nonstandard extensions unlike
printf(3) which clearly mentions the nonportable part.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply [flat|nested] 2+ messages in thread
* [Bug 215844] scanf manpage incorrectly says that ll (ell-ell) is equivalent to L
2022-04-16 10:58 [Bug 215844] New: scanf manpage incorrectly says that ll (ell-ell) is equivalent to L bugzilla-daemon
@ 2022-04-16 18:21 ` bugzilla-daemon
0 siblings, 0 replies; 2+ messages in thread
From: bugzilla-daemon @ 2022-04-16 18:21 UTC (permalink / raw)
To: linux-man
https://bugzilla.kernel.org/show_bug.cgi?id=215844
--- Comment #1 from Alejandro Colomar (man-pages) (alx.manpages@gmail.com) ---
Relevant documents:
POSIX:
<https://pubs.opengroup.org/onlinepubs/9699919799/functions/fscanf.html>
glibc:
<https://www.gnu.org/software/libc/manual/html_mono/libc.html#Numeric-Input-Conversions>
ISO C2x:
<http://www.open-std.org/JTC1/SC22/WG14/www/docs/n2731.pdf#subsubsection.7.21.6.2>
Still, from the documentation linked above, it seems to me that
"%Ln" is supported as a glibc extension, and doesn't fall into
"either no effect or undefined behavior" as says the GCC warning
shown in the bugzilla report. I didn't modify the documentation
regarding %n, and recommend investigating a possible GCC bug.
Reported-by: Avinash Sonawane <rootkea@gmail.com>
Link: bugzilla <https://bugzilla.kernel.org/show_bug.cgi?id=215844>
Cc: glibc <libc-alpha@sourceware.org>
Cc: GCC <gcc@gcc.gnu.org>
Signed-off-by: Alejandro Colomar <alx.manpages@gmail.com>
---
man3/scanf.3 | 35 ++++++++++++++++++++++++++---------
1 file changed, 26 insertions(+), 9 deletions(-)
diff --git a/man3/scanf.3 b/man3/scanf.3
index 55058f3d2..199c8a19a 100644
--- a/man3/scanf.3
+++ b/man3/scanf.3
@@ -308,10 +308,6 @@ and the next pointer is a pointer to
.I double
(rather than
.IR float ).
-Specifying two
-.B l
-characters is equivalent to
-.BR L .
If used with
.B %c
or
@@ -320,12 +316,33 @@ the corresponding parameter is considered
as a pointer to a wide character or wide-character string respectively.
.\" This use of l was introduced in Amendment 1 to ISO C90.
.TP
+.B ll
+(ell-ell)
+Indicates that the conversion will be one of
+.BR b ,
+.BR d ,
+.BR i ,
+.BR o ,
+.BR u ,
+.BR x ,
+.BR X ,
+or
+.B n
+and the next pointer is a pointer to a
+.I long long
+or
+.I unsigned long long
+(rather than
+.IR int ).
+.TP
.B L
Indicates that the conversion will be either
\fBe\fP, \fBf\fP, or \fBg\fP
and the next pointer is a pointer to
.I "long double"
-or the conversion will be
+or
+(as a GNU extension)
+the conversion will be
\fBd\fP, \fBi\fP, \fBo\fP, \fBu\fP, or \fBx\fP
and the next pointer is a pointer to
.IR "long long" .
@@ -683,17 +700,17 @@ floating-point conversion specifier (and is unaffected by
etc.).
.SH BUGS
All functions are fully C89 conformant, but provide the
-additional specifiers
+additional modifiers
.B q
and
.B a
as well as an additional behavior of the
.B L
and
-.B l
-specifiers.
+.B ll
+modifiers.
The latter may be considered to be a bug, as it changes the
-behavior of specifiers defined in C89.
+behavior of modifiers defined in C89.
.PP
Some combinations of the type modifiers and conversion
specifiers defined by ANSI C do not make sense
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply related [flat|nested] 2+ messages in thread
end of thread, other threads:[~2022-04-16 18:21 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-04-16 10:58 [Bug 215844] New: scanf manpage incorrectly says that ll (ell-ell) is equivalent to L bugzilla-daemon
2022-04-16 18:21 ` [Bug 215844] " bugzilla-daemon
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.