>  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

Reply via email to