[TUHS] Command line options and complexity

John P. Linderman jpl.jpl at gmail.com
Thu Mar 12 10:13:11 AEST 2020


I wasn't running FreeBSD. Linux has nothing to say about it. The wonderful
thing about standards is that there are so many to choose from.

On Wed, Mar 11, 2020 at 5:29 PM Warner Losh <imp at bsdimp.com> wrote:

>
>
> On Wed, Mar 11, 2020 at 11:43 AM John P. Linderman <jpl.jpl at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20200311/6a97e60e/attachment.html>


More information about the TUHS mailing list