Re: [TUHS] Command line options and complexity

[Warner Losh <imp@bsdimp.com>]

[-- Attachment #1: Type: text/plain, Size: 1360 bytes --]

On Wed, Mar 11, 2020 at 11:43 AM John P. Linderman <jpl.jpl@gmail.com>
wrote:

> This is *great*, Kurt. The source in src/runtime/hrs/src for rsort.c is
> their version of my external sort, modified to be a subroutine. There's
> some lessons to be learned about "software hygiene". I was cavalier about
> freeing what I allocated dynamically. As a result, their version leaks like
> a sieve if the subroutine is called repeatedly. Apropos of which, they came
> to me having noted that only the first call was acting as expected. There's
> a wonderful irony (I'm big on irony). I had replaced my do-it-yourself
> argument processing with getopt. The code has the following comment
>
> ** Use getopt() for portability.
>
> A few lines later, you see
>
>     optind = 1;  /* reset after use in Hancock program *
>     while ((c = getopt(argc, argv, "cCiIjmrsSuvb:f:D:o:p:T:x:y:z:")) !=
> EOF) {
>
> optind??? Seems getopt has an undocumented global flag to prevent
> reprocessing the arguments. How portable:-)
>

It's documented:

     The variables opterr and optind are both initialized to 1.  The optind
     variable may be set to another value before a set of calls to getopt()
in
     order to skip over more or less argv entries.

is what the FreeBSD man page has to say about it. So this just resets any
scanning that had happened before this...

Warner

[-- Attachment #2: Type: text/html, Size: 2292 bytes --]