Thanks for the feedback! I agree the casts aren't pretty. :)
> Isn't it easier to change your fortify-clang and add a compiler option to
disable this specific error for specific targets?
The short answer is "in some cases, yes. Sadly, this doesn't seem to be one
of those cases."
The longer answer is that FORTIFY is a thing that's implemented partially
in the compiler, and partially in the standard library (for example, the
canonical FORTIFY implementation* has bits in both gcc and glibc). The
errors this patch is trying to fix originate from the bits in the standard
library, so it's not as simple as checking if the compiler got a flag. At
this point, the least-effort fix would be turning FORTIFY off for
${project_with_errors}. If we wanted to be more granular, we could probably
add #ifndef _DISABLE_FORTIFY_FOR_$functionName for each FORTIFY'ed
function, but:
1. grep tells me there are currently 75 FORTIFY functions, so we would need
75 such flags;
2. it lessens the effectiveness of FORTIFY across the entire project; and
3. the idea of hand-curating a list of per-project+per-function defines,
that can arbitrarily change from release to release, seems kind of ugly in
itself. :/
* - Clang is able to compile things with this gcc-based FORTIFY
implementation enabled. It's not able to do *nearly* as well as GCC,
though, because said impl depends heavily on implementation details of GCC
that don't hold true for clang.
Thanks,
George
On Tue, Aug 30, 2016 at 4:10 PM, Ronald S. Bultje <rsbul...@gmail.com>
wrote:
> Hi,
>
> On Tue, Aug 30, 2016 at 6:49 PM, George Burgess IV <g...@chromium.org>
> wrote:
>
>> ChromeOS is adopting a new FORTIFY implementation tailored for clang. As
>> an artifact of how this new FORTIFY is implemented, a handful of
>> implicit conversion warnings get turned into errors. This patch fixes
>> the implicit conversions in ffmpeg that clang-FORTIFY has an issue with.
>
>
> Isn't it easier to change your fortify-clang and add a compiler option to
> disable this specific error for specific targets? (I don't find the casts
> particularly pretty.)
>
> Ronald
>
_______________________________________________
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
