fix getopt[_long] clobbering of optopt on success

getopt is only specified to modify optopt on error, and some software
apparently infers an error from optopt!=0.

getopt_long is changed analogously. the resulting behavior differs
slightly from the behavior of the GNU implementation of getopt_long,
which keeps an internal shadow copy of optopt and copies it to the
public one on return, but since the GNU implementation also exhibits
this shadow-copy behavior for plain getopt where is is non-conforming,
I think this can reasonably be considered a bug rather than an
intentional behavior that merits mimicing.

0 files changed, 0 insertions, 0 deletions