[llvm] r271491 - [LibFuzzer] Reimplement how the optional user functions are called.

[David Blaikie via llvm-commits]

-Wpedantic in clang ToT fires on this too.

I believe the idiomatic way to do this is:

  reinterpret_cast<void*>(reinterpret_cast<uintptr_t>(func_ptr));

On Mon, Jul 10, 2017 at 1:27 PM Eric Christopher <echristo at gmail.com> wrote:

> On Sat, Jul 8, 2017 at 11:32 AM Dan Liew <dan at su-root.co.uk> wrote:
>
>> On 8 July 2017 at 01:40, Eric Christopher <echristo at gmail.com> wrote:
>> > Hi Dan,
>> >
>> > So this is causing warnings and breaking Werror builds:
>> >
>> >
>> /usr/local/google/home/echristo/sources/llvm/lib/Fuzzer/FuzzerExtFunctions.def:29:10:
>> > warning: ISO C++ forbids casting between pointer-to-function and
>> > pointer-to-object [-Wpedantic]
>> >  EXT_FUNC(__lsan_enable, void, (), false);
>> >           ^
>> >
>> /usr/local/google/home/echristo/sources/llvm/lib/Fuzzer/FuzzerExtFunctionsWeak.cpp:44:24:
>> > note: in definition of macro ‘EXT_FUNC’
>> >    CheckFnPtr((void *)::NAME, #NAME, WARN);
>> >                         ^
>> >
>> > Feel like fixing? :)
>>
>> Is this GCC or Clang and which version is this with?
>>
>
> Possibly gcc? And if so, quite old. :) I haven't tested with anything
> newer.
>
>
>>
>> I can think of two options to fix this.
>>
>> 1. Use pragmas to disable warnings in the region. E.g.
>>
>> ```
>> #pragma GCC diagnostic push
>> #pragma GCC diagnostic ignored "-Wpedantic"
>>
>> // do stuff
>>
>> #pragma GCC diagnostic pop
>> ```
>>
>> 2. Make `CheckFnPtr a templated function so that the cast is no longer
>> necessary.
>>
>> i.e. something like.
>> ```
>> template <typename T>
>> static void CheckFnPtr(T FnPtr, const char *FnName, bool WarnIfMissing) {
>>   if (FnPtr == nullptr && WarnIfMissing) {
>>     Printf("WARNING: Failed to find function \"%s\".\n", FnName);
>>   }
>> }
>> ```
>>
>> I kind of prefer option 2 but I don't like the fact this will cause us
>> to emit a different implementation of `CheckFnPtr` for every single
>> function signature, just so we can avoid
>> a pedantic warning.
>>
>>
> It seems like a good warning?
>
>
>
>> @kcc: Any thoughts on this? Do you have any preferences for option 1
>> or 2 or do you have an idea for a third option?
>>
>>
> I have no preferences, but would appreciate you fixing it if possible.
>
> Thanks
>
> -eric
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20170710/e312812d/attachment.html>