9

The following code compiles without any error in VSC++2017 and doesn't compile in gcc 7.3.0 (error: invalid static_cast from type ‘int(int)’ to type ‘void*’ void* p = static_cast<void*>(func))

#include <iostream>

int func(int x) { return 2 * x; }

int main() {

    void* p = static_cast<void*>(func);
    return 0;
}
Fabio says Reinstate Monica
  • 5,271
  • 9
  • 40
  • 61
Soulimane Mammar
  • 1,658
  • 12
  • 20
  • 1
    Function pointers are a bit weird. I'd have to go Standard diving, but I'm pretty sure MSVC is bending the Standard for their own nefarious purposes. – user4581301 Mar 24 '19 at 00:27
  • 2
    @user4581301 Not really – the other question is about C, and there might be differences in the languages... – Aconcagua Mar 24 '19 at 00:35
  • 1
    While function pointers are different animals than object pointers, most incompatibilities occur when the `sizeof()` the two differ. If they are the same you can usually safely convert back and forth to a `void*`. Even so, while it may work, it's not portable and just one of those things best avoided. – doug Mar 24 '19 at 00:57

1 Answers1

8

Functions are implicitly convertible only to function pointers. A function pointer is not a pointer in the strict meaning of the word in the language, which refers only to pointers to objects.

Function pointers cannot be converted to void* using static_cast. The shown program is ill-formed. If a compiler does not warn, then it fails to conform to the standard. Failing to compile an ill-formed program does not violate the standard.

On systems where void* is guaranteed to be able to point to a function (such as POSIX), you can use reinterpret_cast instead:

void* p = reinterpret_cast<void*>(func);

But this is not portable to systems that lack the guarantee. (I know of no system that has a C++ compiler and does not have this guarantee, but that does not mean such system does not exist).

Standard quote:

[expr.reinterpret.cast]

Converting a function pointer to an object pointer type or vice versa is conditionally-supported. The meaning of such a conversion is implementation-defined, except that if an implementation supports conversions in both directions, converting a prvalue of one type to the other type and back, possibly with different cv-qualification, shall yield the original pointer value.

Note that this conditional support does not extend to pointers to member functions. Pointers to member functions are not function pointers.

Community
  • 1
  • 1
eerorika
  • 232,697
  • 12
  • 197
  • 326
  • 2
    POSIX requires interconvertibility between function pointers (code addresses) and object pointers (data addresses), it's necessary to make `dlsym` work. – Ben Voigt Mar 24 '19 at 00:43
  • @BenVoigt - that's true, but it won't be done with `static_cast`. It can be done with `reinterpret_cast` or a C-style cast. – Peter Mar 24 '19 at 01:52
  • On this answer - the standard says nothing about "warnings". The standard requires diagnostics if a program is ill-formed and the error message in the question represents a diagnostic. But the standard neither requires nor forbids warnings (messages about suspicious constructs, etc, that do not prevent code from compiling) - they are discretionary features offered by implementations (and often an indicator of "quality of implementation"). Their absence does not indicate non-compliance with the standard. – Peter Mar 24 '19 at 02:02
  • 1
    @Peter the standard requires a diagnostic if the program is ill-formed (unless specified otherwise). The shown program is ill-formed. A diagnostic is required. A warning is a form of a diagnostic, and issuing a warning would be sufficient to conform to the standard. Lack of a diagnostic is violation of the standard. – eerorika Mar 24 '19 at 02:07
  • 2
    @eerorika - You're conflating terms. The term "diagnostic" has a specific definition in the standard as being required by the standard in specified circumstances. Warnings generally provide additional information, not mandated by the standard, because vendors choose to do so, as an aid for developers (usually because the compiler does more analysis than the standard requires, so can provide additional information). To YOU a warning may be a diagnostic. To the C++ standards, by definition in the standards, it is not. – Peter Mar 24 '19 at 05:15
  • If I recast the ``void*`` to the original type as in ``std::cout << ((int (*)(int))p)(5) << std::endl;`` the program works fine as specified by [expr.reinterpret.cast]. But this is a breaking behavior for portability (and it should be handled in my sense by the standard) – Soulimane Mammar Mar 24 '19 at 08:07
  • 2
    @Peter: A warning is a diagnostic. defns.diagnostic: "message belonging to an implementation-defined subset of the implementation's output messages". – geza Mar 24 '19 at 11:19
  • 2
    @SoulimaneMammar: The standard handles it. It says it is implementation defined whether the conversion is supported. It is the best the standard can say about this (because there could be/was platforms, where the conversion is not possible). But it is highly likely that the conversion works on all current wide-spread platforms (if a platform has dlsym/GetProcAddress, it should work). – geza Mar 24 '19 at 13:31