[Bug libstdc++/110149] New: std::format for pointer arguments allows a '0' option

[Bug libstdc++/110149] New: std::format for pointer arguments allows a '0' option

[bruno at clisp dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110149

            Bug ID: 110149
           Summary: std::format for pointer arguments allows a '0' option
           Product: gcc
           Version: 13.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bruno at clisp dot org
  Target Milestone: ---

Created attachment 55275
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55275&action=edit
test case bug.cc

In C++ 20, a sign, a '#' option, and a '0' option are disallowed for
std::format strings with a pointer argument. The text has the same language for
all three:

In https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/n4950.pdf
§ 22.14.2.2 Standard format specifiers [format.string.std]
Paragraph 5: "The sign option is only valid for arithmetic types other than
charT and bool or when an integer presentation type is specified."
Paragraph 7: "The # option .... This option is valid for arithmetic types other
than charT and bool or when an integer presentation type is specified, and not
otherwise."
Paragraph 8: "The 0 option is valid for arithmetic types other than charT and
bool or when an integer presentation type is specified."

Paragraph 21 specifies the available integer presentation types; 'p' is not one
of them, it is listed in paragraph 25 instead.

Therefore in the attached program bug.cc, an error should be signalled in line
28 and in line 29.

How to reproduce:
1)
$ g++ -Wall -std=gnu++20 bug.cc
<no error>
2) Enable line 18 or line 19 or line 23 or line 24.
$ g++ -Wall -std=gnu++20 bug.cc
<compilation error>

Note also that the '0' option cannot be part of a width specification, because
the width cannot start with '0'.

[Bug libstdc++/110149] std::format for pointer arguments allows a '0' option

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110149

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
0p is proposed by
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2510r3.pdf

[Bug libstdc++/110149] std::format for pointer arguments allows a '0' option

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110149

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
GCC's formatter<const void*, charT> specialization has:

        // _GLIBCXX_RESOLVE_LIB_DEFECTS
        // P2519R3 Formatting pointers
        __first = __spec._M_parse_zero_fill(__first, __last);
        if (__finished())
          return __first;

        __first = __spec._M_parse_width(__first, __last, __pc);

        if (__first != __last && (*__first == 'p' || *__first == 'P'))
          {
            if (*__first == 'P')
              __spec._M_type = __format::_Pres_P;
            ++__first;
          }

Arguably, P2591 is not fixing a defect and so parsing '0' and 'P' could be
guarded behind a check for #if __cplusplus > 202302L but I think it's more
useful to treat this as a fix for C++20 and C++23, not just a C++26 change.

[Bug libstdc++/110149] std::format for pointer arguments allows a '0' option

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110149

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
It looks like I forgot to actually format using 'P' though, I only parsed it
from the format string.

This would fix that, and disable the P2519 changes for -std=c++20 and
-std=c++23:

--- a/libstdc++-v3/include/std/format
+++ b/libstdc++-v3/include/std/format
@@ -2081,19 +2081,29 @@ namespace __format
        if (__finished())
          return __first;

+#if __cplusplus > 202302L || ! defined __STRICT_ANSI__
        // _GLIBCXX_RESOLVE_LIB_DEFECTS
        // P2519R3 Formatting pointers
        __first = __spec._M_parse_zero_fill(__first, __last);
        if (__finished())
          return __first;
+#endif

        __first = __spec._M_parse_width(__first, __last, __pc);

-       if (__first != __last && (*__first == 'p' || *__first == 'P'))
+       if (__first != __last)
          {
-           if (*__first == 'P')
+           if (*__first == 'p')
+             ++__first;
+#if __cplusplus > 202302L || ! defined __STRICT_ANSI__
+           else if (*__first == 'P'))
+           {
+             // _GLIBCXX_RESOLVE_LIB_DEFECTS
+             // P2519R3 Formatting pointers
              __spec._M_type = __format::_Pres_P;
-           ++__first;
+             ++__first;
+           }
+#endif
          }

        if (__finished())
