[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
