std:: container cast to C style array

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 ;-)