[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130704152447.GO29800@brightrain.aerifal.cx>
Date: Thu, 4 Jul 2013 11:24:48 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Use of size_t and ssize_t in mseek
On Thu, Jul 04, 2013 at 10:45:47AM +0200, Jens Gustedt wrote:
> Am Donnerstag, den 04.07.2013, 04:12 -0400 schrieb Rich Felker:
> > > (In P99 I do that with inlining and gcc shows to be able to expand all
> > > comparisons in place and to optimize that smoothly.)
> >
> > Nice. I'll have to take a look -- I've always wanted to see a fully
> > inlined qsort that could be compared to the C++ template-based sorts
> > to demonstrate that inline functions in C can do just as good or
> > better, inlining the comparison callback... :)
>
> just to continue on my shameless self advertisement, I have written
> this up on my blog
>
> http://gustedt.wordpress.com/2012/12/04/inline-functions-as-good-as-templates/
No need to apologize. :) Thanks for the link.
> > > > TLS is not guaranteed to exist when these functions are called;
> > > > programs not using any multi-threaded functionality are supposed to
> > > > "basically work" on Linux 2.4. I don't mind having the Annex K
> > > > functions depend on TLS, since only new programs will use them anyway,
> > > > but I don't want to break existing programs.
> > >
> > > My guess would be that you can alias the TLS variable that would
> > > control that behavior to a simple global variable in the case of
> > > absence of threads.
> >
> > Yes, that can be done, but I'd probably rather just use the FILE...
>
> well there are certainly different strategies possible, and only a
> close investigation of the existing code and the consequence of adding
> (or not) new fields or global variables, would show the best way to do
> this
>
> the global variable approach would be independent of FILE and just
> work for sprintf and friends without headache.
It would also possibly break the async-signal-safety of our printf,
unless handled very carefully. Generally the style/policy in musl is
to avoid any use of global variables or other global state that's not
absolutely required to implement something, and that's what's led us
to a library where almost everything is AS-safe.
> > > Especially qsort_s is nice
> >
> > I agree. IMO it's a shame it was done as part of Annex K and not the
> > base standard. Unlike most of Annex K, it serves a real purpose.
>
> so one possibility, for a start would be to provide the interesting
> interfaces as extensions. the access to these could probably be
> regulated by the __STDC_WANT_LIB_EXT1__ macro. I think nothing forbids
> to provide EXT1 partially, even if __STDC_LIB_EXT1__ is not set.
I think they violate the namespace if it's not set, but it's not
entirely clear to me whether that's the intent of the standard or not.
If they didn't, the whole idea of having to use a feature test macro
to request them does not make sense. The implementation would just
unconditionally provide them and define a macro reflecting whether
they're available.
It looks like the glibc plan is to make them available under
_GNU_SOURCE or __STDC_WANT_LIB_EXT1__, but not by default. So unless
major BSDs make them available by default, I'd have a hard time
justifying a decision to do so. It seems it would just result in
gratuitous portability problems (programs working on musl but failing
when built on other systems).
> footnote 382 seem to point out that if __STDC_WANT_LIB_EXT1__ is set
> to something different from 0, we'd have the right to use the symbols
> that are defined in K.
Conforming applications will never set it to anything other than 1, so
I'm not sure how this would end up getting picked up.
On the other hand, as long as we don't define __STDC_LIB_EXT1__, there
is no guarantee to applications that __STDC_WANT_LIB_EXT1__ works or
does anything at all. So it seems like it me be conforming to
provide some, but not all, of these interfaces, or interfaces with the
same names but weaker functionality, when __STDC_WANT_LIB_EXT1__ is
defined, as long as we don't define __STDC_LIB_EXT1__. By "weaker
functionality", what I had in mind is simply crashing (a_crash) on
runtime constraint violations, not doing anything to block %n, etc.
But I'm skeptical of whether this would be a good idea.
> > For printf, there's nothing dangerous about %n. This is a
> > misconception based on knee-jerk reactions to format string bugs. The
> > only thing that's dangerous is passing non-format-strings as the
> > format-string argument to printf.
>
> yes, probably, and the fact that there are still compilers arround
> that don't check for consistency of the printf arguments,
Well I'm assuming you've done minimal coverage testing. Naturally
there could be dangerous bugs in calls where the format string
statically fails to match the arguments, but this would be detected
during any sanity testing of the code in question.
Rich
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.
