On Thu, 28 Nov 2013, Diego Biurrun wrote:
On Thu, Nov 28, 2013 at 10:48:00AM +0200, Martin Storsjö wrote:
On Wed, 27 Nov 2013, Diego Biurrun wrote:
On Wed, Nov 27, 2013 at 10:15:09PM +0200, Martin Storsjö wrote:
On Wed, 27 Nov 2013, Diego Biurrun wrote:
--- a/configure
+++ b/configure
@@ -3355,45 +3380,52 @@ esac
+ add_${pfx}cppflags -U__STRICT_ANSI__
+ elif check_${pfx}func_headers stdlib.h _get_doserrno; then
+ eval ${pfx}libc_type=msvcrt
+ add_compat strtod.o strtod=avpriv_strtod
+ add_compat msvcrt/snprintf.o snprintf=avpriv_snprintf \
+ _snprintf=avpriv_snprintf \
+ vsnprintf=avpriv_vsnprintf
Things like add_compat here (and below) should only be done if this
is the target libc, not if it's the host one. In general, every
single action (add/set/whatever) in this needs to include $pfx in
one way or another, otherwise it's doing something wrong.
When using msvc as host compiler this is not necessary?
Well, add_compat only adds the objects to be used in target
complication anyway, so calling that based on the host libc
detection is just broken anyway.
Apparently we've been able to cope just fine without these with MSVC
as host compiler so far. They are only added in the target
compilation to amend the existing strtod/snprintf implementations to
comply with more corner cases that we don't exercise in the host
tools. For strtod, it's about parsing hex literal strings (which
strtol can handle but not strtod in both msvcrt and bionic) - and I
don't think any of the host tools use that feature. For snprintf,
it's about getting the right semantics in case the buffer overflows
(the msvcrt implementation doesn't null terminate it in this case,
which the C standard says it should). So for target compilation,
it's needed because otherwise a whole lot of string handling
suddenly would be insecure. For host building, you're not (quite as
much at least) exposed to the threat of any random incoming data,
but only to the threat of what's in the libav source itself.
So basically we don't need it now and can maybe or even probably get
away with cutting a corner here, at least for the foreseeable future.
Still it would be cleaner to apply this to both host and target
compilation.
Cleaner perhaps, but I'd rather postpone that to a later patch instead of
growing the scope of this patch to larger proportions anyway. This patch
is not dead-trivial as it is anyway, and the more bells and whistles we
add to it, the harder it gets to review and to say with good confidence
that it's ok. And it's not needed probably any time soon anyway.
// Martin
_______________________________________________
libav-devel mailing list
[email protected]
https://lists.libav.org/mailman/listinfo/libav-devel
