[Bug string/31974] New: glibc incorrectly uses __isoc23_sscanf for C++

[Bug string/31974] New: glibc incorrectly uses __isoc23_sscanf for C++

[euloanty at live dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31974

            Bug ID: 31974
           Summary: glibc incorrectly uses __isoc23_sscanf for C++
           Product: glibc
           Version: unspecified
            Status: UNCONFIRMED
          Severity: critical
          Priority: P2
         Component: string
          Assignee: unassigned at sourceware dot org
          Reporter: euloanty at live dot com
  Target Milestone: ---

#include <features.h>
#include <stdio.h>

int main() {
   const char *input = "42 Alice";
   int number;

   int result = sscanf(input, "%d", &number);

   printf("Parsed number: %d\n", number);

}

g++ -S hello.cc -std=c++11
g++ -S hello.cc -std=c++14
g++ -S hello.cc -std=c++17
g++ -S hello.cc -std=c++20
g++ -S hello.cc -std=c++23

This is insane they all use __isoc23_sscanf in the latest glibc 2.40.

First.
1. C++ does not make the change to sscanf yet.
If we compile it with gcc

gcc -S hello.c -std=c11
gcc -S hello.c -std=c14
gcc -S hello.c -std=c18
gcc -S hello.c -std=c23
Only C23 uses __isoc23_sscanf.

So the macros are just wrong for C++ completely and it breaks GCC, libstdc++,
libc++ and llvm.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug string/31974] glibc incorrectly uses __isoc23_sscanf for C++

[euloanty at live dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31974

cqwrteur <euloanty at live dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |euloanty at live dot com
           Priority|P2                          |P1

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug string/31974] glibc incorrectly uses __isoc23_sscanf for C++

[euloanty at live dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31974

--- Comment #1 from cqwrteur <euloanty at live dot com> ---
Created attachment 15618
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15618&action=edit
proposed patch

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug string/31974] glibc incorrectly uses __isoc23_sscanf for C++

[sam at gentoo dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31974

Sam James <sam at gentoo dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=115907

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug string/31974] glibc incorrectly uses __isoc23_sscanf for C++

[pinskia at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31974

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
                 CC|                            |pinskia at gcc dot gnu.org
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Not a bug. G++ enables _GNU_SOURCE which enables using all extensions including
C23 extensions.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug string/31974] glibc incorrectly uses __isoc23_sscanf for C++

