[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1372927547.16412.171.camel@eris.loria.fr>
Date: Thu, 04 Jul 2013 10:45:47 +0200
From: Jens Gustedt <jens.gustedt@...ia.fr>
To: musl@...ts.openwall.com
Subject: Re: Use of size_t and ssize_t in mseek
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/
> > > 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.
> > > What I was saying is that, in library code, you can't rely on this.
> > > The application may have installed a handler that causes the functions
> > > to just return an error, or the default implementation-defined handler
> > > might do so.
> >
> > sure, but I don't see any problem in this. continuing execution is
> > one of the permitted path that a constraint handler may take. these
> > are user interfaces, not meant to be used internally by the C library,
> > I think.
>
> I was thinking of third-party libraries that aim to be proper library
> code, not use in the standard library.
ok, but they also should not expect any particular behavior from the
handler(s), just use the interfaces, then.
> > I think there are some of these interfaces that are not too bad, from
> > a user perspective these interfaces are relatively simple to use.
>
> I find the str/mem functions rather confusing, with their redundant
> size arguments and all.
>
> > 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.
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.
> > and I also see advantages in being able to
> > inhibit certain dangerous printf or scanf formats.
>
> 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,
> For scanf, having size limits on strings to be read is useful. I was
> under the mistaken impression that exceeding the limit was a runtime
> constraint violation, which would have made scanf_s useless, but it's
> specified to be a matching failure. Still, the same can be achieved
> with plain scanf and a field width specifier. And if you need the
> width to vary at runtime, you can generate the format string with
> snprintf... So scanf_s buys you a little bit of convenience, but not
> much more.
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.
