[Bug c++/95596] New: string literal wrong overload resolution (char* vs std::string)

[Bug c++/95596] New: string literal wrong overload resolution (char* vs std::string)

[bzsurr at protonmail dot com]

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

            Bug ID: 95596
           Summary: string literal wrong overload resolution (char* vs
                    std::string)
           Product: gcc
           Version: 10.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bzsurr at protonmail dot com
  Target Milestone: ---

Looking at the following code gcc calls the _char*_ overload, according to the
standard the string literal is of type const array of char, so the non const
char pointer should not be part of the overload set.

#include <cstdio>
#include <string>
void foo(char*) { puts("char*"); }
void foo(std::string) { puts("std::string"); }
int main()
{
    foo("Hello World");
}


Compiler Explorer Link:
https://godbolt.org/z/82D4LT

[Bug c++/95596] string literal wrong overload resolution (char* vs std::string)

[bzsurr at protonmail dot com]

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

--- Comment #1 from bzsurr at protonmail dot com ---
(In reply to bzsurr from comment #0)
> Looking at the following code gcc calls the _char*_ overload, according to
> the standard the string literal is of type const array of char, so the non
> const char pointer should not be part of the overload set.
> 
> #include <cstdio>
> #include <string>
> void foo(char*) { puts("char*"); }
> void foo(std::string) { puts("std::string"); }
> int main()
> {
>     foo("Hello World");
> }
> 
> 
> Compiler Explorer Link:
> https://godbolt.org/z/82D4LT

Compiler output:
<source>: In function 'int main()':
<source>:9:9: warning: ISO C++ forbids converting a string constant to 'char*'
[-Wwrite-strings]
    9 |     foo("Hello World");
      |         ^~~~~~~~~~~~~

[Bug c++/95596] string literal wrong overload resolution (char* vs std::string)

[redi at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2020-06-09

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Confirmed. Even with -std=c++14 -pedantic-errors we still choose the wrong
overload (and then give an error that the conversion is not allowed).

There seems to be no way to disable the conversion from string literals to
char* that has been deprecated for years.

[Bug c++/95596] string literal wrong overload resolution (char* vs std::string)

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
gcc/cp/typeck.c does:

      if (cxx_dialect >= cxx11)
        pedwarn (loc, OPT_Wwrite_strings,
                 "ISO C++ forbids converting a string constant to %qT",
                 totype);
      else
        warning_at (loc, OPT_Wwrite_strings,
                    "deprecated conversion from string constant to %qT",
                    totype);

As the example above shows, allowing the conversion and then conditionally
warning about it is not conforming.

[Bug c++/95596] string literal wrong overload resolution (char* vs std::string)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
So this is essentially:

struct S {
  S(const char *);
};

void foo(char *) = delete;
void foo(S);

void
g ()
{
  foo ("");
}

which compiles with clang++ but not with gcc.

[Bug c++/95596] string literal wrong overload resolution (char* vs std::string)

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Another one that G++ rejects:

  void f(char*);
  int &f(...);
  int &r = f("foo");

[Bug c++/95596] string literal wrong overload resolution (char* vs std::string)

[redi at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |zhonghao at pku dot org.cn

--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
*** Bug 86498 has been marked as a duplicate of this bug. ***

[Bug c++/95596] string literal wrong overload resolution (char* vs std::string)

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |johnsen.david at siemens dot com

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 104534 has been marked as a duplicate of this bug. ***

[Bug c++/95596] string literal wrong overload resolution (char* vs std::string)

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |arthur.j.odwyer at gmail dot com

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 110005 has been marked as a duplicate of this bug. ***