Not sure there's anything to fix. That binary compiles and runs fine; it's the caller that's making a mistake: argv should never be empty.

From execve(2) man page:

argv is an array of argument strings passed to the new program. By convention, the first of these strings should contain the filename associated with the file being executed

On Linux, argv can be specified as NULL, which has the same effect as
specifying this argument as a pointer to a list containing a single NULL pointer.
Do not take advantage of this misfeature!
It is nonstandard and nonportable: on most other UNIX systems doing this
will result in an error (EFAULT).

So, I'am also not sure if we need to fix something.

I've spotted this issue when my binary was ran by rsyslog.
Documentation looks inconsistent, as argv[0] doesn't have a program name, but whatever is provided to argv[0].
Module flag apparently is not only in charge of parsing args, but also flags when there is no argv[0] by throwing runtime error.
I'm new to golang and don't really have horse in this race, but from what I see at least len(argv) in flag module needs to be checked.

What config was used for rsyslog?

Something like this:

module(load="omprog")
action(type="omprog"
       binary="/pathto/omprog.py --parm1=\"value 1\" --parm2=\"value2\""
       template="RSYSLOG_TraditionalFileFormat")

yep, binary was invoked by omprog with no parameters.
like binary="/pathto/omprog.py"

It was fixed in latest versions of rsyslog apparently:
rsyslog/rsyslog@8d807e3

mmexternal bugfix: potentially missing argv[0]
This is incorrect and can cause problems with some language, namely go.

I searched Github and found another examples of execve("cmd", NULL, NULL); usage. It defentely not best practice but maybe it good idea to not panic in such case? @ianlancetaylor @robpike

It seems to me that the C getopt function will also crash in this case. It really doesn't seem worth worrying about.

But I guess if someone sends a patch for 1.14 we can take a look.

getopt(0,NULL,NULL) will work as argc is 0 obviously,
I can try to work on patch, but I would need some guidance on where this issue needs to be fixed.

In the initialization of CommandLine in the flag package.

Change https://golang.org/cl/184637 mentions this issue: flag: handle nil os.Args on CommandLine initialization

Thank you for filing this issue @Kneht and for the patience and everyone for chiming in. Welcome to the Go project!

I agree with what @robpike and @ianlancetaylor say: I don't think we should do anything here.

You are incorrectly using execve and yet execve asks that you pass at least one argument to char *const argv[] with the various standards and OSes stating in e.g.

Posix

The all encompassing standard says
https://pubs.opengroup.org/onlinepubs/9699919799/functions/exec.html

Linux

http://man7.org/linux/man-pages/man2/execve.2.html

Windows

https://docs.microsoft.com/en-us/cpp/c-runtime-library/exec-wexec-functions?view=vs-2019

Darwin

https://man.openbsd.org/execve.2

FreeBSD

https://www.freebsd.org/cgi/man.cgi?query=execve&sektion=2

and running a C variant on my MacbookPro computer

#include <unistd.h>

int main(int argc, char **argv) {
    getopt(0, NULL, NULL);
}

produces a SEGMENTATION FAULT as per

$ gcc call.c -o call && ./call
Segmentation fault: 11

Thus I shall close this issue, but nonetheless thank you for filing it, for the discourse, patience and for the CL. Looking forward to continuing to interact more with you on Go.

Hi @odeke-em, thank you for complete reply.

Based on links you've posted, standard and Linux documentation says that argv[0] should contain the filename, which sounds like recommendation to me.

Obviously you can check in evecve documentation for every OS and run any tests on personal computer of your choice, but it doesn't matter much as more then 50% of golang users are on Linux, at least based on survey 2018.

Given that fix has been implemented by Max and pre approved by Ian I guess it's up to them if this change needs to be merged.

Thanks for your contributions @odeke-em .