@@ -2113,6 +2123,18 @@ namespace __format
          const int __n = __ptr - __buf;
          __buf[0] = '0';
          __buf[1] = 'x';
+#if __cplusplus > 202302L || ! defined __STRICT_ANSI__
+         if (_M_spec._M_type == _Pres_)
+           {
+             __buf[1] = 'X';
+             for (auto __p = __buf + 2; __p != __res.ptr; ++__p)
+#if __has_builtin(__builtin_toupper)
+               *__p = __builtin_toupper(*__p);
+#else
+               *__p = std::toupper(*__p);
+#endif
+           }
+#endif

          basic_string_view<_CharT> __str;
          if constexpr (is_same_v<_CharT, char>)

[Bug libstdc++/110149] std::format for pointer arguments allows a '0' option

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110149

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |redi at gcc dot gnu.org
   Last reconfirmed|                            |2023-06-08
             Status|UNCONFIRMED                 |ASSIGNED
   Target Milestone|---                         |13.2
     Ever confirmed|0                           |1

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I plan to support the P2510 changes unconditionally in C++20 mode, i.e. treat
it as a DR against C++20. But it should actually work as proposed by P2510, and
it seems that I only half implemented it so far.

[Bug libstdc++/110149] std::format for pointer arguments allows a '0' option

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110149

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:

https://gcc.gnu.org/g:628ba410b9265dbd4278c1f1b1fadf05348adef2

commit r14-1648-g628ba410b9265dbd4278c1f1b1fadf05348adef2
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Thu Jun 8 21:35:21 2023 +0100

    libstdc++: Fix P2510R3 "Formatting pointers" [PR110149]

    I had intended to support the P2510R3 proposal unconditionally in C++20
    mode, but I left it half implemented. The parse function supported the
    new extensions, but the format function didn't.

    This adds the missing pieces, and makes it only enabled for C++26 and
    non-strict modes.

    libstdc++-v3/ChangeLog:

            PR libstdc++/110149
            * include/std/format (formatter<const void*, charT>::parse):
            Only alow 0 and P for C++26 and non-strict modes.
            (formatter<const void*, charT>::format): Use toupper for P
            type, and insert zero-fill characters for 0 option.
            * testsuite/std/format/functions/format.cc: Check pointer
            formatting. Only check P2510R3 extensions conditionally.
            * testsuite/std/format/parse_ctx.cc: Only check P2510R3
            extensions conditionally.

[Bug libstdc++/110149] std::format for pointer arguments allows a '0' option

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110149

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Fixed on trunk so far, backport to follow.

[Bug libstdc++/110149] std::format for pointer arguments allows a '0' option

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110149

--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
<redi@gcc.gnu.org>:

https://gcc.gnu.org/g:ae7cdc8c0f5278e7941f1de7c72ffe9f1fed2775

commit r13-7510-gae7cdc8c0f5278e7941f1de7c72ffe9f1fed2775
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Thu Jun 8 21:35:21 2023 +0100

    libstdc++: Fix P2510R3 "Formatting pointers" [PR110149]

    I had intended to support the P2510R3 proposal unconditionally in C++20
    mode, but I left it half implemented. The parse function supported the
    new extensions, but the format function didn't.

    This adds the missing pieces, and makes it only enabled for C++26 and
    non-strict modes.

    libstdc++-v3/ChangeLog:

            PR libstdc++/110149
            * include/std/format (formatter<const void*, charT>::parse):
            Only alow 0 and P for C++26 and non-strict modes.
            (formatter<const void*, charT>::format): Use toupper for P
            type, and insert zero-fill characters for 0 option.
            * testsuite/std/format/functions/format.cc: Check pointer
            formatting. Only check P2510R3 extensions conditionally.
            * testsuite/std/format/parse_ctx.cc: Only check P2510R3
            extensions conditionally.

    (cherry picked from commit 628ba410b9265dbd4278c1f1b1fadf05348adef2)

[Bug libstdc++/110149] std::format for pointer arguments allows a '0' option

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110149

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Fixed for GCC 13.2