Fix for optind in getopt on musl libc.

[fredrikekre]

This fixes

julia/test/cmdlineargs.jl

Line 258 in 11ce4d1

@test readchomp(`$exename -E "Base.JLOptions().opt_level" -O`) == "3"

and

julia/test/cmdlineargs.jl

Line 263 in 11ce4d1

@test readchomp(`$exename -E "Base.JLOptions().debug_level" -g`) == "2"

i.e. the bug only shows where there are a last option with a default value.

On exit optind points to the last non-opt argument of argv, but in the case where there are only options optind does not go beyond argc, except on musl libc, where it becomes argc + 1. This causes

julia/src/jloptions.c

Line 624 in 11ce4d1

*argcp -= optind;

to be -1 and then we try to resize ARGS to -1 here:

julia/src/jloptions.c

Line 638 in 11ce4d1

jl_array_grow_end(args, argc);

and crash.

I don't know if this is an acceptable fix, but feels like it should be safe on all systems.

edit: fixes #26761

[stevengj]

Should a bug report be filed with musl as well?

[fredrikekre]

I don't know which one is correct though, e.g. from https://www.gnu.org/software/libc/manual/html_node/Using-Getopt.html#Using-Getopt:

optind: This variable is set by getopt to the index of the next element of the argv array to be processed. Once getopt has found all of the option arguments, you can use this variable to determine where the remaining non-option arguments begin. The initial value of this variable is 1.

which could be interpreted as optind should be argc + 1 when there are only option arguments. Also, https://github.com/JuliaLang/julia/blob/master/src/getopt.h#L1 seems to be based on the musl version, only used on MSVC so maybe that has the same problem

julia/src/Makefile

Lines 50 to 52 in 5486cc2

	ifeq ($(USEMSVC), 1)
	SRCS += getopt
	endif

[staticfloat]

you can use this variable to determine where the remaining non-option arguments begin

IMO it's a bug that it points off the end of the array; I think it's worthwhile notifying the musl developers. They're probably aware and they'll probably close it as wontfix, but might as well try to be good citizens.

[stevengj]

The POSIX getopt documentation is quite explicit about optind:

If the resulting value of optind is greater than argc, this indicates a missing option-argument, and getopt() shall return an error indication.

My reading is that on a successful call POSIX requires 1 ≤ optind ≤ argc, and if the arguments are all valid options then you should have optind == argc.

[richfelker]

As noted by @stevengj, POSIX is very explicit about requiring this behavior; it's not a bug in musl:

If the option was the last character in the string pointed to by an element of argv, then optarg shall contain the next element of argv, and optind shall be incremented by 2. If the resulting value of optind is greater than argc, this indicates a missing option-argument, and getopt() shall return an error indication.

If other implementations are not doing this it should probably be reported as a bug against them.