Date: Thu, 04 Jul 2013 08:11:58 +0200 From: Jens Gustedt <jens.gustedt@...ia.fr> To: musl@...ts.openwall.com Subject: Re: Use of size_t and ssize_t in mseek Hello Rich, Am Mittwoch, den 03.07.2013, 21:28 -0400 schrieb Rich Felker: > The requirements for printf_s, scanf_s, and related functions look > quite invasive and would affect programs not using these interfaces. unless one would finally implement them separately, of course > Otherwise, the Annex K interfaces look like a considerable amount of > bloat with highly questionable usefulness, but mostly non-invasive. My > feeling is that we should hold off on a decision about them to see if > any applications actually start using them. If just some if conditionals are bloat for you, yes. These conditionals could easily be tagged as likely/unlikely to privilege the fastpath. > > Then some interfaces are clearly different such that they can't simply > > be copied over, notably bsearch and qsort functions, since they > > receive additional arguments to provide context to the object > > comparison. > > These are much easier; the extra argument can be passed via TLS. It's > printf_s and scanf_s that are hard. Hm, I don't see how this can be done "easily", and in particular such that there is no performance loss for qsort. I think for these functions performance is important in any type of platform. I once implemented such context propagation for POSIX' tsearch family and it was a real pain, IRC. > > IIRC, what I couldn't handle within P99 was checking of printf > > arguments, but from within musl this should be relatively straight > > forward. > > Not really. There would need to be a way to convey to the printf core > that it's supposed to do this extra checking, and a way to make it > call the constraint handlers. This you could e.g easily to with TLS :) I'd think that for printf and friends this would be much less critical than for the sort functions. To my understanding printf functions are IO bound (or memory bound for sprintf), so just some switching on entry on some TLS wouldn't be much of an overhead, I think. > P.S. One other reason I hate Annex K is that the constraint handler > design is non-thread-safe and non-library-safe. that is certainly a good point > There's only one > global constraint handler, shared by all threads and by all > libraries/modules that might be using Annex K functions. That means > there's really no valid way to write code that depends on a particular > constraint handler being installed. This is just meant to be like this. These interfaces are meant to give means to abort more or less gracefully if constraints as they are described in that Annex occur. They are not meant to have complicated games that let you "repair" faulty environments and continue execution. > And the default handler is > implementation-defined, so it wouldn't even be reasonable to say > "leave the default handler there". The only thing reasonable code > using these interfaces can expect when a constraint is violated is > implementation-defined behavior, which is only a tiny step up from > undefined behavior... You are too much a library implementor :) I think it is easy for an application to install a different constraint handler (a standard one or of its own) during startup in its main, before creating any other thread. I see that as the principal use pattern for this, just straight and simple. In particular no library should expect any particular constraint handler to be in place. It is up to the application to determine what is to be done if a constraint occurs. > My feeling is that we should hold off on a decision about them to > see if any applications actually start using them. I think we have a hen and egg problem, here. Nobody will use them if nobody provides an implementation. Jens -- :: INRIA Nancy Grand Est :: http://www.loria.fr/~gustedt/ :: :: AlGorille ::::::::::::::: office Nancy : +33 383593090 :: :: ICube :::::::::::::: office Strasbourg : +33 368854536 :: :: ::::::::::::::::::::::::::: gsm France : +33 651400183 :: :: :::::::::::::::::::: gsm international : +49 15737185122 :: Download attachment "signature.asc" of type "application/pgp-signature" (199 bytes)
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.