Hi, On Thu, Aug 2, 2012 at 12:07 PM, Ronald S. Bultje <[email protected]> wrote: > Hi, > > On Thu, Aug 2, 2012 at 11:55 AM, Måns Rullgård <[email protected]> wrote: >> "Ronald S. Bultje" <[email protected]> writes: >>> On Mon, Jul 30, 2012 at 8:10 AM, Måns Rullgård <[email protected]> wrote: >>>> "Ronald S. Bultje" <[email protected]> writes: >>>>> On Mon, Jul 30, 2012 at 8:03 AM, Måns Rullgård <[email protected]> wrote: >>>>>> inline_mmx_deps="inline_asm mmx" >>>>>> inline_sse_deps="inline_mmx" >>>>> >>>>> If the user uses --disable-sse, this doesn't disable it here. I >>>>> suppose you might mean inline_sse_deps="inline_mmx sse"? >>>> >>>> Right. >>>> >>>>> Other than that, looks good to me. I don't think we need HAVE_SSE etc. >>>>> in config.h, only HAVE_INLINE_SSE and HAVE_YASM_SSE. >>>> >>>> Some of them are needed. For instance, we need to know if any kind of >>>> mmx might be used in order to issue emms correctly. >>> >>> Hm, ok, so I guess we can keep HAVE_MMX. Do we need others? >> >> Do they do any harm? > > Just trying to keep it clean. > > As for vsnprintf behaviour, from MSDN: > "vsnprintf, _vsnprintf, and _vsnwprintf return the number of > characters written if the number of characters to write is less than > or equal to count; if the number of characters to write is greater > than count, these functions return -1 indicating that output has been > truncated. The return value does not include the terminating null, if > one is written." > > So if format, buffer != NULL and count > 0, a return value of -1 means > that the buffer was overrun and is filled with data ("truncated"), so > writing a '\0' at the end and returning count should be OK then. > > As you pointed out, if the return value equals count, no zero was > written and we should add that. > > Do we care that the return value of this snprintf() drop-in will not > be the amount of characters that would have been written, but is > simply count, if the output was truncated? If so, this should be > relatively easy to finish.
Wrong thread, ignore. Ronald _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