[euloanty at live dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31974

cqwrteur <euloanty at live dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |---

--- Comment #3 from cqwrteur <euloanty at live dot com> ---
I don't want this.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug string/31974] glibc incorrectly uses __isoc23_sscanf for C++

[pinskia at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31974

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=11196

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Again the issue is not in glibc. The issue is g++ defines _GNU_SOURCE which
enables all extensions. 

The g++ issue is recorded as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11196
.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug string/31974] glibc incorrectly uses __isoc23_sscanf for C++

[jwakely.gcc at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31974

Jonathan Wakely <jwakely.gcc at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jwakely.gcc at gmail dot com

--- Comment #5 from Jonathan Wakely <jwakely.gcc at gmail dot com> ---
(In reply to cqwrteur from comment #0)
> 1. C++ does not make the change to sscanf yet.

I've written a proposal to change that.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug string/31974] glibc incorrectly uses __isoc23_sscanf for C++

[euloanty at live dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31974

cqwrteur <euloanty at live dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |---
             Status|RESOLVED                    |UNCONFIRMED

--- Comment #6 from cqwrteur <euloanty at live dot com> ---
i have a better solution

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug string/31974] glibc incorrectly uses __isoc23_sscanf for C++

[euloanty at live dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31974

cqwrteur <euloanty at live dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #15618|0                           |1
        is obsolete|                            |

--- Comment #7 from cqwrteur <euloanty at live dot com> ---
Created attachment 15625
  --> https://sourceware.org/bugzilla/attachment.cgi?id=15625&action=edit
Patch to stabilize abi from 2.34

This patch will stabilize abi and make things much easier since glibc 2.34

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug string/31974] glibc incorrectly uses __isoc23_sscanf for C++

[euloanty at live dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31974

--- Comment #8 from cqwrteur <euloanty at live dot com> ---
(In reply to Jonathan Wakely from comment #5)
> (In reply to cqwrteur from comment #0)
> > 1. C++ does not make the change to sscanf yet.
> 
> I've written a proposal to change that.

I think you need to propose stdbits.h being the same way stdatomic.h is
handleed. It should be just a wrapper around C++20 bit header. _Generic macro
is not something C++ supports and there is no point to support it either since
C++ alternatives are objectively better.

namespace std
{

namespace details
{
template<typename T>
constexpr T stdc_bit_ceil(T x) noexcept
{
return ::std::bit_ceil(x);
}

}

}

using ::std::details::stdc_bit_ceil;

stdc_bit_ceil should wrap around std::bit_ceil. For example.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug string/31974] glibc incorrectly uses __isoc23_sscanf for C++

[euloanty at live dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31974

--- Comment #9 from cqwrteur <euloanty at live dot com> ---
(In reply to cqwrteur from comment #7)
> Created attachment 15625 [details]
> Patch to stabilize abi from 2.34
> 
> This patch will stabilize abi and make things much easier since glibc 2.34

https://github.com/trcrsired/glibc/tree/stableabi

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug string/31974] glibc incorrectly uses __isoc23_sscanf for C++

[schwab@linux-m68k.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31974

Andreas Schwab <schwab@linux-m68k.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P1                          |P3
           Severity|critical                    |enhancement

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug string/31974] glibc incorrectly uses __isoc23_sscanf for C++

[jwakely.gcc at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31974

--- Comment #10 from Jonathan Wakely <jwakely.gcc at gmail dot com> ---
The "stabilise ABI" part of this patch and bug report is nonsense, and not
desired by libstdc++ AT ALL. Please ignore it.

There is a valid point hidden among the noise, which is that __GLIBC_USE
(ISOC23) is true for C++ because G++ defines _GNU_SOURCE (for reasons:
https://gcc.gnu.org/PR11196 and Glibc PR 21327). That means that libstdc++
always gets the C23 library changes, even though no version of C++ is based on
the C23 library.

I doubt that's really a problem for most people. I certainly don't care if
strtol and sscanf accept a 0b prefix in C++20, because I very much doubt that
the correctness of any real C++ programs depends on getting an error from those
functions for a 0b prefix. If you don't want the feature in C++, don't pass
such strings to those functions. This is no different from libstdc++ on
Glibc-based systems getting other GNU extensions that provide features not
specified in C standards.

If it needed to be solved (which again, I don't believe) then a better solution
than the attached patch would be something like:

diff --git a/include/features.h b/include/features.h
index 093de6f44c..bc8e6841dd 100644
--- a/include/features.h
+++ b/include/features.h
@@ -210,12 +210,18 @@
 #ifdef _GNU_SOURCE
 # undef  _ISOC95_SOURCE
 # define _ISOC95_SOURCE        1
+#if ! defined __cplusplus || __cplusplus >= 201103L
 # undef  _ISOC99_SOURCE
 # define _ISOC99_SOURCE        1
+#if ! defined __cplusplus || __cplusplus >= 201703L
 # undef  _ISOC11_SOURCE
 # define _ISOC11_SOURCE        1
+#if ! defined __cplusplus
 # undef  _ISOC23_SOURCE
 # define _ISOC23_SOURCE        1
+#endif
+#endif
+#endif
 # undef  _POSIX_SOURCE
 # define _POSIX_SOURCE 1
 # undef  _POSIX_C_SOURCE

The condition guarding the _ISOC23_SOURCE part could also check __cplusplus >
202400L on the assumption that my proposal to rebase the C++26 library on C23
will be approved.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug string/31974] glibc incorrectly uses __isoc23_sscanf for C++

[euloanty at live dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31974

--- Comment #11 from cqwrteur <euloanty at live dot com> ---
(In reply to Jonathan Wakely from comment #10)
> The "stabilise ABI" part of this patch and bug report is nonsense, and not
> desired by libstdc++ AT ALL. Please ignore it.
> 
> There is a valid point hidden among the noise, which is that __GLIBC_USE
> (ISOC23) is true for C++ because G++ defines _GNU_SOURCE (for reasons:
> https://gcc.gnu.org/PR11196 and Glibc PR 21327). That means that libstdc++
> always gets the C23 library changes, even though no version of C++ is based
> on the C23 library.
> 
> I doubt that's really a problem for most people. I certainly don't care if
> strtol and sscanf accept a 0b prefix in C++20, because I very much doubt
> that the correctness of any real C++ programs depends on getting an error
> from those functions for a 0b prefix. If you don't want the feature in C++,
> don't pass such strings to those functions. This is no different from
> libstdc++ on Glibc-based systems getting other GNU extensions that provide
> features not specified in C standards.
> 
> If it needed to be solved (which again, I don't believe) then a better
> solution than the attached patch would be something like:
> 
> diff --git a/include/features.h b/include/features.h
> index 093de6f44c..bc8e6841dd 100644
> --- a/include/features.h
> +++ b/include/features.h
> @@ -210,12 +210,18 @@
>  #ifdef _GNU_SOURCE
>  # undef  _ISOC95_SOURCE
>  # define _ISOC95_SOURCE        1
> +#if ! defined __cplusplus || __cplusplus >= 201103L
>  # undef  _ISOC99_SOURCE
>  # define _ISOC99_SOURCE        1
> +#if ! defined __cplusplus || __cplusplus >= 201703L
>  # undef  _ISOC11_SOURCE
>  # define _ISOC11_SOURCE        1
> +#if ! defined __cplusplus
>  # undef  _ISOC23_SOURCE
>  # define _ISOC23_SOURCE        1
> +#endif
> +#endif
> +#endif
>  # undef  _POSIX_SOURCE
>  # define _POSIX_SOURCE 1
>  # undef  _POSIX_C_SOURCE
> 
> The condition guarding the _ISOC23_SOURCE part could also check __cplusplus
> > 202400L on the assumption that my proposal to rebase the C++26 library on
> C23 will be approved.

std::format has the same issue bro. They will keep adding more formatters. What
are you going to do after that? It is a complete mess. Format string needs to
be wiped from the phase of earth.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug string/31974] glibc incorrectly uses __isoc23_sscanf for C++

[jwakely.gcc at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31974

--- Comment #12 from Jonathan Wakely <jwakely.gcc at gmail dot com> ---
Try to focus and stay on topic, your irrational hatred of std::format has
nothing to do with this glibc PR. (But it doesn't have the same issue, because
it's header-only so can very easily tailor which format specifiers are
supported based on the current value of __cplusplus, you're mistaken as usual.)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug string/31974] glibc incorrectly uses __isoc23_sscanf for C++

[euloanty at live dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31974

--- Comment #13 from cqwrteur <euloanty at live dot com> ---
(In reply to Jonathan Wakely from comment #12)
> Try to focus and stay on topic, your irrational hatred of std::format has
> nothing to do with this glibc PR. (But it doesn't have the same issue,
> because it's header-only so can very easily tailor which format specifiers
> are supported based on the current value of __cplusplus, you're mistaken as
> usual.)

They will keep adding formatters. Each time you add a new formatter it is an
abi break. What are you going to do?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug string/31974] glibc incorrectly uses __isoc23_sscanf for C++

[jwakely.gcc at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31974

--- Comment #14 from Jonathan Wakely <jwakely.gcc at gmail dot com> ---
It's not an ABI break, but trying to correct your misunderstanding of
std::format is off topic here.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug string/31974] glibc incorrectly uses __isoc23_sscanf for C++

[euloanty at live dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31974

--- Comment #15 from cqwrteur <euloanty at live dot com> ---
(In reply to Jonathan Wakely from comment #14)
> It's not an ABI break, but trying to correct your misunderstanding of
> std::format is off topic here.

It is absolutely an abi break. If you add a new formatter, it changes the
behavior of vformat implementation so you have to use at least versioned symbol
to use the new symbol. What even worse is that it breaks static analysis of the
compiler.

This is also why mingw-w64 cannot just link to microsoft's msvcrt unless you
use ucrt since it is an abi break.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug string/31974] glibc incorrectly uses __isoc23_sscanf for C++

[euloanty at live dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31974

--- Comment #16 from cqwrteur <euloanty at live dot com> ---
(In reply to Jonathan Wakely from comment #14)
> It's not an ABI break, but trying to correct your misunderstanding of
> std::format is off topic here.

Just admit format string is a historical mistake made by C back in 1970s and
the entire industry had paid trillions of dollar on this mistake and we are
still paying. Full stop.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug string/31974] glibc incorrectly uses __isoc23_sscanf for C++

[jwakely.gcc at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31974

Jonathan Wakely <jwakely.gcc at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|jwakely.gcc at gmail dot com       |

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug string/31974] glibc incorrectly uses __isoc23_sscanf for C++

[adhemerval.zanella at linaro dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31974

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |adhemerval.zanella at linaro dot o
                   |                            |rg

--- Comment #17 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to Jonathan Wakely from comment #10)
> The "stabilise ABI" part of this patch and bug report is nonsense, and not
> desired by libstdc++ AT ALL. Please ignore it.
> 
> There is a valid point hidden among the noise, which is that __GLIBC_USE
> (ISOC23) is true for C++ because G++ defines _GNU_SOURCE (for reasons:
> https://gcc.gnu.org/PR11196 and Glibc PR 21327). That means that libstdc++
> always gets the C23 library changes, even though no version of C++ is based
> on the C23 library.
> 
> I doubt that's really a problem for most people. I certainly don't care if
> strtol and sscanf accept a 0b prefix in C++20, because I very much doubt
> that the correctness of any real C++ programs depends on getting an error
> from those functions for a 0b prefix. If you don't want the feature in C++,
> don't pass such strings to those functions. This is no different from
> libstdc++ on Glibc-based systems getting other GNU extensions that provide
> features not specified in C standards.
> 
> If it needed to be solved (which again, I don't believe) then a better
> solution than the attached patch would be something like:
> 
> diff --git a/include/features.h b/include/features.h
> index 093de6f44c..bc8e6841dd 100644
> --- a/include/features.h
> +++ b/include/features.h
> @@ -210,12 +210,18 @@
>  #ifdef _GNU_SOURCE
>  # undef  _ISOC95_SOURCE
>  # define _ISOC95_SOURCE        1
> +#if ! defined __cplusplus || __cplusplus >= 201103L
>  # undef  _ISOC99_SOURCE
>  # define _ISOC99_SOURCE        1
> +#if ! defined __cplusplus || __cplusplus >= 201703L
>  # undef  _ISOC11_SOURCE
>  # define _ISOC11_SOURCE        1
> +#if ! defined __cplusplus
>  # undef  _ISOC23_SOURCE
>  # define _ISOC23_SOURCE        1
> +#endif
> +#endif
> +#endif
>  # undef  _POSIX_SOURCE
>  # define _POSIX_SOURCE 1
>  # undef  _POSIX_C_SOURCE
> 
> The condition guarding the _ISOC23_SOURCE part could also check __cplusplus
> > 202400L on the assumption that my proposal to rebase the C++26 library on
> C23 will be approved.

Hey Jonathan, I think this change make sense, could you send a patch to
libc-alpha?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug string/31974] glibc incorrectly uses __isoc23_sscanf for C++

[euloanty at live dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31974

--- Comment #18 from cqwrteur <euloanty at live dot com> ---
> Hey Jonathan, I think this change make sense, could you send a patch to
> libc-alpha?

For this topic, I've said that to do this, we need to stabilize the abi to a
glibc version and use macros to allow users to change the version like
Microsoft does. That is my solution since it just works on windows. I don't see
why this cannot be applied for glibc. That would just solve the issue here.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug string/31974] glibc incorrectly uses __isoc23_sscanf for C++

[jwakely.gcc at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31974

--- Comment #19 from Jonathan Wakely <jwakely.gcc at gmail dot com> ---
No, I would rather focus my efforts on solving https://gcc.gnu.org/PR11196 and
Glibc PR 21327

If that is solved then G++ won't predefine _GNU_SOURCE, and then it won't be a
problem that _GNU_SOURCE enables all extensions including C23 features.
_GNU_SOURCE *should* enable all features, that's the whole point. The bug is
that G++ defines it whether users want it or not.

I don't think any change is needed for this PR, and I'm muting any further
replies from this PR now.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug string/31974] glibc incorrectly uses __isoc23_sscanf for C++

[jwakely.gcc at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31974

Jonathan Wakely <jwakely.gcc at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jwakely.gcc at gmail dot com

--- Comment #20 from Jonathan Wakely <jwakely.gcc at gmail dot com> ---
(that was in reply to comment 17)

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug string/31974] glibc incorrectly uses __isoc23_sscanf for C++

[jwakely.gcc at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31974

Jonathan Wakely <jwakely.gcc at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|jwakely.gcc at gmail dot com       |

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug string/31974] glibc incorrectly uses __isoc23_sscanf for C++

[adhemerval.zanella at linaro dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31974

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #21 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
As per comment #19.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug string/31974] glibc incorrectly uses __isoc23_sscanf for C++

[euloanty at live dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31974

cqwrteur <euloanty at live dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|INVALID                     |---

--- Comment #22 from cqwrteur <euloanty at live dot com> ---
Stop changing status. It is a bug

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug string/31974] glibc incorrectly uses __isoc23_sscanf for C++

[euloanty at live dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31974

--- Comment #23 from cqwrteur <euloanty at live dot com> ---
(In reply to Adhemerval Zanella from comment #21)
> As per comment #19.

I have said to stabilize the version to 2.34 what's wrong with it?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug string/31974] glibc incorrectly uses __isoc23_sscanf for C++

[euloanty at live dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31974

cqwrteur <euloanty at live dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|enhancement                 |critical
           Priority|P3                          |P2

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug string/31974] glibc incorrectly uses __isoc23_sscanf for C++

[euloanty at live dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31974

--- Comment #24 from cqwrteur <euloanty at live dot com> ---
(In reply to Jonathan Wakely from comment #12)
> Try to focus and stay on topic, your irrational hatred of std::format has
> nothing to do with this glibc PR. (But it doesn't have the same issue,
> because it's header-only so can very easily tailor which format specifiers
> are supported based on the current value of __cplusplus, you're mistaken as
> usual.)

irrational hatred? Do you even know how many security vulnerabilities were
caused by format string and std::format is also very slow and bloated. It is
even much slower than stream. And it breaks abi. It causes trouble for
compilers to sanitize the imports.


https://gist.github.com/Au-lit/447f376101674503aac2d721fcee0cd1

How are those points irrational?

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug string/31974] glibc incorrectly uses __isoc23_sscanf for C++

[euloanty at live dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31974

--- Comment #25 from cqwrteur <euloanty at live dot com> ---
(In reply to cqwrteur from comment #24)
> (In reply to Jonathan Wakely from comment #12)
> > Try to focus and stay on topic, your irrational hatred of std::format has
> > nothing to do with this glibc PR. (But it doesn't have the same issue,
> > because it's header-only so can very easily tailor which format specifiers
> > are supported based on the current value of __cplusplus, you're mistaken as
> > usual.)
> 
> irrational hatred? Do you even know how many security vulnerabilities were
> caused by format string and std::format is also very slow and bloated. It is
> even much slower than stream. And it breaks abi. It causes trouble for
> compilers to sanitize the imports.
> 
> 
> https://gist.github.com/Au-lit/447f376101674503aac2d721fcee0cd1
> 
> How are those points irrational?

santize the inputs

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug string/31974] glibc incorrectly uses __isoc23_sscanf for C++

[euloanty at live dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31974

--- Comment #26 from cqwrteur <euloanty at live dot com> ---
(In reply to cqwrteur from comment #25)
> (In reply to cqwrteur from comment #24)
> > (In reply to Jonathan Wakely from comment #12)
> > > Try to focus and stay on topic, your irrational hatred of std::format has
> > > nothing to do with this glibc PR. (But it doesn't have the same issue,
> > > because it's header-only so can very easily tailor which format specifiers
> > > are supported based on the current value of __cplusplus, you're mistaken as
> > > usual.)
> > 
> > irrational hatred? Do you even know how many security vulnerabilities were
> > caused by format string and std::format is also very slow and bloated. It is
> > even much slower than stream. And it breaks abi. It causes trouble for
> > compilers to sanitize the imports.
> > 
> > 
> > https://gist.github.com/Au-lit/447f376101674503aac2d721fcee0cd1
> > 
> > How are those points irrational?
> 
> santize the inputs

What Are Format String Vulnerabilities?

https://www.invicti.com/blog/web-security/format-string-vulnerabilities/

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug string/31974] glibc incorrectly uses __isoc23_sscanf for C++

[adhemerval.zanella at linaro dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31974

--- Comment #27 from Adhemerval Zanella <adhemerval.zanella at linaro dot org> ---
(In reply to cqwrteur from comment #22)
> Stop changing status. It is a bug

Per Jonathan's comment, I also do not see this as a glibc bug, since
_GNU_SOURCE does intend to enable all GNU extensions, and the two libstdc++
bugs seem more reasonable to be fixed.

Your proposed patch does not make much sense, and conditionalizing some
function definitions to glibc version will be clearly NACKed. But you can try
if someone can review this on libc-alpha.

In any case, your attitude is just alienating people and changing the bug
report will not raise any attention to this issue. Like Jonathan, I will also
mute this bug.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug string/31974] glibc incorrectly uses __isoc23_sscanf for C++

[adhemerval.zanella at linaro dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=31974

Adhemerval Zanella <adhemerval.zanella at linaro dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|adhemerval.zanella at linaro dot o |
                   |rg                          |

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug string/31974] glibc incorrectly uses __isoc23_sscanf for C++

[euloanty at live dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31974

--- Comment #28 from cqwrteur <euloanty at live dot com> ---
(In reply to Adhemerval Zanella from comment #27)
> (In reply to cqwrteur from comment #22)
> > Stop changing status. It is a bug
> 
> Per Jonathan's comment, I also do not see this as a glibc bug, since
> _GNU_SOURCE does intend to enable all GNU extensions, and the two libstdc++
> bugs seem more reasonable to be fixed.
> 
> Your proposed patch does not make much sense, and conditionalizing some
> function definitions to glibc version will be clearly NACKed. But you can
> try if someone can review this on libc-alpha.
> 
> In any case, your attitude is just alienating people and changing the bug
> report will not raise any attention to this issue. Like Jonathan, I will
> also mute this bug.

Why is it NAKed? Do you want people to stick with old GCC versions forever?
Linus Torvalds clearly disagrees.

https://youtu.be/Pzl1B7nB9Kc?si=EBzAdkDUGW6CtXLu

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug string/31974] glibc incorrectly uses __isoc23_sscanf for C++

[euloanty at live dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=31974

--- Comment #29 from cqwrteur <euloanty at live dot com> ---
(In reply to Adhemerval Zanella from comment #27)
> (In reply to cqwrteur from comment #22)
> > Stop changing status. It is a bug
> 
> Per Jonathan's comment, I also do not see this as a glibc bug, since
> _GNU_SOURCE does intend to enable all GNU extensions, and the two libstdc++
> bugs seem more reasonable to be fixed.
> 
> Your proposed patch does not make much sense, and conditionalizing some
> function definitions to glibc version will be clearly NACKed. But you can
> try if someone can review this on libc-alpha.
> 
> In any case, your attitude is just alienating people and changing the bug
> report will not raise any attention to this issue. Like Jonathan, I will
> also mute this bug.

Whatever. i will fight this to the end by maintaining myself and ship binaries
to make glibc irrelevant. i don't give a fk on licensing. Glibc is mine now.

-- 
You are receiving this mail because:
You are on the CC list for the bug.