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.