[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK1hOcM1bJzBCPXFXQUb-U5MANAkma5CyT_nD6pqRu10HRXzLw@mail.gmail.com>
Date: Tue, 29 Aug 2017 18:47:24 +0200
From: Denys Vlasenko <vda.linux@...glemail.com>
To: musl <musl@...ts.openwall.com>
Subject: Re: getopt() not exposing __optpos - shell needs it
On Tue, Aug 29, 2017 at 3:07 PM, Rich Felker <dalias@...c.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.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
