Re: getopt() not exposing __optpos - shell needs it

[Denys Vlasenko <vda.linux@googlemail.com>]

On Tue, Aug 29, 2017 at 3:07 PM, Rich Felker <dalias@libc.org> wrote:
>> > Maybe I'm missing what you're trying to say, but all the state is
>> > clobbered; I don't see how optarg is a problem specifically. You can
>> > clear or set it to a sentinel value before the relevant call if you're
>> > trying to determine if the call set it. Across other calls (not the
>> > one for the current option) I don't see why it matters at all what
>> > happens to it.
>>
>> Yes, this can be done.
>>
>> It gets increasigly ugly, though.
>>
>> With these amounts of massaging around libc API design breakage,
>
> Yes the getopt API is horribly broken. It's all global state, with a
> tiny portion of that state internal/inaccessible. It doesn't follow
> that the solution is adding new extensions every time an application
> hits an obstacle from the brokenness. The right direction for fixing
> it on the libc side would be introduction (with consensus across
> important implementations) of a getopt_r API or similar with no
> global/internal state.

I don't understand why you are opposed to exposing __optpos.
It does not even require any coding. Not a single insn needs
to be added.