std:: container cast to C style array

[Christian Ehrlicher]

Add the proper cast and all is fine.

/edit:

  std::vector<const char*> cmdLine = { "command", "option", "param1", "param2", nullptr };
  main(cmdLine.size() - 1, const_cast<char **>(cmdLine.data()));
  // or
  execvp("blub", const_cast<char **>(cmdLine.data()));

Why not using QProcess?

[JonB]

@Kent-Dorfman
I'm lost :( As per the compiler message, const char** is not the same type as char* const*, and const char *argv[] is not the same as char* const argv[]. But you can cast-convert between them (as @Christian-Ehrlicher has said) if that's what you want to do, in that if we ignore the consts they both physically refer to a pointer-to a pointer-to a char, or if you prefer an array of pointers-to char. So what is your question (meant in the nicest way)?

[JonB]

@Christian-Ehrlicher said in std:: container cast to C style array:

Why not using QProcess?

The OP has not shown he is using any fork()-type call. Only execvp(). I don't know whether it's intentional(!), but as it stands he is not creating a sub-process, he is overlaying (i.e. replacing) the current process image with a new process image, no return to calling process....

[JKSH]

@Kent-Dorfman said in std:: container cast to C style array:

Ugh! closer inspection shows the prototype is
char* const argv[],
which may be different than
const char* argv[]

Lemme check!

They have different rules:

• const char *: Char data is const. Pointer is non-const.
• char * const: Char data is non-const. Pointer is const.

Which means:

• std::vector<const char*>: Char data cannot be modified through the pointer.
• char* const argv[]: Char data can be modified through the pointer.

The only way to pass the vector data into your C function is by using a const_cast like @Christian-Ehrlicher showed.

(P.S. I just found out that execvp() is part of the standard POSIX API. I'm puzzled as to why the function designer allows the char values to be modified)

[Christian Ehrlicher]

@JKSH said in std:: container cast to C style array:

I'm puzzled as to why the function designer allows the char values to be modified

Maybe for compatibility with main() entry point?

[JonB]

@JKSH , @Christian-Ehrlicher
TBH, I'm puzzled as to why the argv argument to main() is not declared

const char * const argv[];

[Kent-Dorfman]

@Christian-Ehrlicher et al

thanks @Christian-Ehrlicher ... my misstating the problem in the OP led to my own confuction. It was in fact solved by the proper const_cast. due to my misstaing ofthe const char* vs const* char, which were different. No QProcess as it's pure C/C++ ISO with the only externa dependencies to the project being anything that is implemented in pure C++ template headers. Test harness for spacecraft OS and I needed to spawn many clients with different argv params. complete std::thread run method is:

        static void RunProgram(ThreadWrapper* instance) {
            int pid = fork();
            if (pid == 0) {
                static const size_t STRLENGTH = 6;
                char instanceStr[STRLENGTH];
                char cmd[STRLENGTH];
                assert(snprintf(instanceStr, STRLENGTH, "%d", instance->instanceNum) > 0);
                assert(snprintf(cmd, STRLENGTH, "%s", instance->callType.c_str()) > 0);
                std::vector<const char*> cmdLine =
                        { "./CDSTest", cmd, SHMNAME, nullptr, nullptr };
                if (instance->callType == "-c") {
                    cmdLine[3] = instanceStr;
                } else {
                    cmdLine.resize(4);
                }
                assert(execvp("./CDSTest", const_cast<char**>(cmdLine.data())) >= 0);
            }
            int status(0);
            instance->pid = pid;
            assert(waitpid(pid, &status, 0) >= 0);

            instance->retval = WEXITSTATUS(status);
                // stall thread until command completes
        }

Solved.

[JonB]

@Kent-Dorfman
I am surprised at your usage of assert(). You are using it with a (vital) function call as its argument. Have you tested it, in Release mode, with a variety of compilers? Assuming https://en.cppreference.com/w/cpp/error/assert is "recognised" for C++ ISO (I don't know whether it is), it claims it will indeed be a macro with the definition being like:

// Defined in header <cassert>
#ifdef NDEBUG
#define assert(condition) ((void)0)
#else
#define assert(condition) /*implementation defined*/
#endif

?

[I have no idea what spacecraft OS is, but I'm very worried that yours is going to come crashing onto my head when you launch it non-debug mode ;-) ]

[Christian Ehrlicher]

@JonB You're correct - the usage of assert() is wrong in the code from @Kent-Dorfman

[Kent-Dorfman]

don't read into it. it's a test harness, not flight code. LOL

AUTOSAR standards forbid use of assert in mission critical code anyway so the existence of the assert() in R&D test code is kind of irrelevant...

[Christian Ehrlicher]

@Kent-Dorfman said in std:: container cast to C style array:

in R&D test code is kind of irrelevant...

It's not irrelevant, it's wrong in your case!

[JonB]

@Kent-Dorfman said in std:: container cast to C style array:

AUTOSAR standards forbid use of assert in mission critical code anyway so the existence of the assert() in R&D test code is kind of irrelevant...

In that case, even more reason not to put the code you want executed as an argument to assert(), only use assert() on a bool result variable? Anyway, your business, so long as you understand what assert() expands to in non-Debug compilation. Your usage just really caught my eye.

[Kent-Dorfman]

This post is deleted!

[Kent-Dorfman]

OK...I see the point of contention...since assert is itself defined as a macro...

[JonB]

@Kent-Dorfman
Indeed so! Hence I pasted the definition, showing that in the NDEBUG case it's not just that it does not verify the expression result, it's that it does not even evaluate (call) it. So any expression which has any side-effects should not be directly passed as argument to assert(), your code will not execute the CDSTest at all! And that will mean the child will continue into the pid != 0 (i.e. parent) code below, and continue running as a forked copy in parallel, with consequences. (IIRC, you should follow an execvp() in child with _exit(...), just in case....)

Hence my fear of your rocket maybe crashing onto my head ;-)