> 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. 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 > 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. > In any case, while correct, this change can (and probably will) definitely > break building some user code that has so far worked So I don't think it is a breaking change. On Fri, Apr 19, 2024 at 10:38 AM Martin Storsjö <mar...@martin.st> wrote: > On Thu, 18 Apr 2024, Nikita Kniazev wrote: > > > From 0d9fb95b2c50a15a90276f67e7ec44c67cb1093b Mon Sep 17 00:00:00 2001 > > From: Nikita Kniazev <kniazev.nik...@gmail.com> > > Date: Thu, 18 Apr 2024 03:37:48 +0000 > > Subject: [PATCH] crt: execv*/spawnv* const-correctness > > > > Signed-off-by: Nikita Kniazev <kniazev.nik...@gmail.com> > > --- > > mingw-w64-headers/crt/process.h | 26 +++++++++++++------------- > > 1 file changed, 13 insertions(+), 13 deletions(-) > > > > diff --git a/mingw-w64-headers/crt/process.h > > b/mingw-w64-headers/crt/process.h > > index 1ac39a064..8c35372a3 100644 > > --- a/mingw-w64-headers/crt/process.h > > +++ b/mingw-w64-headers/crt/process.h > > @@ -183,20 +183,20 @@ extern "C" { > > stupid warnings, define them in POSIX way. This is save, because > > those > > methods do not return in success case, so that the return value is > not > > really dependent to its scalar width. */ > > - _CRTIMP int __cdecl execv(const char *_Filename,char *const > _ArgList[]) > > __MINGW_ATTRIB_DEPRECATED_MSVC2005; > > - _CRTIMP int __cdecl execve(const char *_Filename,char *const > > _ArgList[],char *const _Env[]) __MINGW_ATTRIB_DEPRECATED_MSVC2005; > > - _CRTIMP int __cdecl execvp(const char *_Filename,char *const > _ArgList[]) > > __MINGW_ATTRIB_DEPRECATED_MSVC2005; > > - _CRTIMP int __cdecl execvpe(const char *_Filename,char *const > > _ArgList[],char *const _Env[]) __MINGW_ATTRIB_DEPRECATED_MSVC2005; > > + _CRTIMP int __cdecl execv(const char *_Filename,const char *const > > _ArgList[]) __MINGW_ATTRIB_DEPRECATED_MSVC2005; > > Thanks, I think this patch is correct, so I think we should apply it. > > However, this is a quite subtle area, and this can actually cause breakage > in user code. > > 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. > > That said, MSVC's header seem to have const applied on these pointers like > you suggest, already in ancient versions like MSVC 6, up to the latest > versions using UCRT. So therefore, the change certainly is motivated, and > reduces the amount of unnecessary differences to MSVC. > > However, on the other side, the POSIX spec for the exec* family of > functions, declare them without const here: > https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html > > So we gain conformance with MSVC, but lose conformance with POSIX. (OTOH, > our functions are named with leading underscores, which can motivate them > differing.) > > In any case, while correct, this change can (and probably will) definitely > break building some user code that has so far worked, depending on > language mode and warning strictness etc. (Code that is built with both > MSVC and mingw might not have such issues though as there already was a > divergence.) > > // Martin > > > > _______________________________________________ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public