On Fri, 19 Apr 2024, Nikita Kniazev wrote:
A "char**" pointer can't be implicitly converted to a "const char**"
pointer - see https://c-faq.com/ansi/constmismatch.html for the full
explanation for this issue.
The function arguments are not "const char**", they are "const char*
const*" so there is no issue.
That doesn't make any difference. The point is that non-const can be
implicitly converted to const, only applies on the outermost pointer
layer.
int execve_before(const char *_Filename,char *const _ArgList[],char *const
_Env[]);
int execve_after(const char *_Filename,const char *const _ArgList[],const
char *const _Env[]);
void foo(char** args, char** env)
{
execve_before("x", args, env);
execve_after("x", args, env);
}
https://godbolt.org/z/4Tx5j9KM9
Note how you run this example in C++ mode. As Liu Hao mentioned, the
rules for these conversions differ between C and C++.
If you convert your example to C, it gives loud warnings with Clang and is
a hard error with GCC.
https://godbolt.org/z/d7EsnK61x
So we gain conformance with MSVC, but lose conformance with POSIX. (OTOH,
our functions are named with leading underscores, which can motivate them
differing.)
AFAIK types (not even type-constness) are **not** a part of C ABI on any
known platform to me.
I didn't say it is an ABI break - it's not. It's an API break though.
// Martin
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
