I have an issue with a code that compiles without problem under gcc but not with g++. I am moving to g++ since I would like to make use of boost for some multithreading improvement. The errors I get are something like:
invalid conversion from 'void* volatile' to 'TrialVect*'
the piece of code is:
static void funcSize( struct TrialVect *vector ) {
if ( vector->field ) {
struct TrialVect *ptr = BO2V (vector->first,vector->second);
}
}
As I googled there is some issue with casting variables, why? suggestions how to fix it?
In C++ any pointer can be converted to void* implicitly, but converting from void* requires an explicit cast.
Try this:
auto ptr = static_cast<TrialVect* volatile>( BO2V (vector->first,vector->second) );
volatile is an attribute (like const) that must be handled separately; either the new pointer must match the old one, or you can change the const/volatile attributes using a separate const_cast. For example,
auto ptr = static_cast<TrialVect*>( const_cast<void*>( BO2V(vector->first, vector->second) ) );
Whether removing the volatile attribute is safe or not depends on the application.
Related
You may have to forgive me as I'm new to C++ and may have made some fundamental errors with the code I have worked up so far.
static tuple<read_result, uint8_t*> m_scan_record(bool skip, uint32_t& size, FILE* file)
{
read_result result;
tuple<read_result, uint32_t*> rd_rec_size_result = m_read_generic_t<uint32_t>(file);
result = (read_result)get<0>(rd_rec_size_result);
if (result != read_success )
{
return tuple<read_result, uint8_t*>(result, nullptr);
}
size = (uint32_t) get<1>(rd_rec_size_result);
if ( skip )
{
fseek(file, size, SEEK_CUR);
}
// ...
}
template<typename T>
static tuple<read_result, T*> m_read_generic_t(FILE* file)
{
T ret = 0;
read_result result = m_read_from_file_to_buffer(&ret, sizeof(T), file);
if (result == read_success)
{
return tuple<read_result, T*>(result, &ret);
}
return tuple<read_result, T*>(result, nullptr);
}
When I compile this code I am getting this error:
cast from ‘std::__tuple_element_t<1, std::tuple<read_result, unsigned int*> >’ {aka ‘unsigned int*’} to ‘uint32_t’ {aka ‘unsigned int’} loses precision [-fpermissive]
My intentions and what I am expected to do/happen:
In the declaration of m_scan_record, the size argument is declared with a & which is intended to allow me to pass the value by reference, analogous to using the REF c# keyword
I make a call to generic (template) function m_read_generic_t which is called with the specified type <unit32_t> and therefore (according to its definition) will return a type of tuple<read_result, uint32_t*>
Once I have the tuple returned by m_read_generic_t, I want to take the unit32_t value pointed to by the second value of the tuple, and put that value into the size variable mentioned at point 1, above, which presumably will then be accessible to the calling function one step further up the stack.
From the above points you can hopefully see that my intention (and I appreciate that I may be far away in reality!) is that at this line:
size = (uint32_t) get<1>(rd_rec_size_result);
all I am doing is simply grabbing a 'pointed to' value and putting it into a variable of a matching type, much like the oft-cited textbook example:
uint32_t v = 123;
uint32_t* ptr_to_v = &v;
uint32_t x = ptr_to_v; // x == 123
Clearly this is not what is really going on with my code, though, because if it were, I presume that the cast would be un-needed. But if I remove it, like this:
size = get<1>(rd_rec_size_result);
then I get a compile-time error:
a value of type "std::__tuple_element_t<1UL, std::tuple<read_result, uint32_t *>>" cannot be assigned to an entity of type "uint32_t"
I believe therefore that I am doing something badly wrong - but I can't work out what. Is this to do with the way I am taking the pointer out of the tuple; or is there something else going on when it comes to the getting a uint32_t value from a uint32_t* ?
This is all in a C++ environment on Ubuntu 20.04, FWIW
Many thanks in advance for any/all suggestions; please go easy on me!
tuple<read_result, uint32_t*> rd_rec_size_result = ...
The 2nd member of this tuple, as explicitly declared here, is a pointer to a uint32_t. That's what uint32_t * means, in C++.
size = (uint32_t) get<1>(rd_rec_size_result);
This retrieves the uint32_t * and attempts to convert it to a uint32_t. C++ does not work this way. Although this conversion can be forced your compiler has every right to believe that whatever this code is trying to do it must be wrong.
Perhaps I was wondering initially, your intention was to dereference the pointer. This is the reason for your compilation error, in any case. If your intention was to, truly, dereference this pointer, then this would've been a simple matter of changing this to
size = *get<1>(rd_rec_size_result);
However, that's not going to be the end of your troubles. Even after this compilation error is fixed, this way, the shown code will still be badly, badly broken.
This is because m_read_generic_t returns a pointer to a local object, which will get destroyed when the function returns, and attempting to dereference this pointer, here, will make demons fly out of your nose.
The real fix here is to change m_read_generic_t to not return a pointer as the 2nd value in the tuple in the first place, thus eliminating the compilation error in the first place.
I’ve searched Stack Overflow for an answer, but I get nothing specific to this problem: only general cases about use of various types of cast operators.
So, the case in point is when retrieving a function address with the Windows GetProcAddress() API call, which returns a function pointer of type FARPROC, with: typedef INT_PTR (__stdcall *FARPROC)();.
The trouble is, the actual function sought rarely (if ever) has this actual signature, as shown in the MRCE code, below. In this code, I have shown a variety of different attempts to convert the returned value to a function pointer of the appropriate type, with all but the fourth method commented out:
#include <Windows.h>
#include <iostream>
typedef DPI_AWARENESS_CONTEXT(__stdcall* TYPE_SetDPI)(DPI_AWARENESS_CONTEXT); // Function pointer typedef
static DPI_AWARENESS_CONTEXT __stdcall STUB_SetDpi(DPI_AWARENESS_CONTEXT) { return nullptr; } // Dummy 'stub' function
static DPI_AWARENESS_CONTEXT(__stdcall* REAL_SetDpi)(DPI_AWARENESS_CONTEXT) = STUB_SetDpi; // Func ptr to be assigned
using std::cout; using std::endl;
int main()
{
HINSTANCE hDll = LoadLibrary("User32.dll");
if (!hDll) {
cout << "User32.dll failed to load!\n" << endl;
return 1;
}
cout << "User32.dll loaded succesfully..." << endl;
// (1) Simple assignment doesn't work ...
// REAL_SetDpi = GetProcAddress(hDll, "SetThreadDpiAwarenessContext");
// (2) Using 'C'-style cast does work, but it is flagged as 'evil' ...
// REAL_SetDpi = (TYPE_SetDPI)GetProcAddress(hDll, "SetThreadDpiAwarenessContext");
// (3) Using reinterpret_cast: seems OK with clang-cl but MSVC doesn't like it ...
// REAL_SetDpi = reinterpret_cast<TYPE_SetDPI>(GetProcAddress(hDll,
// (4) Using a temporary plain "void *": OK with MSVC but clang-cl complains ...
void* tempPtr = GetProcAddress(hDll, "SetThreadDpiAwarenessContext");
REAL_SetDpi = reinterpret_cast<TYPE_SetDPI>(tempPtr);
// (5) Using a union (cheating? - but neither clang-cl nor MSVC give any warning!) ...
// union {
// intptr_t(__stdcall* gotProc)(void);
// TYPE_SetDPI usrProc; // This has the 'signature' for the actual function.
// } TwoProcs;
// TwoProcs.gotProc = GetProcAddress(hDll, "SetThreadDpiAwarenessContext");
// REAL_SetDpi = TwoProcs.usrProc;
if (REAL_SetDpi == nullptr) cout << "SetThreadDpiAwarenessContext function not found!" << endl;
else cout << "SetThreadDpiAwarenessContext function loaded OK!" << endl;
FreeLibrary(hDll);
return 0;
}
The various error/warning messages given by the clang-cl and native MSVC compiler, for each of the 5 options are as follows:
// (1) Simple assignment doesn't work ...
REAL_SetDpi = GetProcAddress(hDll, "SetThreadDpiAwarenessContext");
clang-cl -> error : assigning to 'DPI_AWARENESS_CONTEXT (*)(DPI_AWARENESS_CONTEXT) __attribute__((stdcall))'
(aka 'DPI_AWARENESS_CONTEXT__ *(*)(DPI_AWARENESS_CONTEXT__ *)') from incompatible type 'FARPROC'
(aka 'long long (*)()'): different number of parameters (1 vs 0)
Visual-C -> error C2440: '=': cannot convert from 'FARPROC' to
'DPI_AWARENESS_CONTEXT (__cdecl *)(DPI_AWARENESS_CONTEXT)'
message : This conversion requires a reinterpret_cast, a C-style cast or function-style cast
This error is (of course) expected, but the one confusing thing to me is why MSVC shows my function as __cdecl when I have explicitly declared it __stdcall?
// (2) Using 'C'-style cast does work, but it is flagged as dangerous ...
REAL_SetDpi = (TYPE_SetDPI)GetProcAddress(hDll, "SetThreadDpiAwarenessContext");
clang-cl -> warning : use of old-style cast [-Wold-style-cast]
Visual-C -> warning C4191: 'type cast': unsafe conversion from 'FARPROC' to 'TYPE_SetDPI'
warning C4191: Calling this function through the result pointer may cause your program to fail
Generally, I endeavour to completely avoid old, ‘C’-style casts in my code! Where I am forced to do cast between ‘unrelated’ objects, I use explicit reinterpret_cast operators, as these are far easier to track down in code if problems arise. So, for case 3:
// (3) Using reinterpret_cast: seems OK with clang-cl but MSVC doesn't like it ...
REAL_SetDpi = reinterpret_cast<TYPE_SetDPI>(GetProcAddress(hDll, "SetThreadDpiAwarenessContext"));
clang-cl -> No error, no warning!
Visual-C -> warning C4191: 'reinterpret_cast': unsafe conversion from 'FARPROC' to 'TYPE_SetDPI'
Calling this function through the result pointer may cause your program to fail
Here, the MSVC warning is pretty much the same as for the C-style cast. Maybe I could live with this, but case 4 makes things more interesting:
// (4) Using a temporary plain "void *": OK with MSVC but clang-cl complains ...
void* tempPtr = GetProcAddress(hDll, "SetThreadDpiAwarenessContext");
REAL_SetDpi = reinterpret_cast<TYPE_SetDPI>(tempPtr);
clang-cl -> warning : implicit conversion between pointer-to-function and pointer-to-object is a Microsoft extension
[-Wmicrosoft-cast]
warning : cast between pointer-to-function and pointer-to-object is incompatible with C++98
[-Wc++98-compat-pedantic]
Here, MSVC gives no warning – but I feel I’m simply ‘fooling’ the compiler! I can’t see how this can have any different overall effect than the code in case 3.
// (5) Using a union (cheating? - but neither clang-cl nor MSVC give any warning!) ...
union {
intptr_t(__stdcall* gotProc)(void);
TYPE_SetDPI usrProc; // This has the 'signature' for the actual function.
} TwoProcs;
TwoProcs.gotProc = GetProcAddress(hDll, "SetThreadDpiAwarenessContext");
REAL_SetDpi = TwoProcs.usrProc;
I did post this as an answer (now retracted), to which #formerlyknownas_463035818 pointed out that this is officially Undefined Behaviour and/or disallowed in C++ (the link given by the aforementioned commentator).
Which option do I currently use?
Well, as my software is specifically Windows-oriented, I use the last (option 4) for two reasons: (1) the clang-cl warning is the ‘least scary’; and (2) I like to think that MSVC is probably the best ‘mediator’ for compiling/building Windows apps.
EDIT: Since first posting this question, and having 'reviewed' the various comments and suggestions made, I have now changed all
instances of this type of cast (that is, from a function pointer
loaded via GetProcAddress) in my code to using the following
conversion 'function', defined in my global header file:
template<typename T> T static inline FprocPointer(intptr_t(__stdcall* inProc)(void)) {
__pragma(warning(suppress:4191)) // Note: no semicolon after this expression!
return reinterpret_cast<T>(inProc);
}
This allows for easy/rapid location of any such casts, should I need (or wish) to change the way they work in future.
Why does it matter?
Maybe it doesn’t! However, elsewhere in my code, I have come across an unexpected crash, when using function pointers loaded via GetProcAddress() - not any standard WinAPI calls, but functions from my own DLLs, loaded as plug-in modules. The code snippet below shows a potential case-in-point:
// --------------------------------------------------------------------------------------------------------------------
// These two routines are the 'interceptors' for plug-in commands; they check active plug-ins for handlers or updaters:
static int plin; //! NOTA BENE: We use this in the two functions below, as the use of a local 'plin' loop index
// is prone to induce stack corruption (?), especially in MSVC 2017 (MFC 14) builds for x86.
void BasicApp::OnUpdatePICmd(uint32_t nID, void *pUI)
{
//! for (int plin = 0; plin < Plugin_Number; ++plin) { // Can cause problems - vide supra
for (plin = 0; plin < Plugin_Number; ++plin) {
BOOL mEbl = FALSE; int mChk = -1;
if ((Plugin_UDCfnc[plin] != nullptr) && Plugin_UDCfnc[plin](nID, &mEbl, &mChk)) {
CommandEnable(pUI, mEbl ? true : false);
if (mChk >= 0) CmdUISetCheck(pUI, mChk);
return;
}
}
CommandEnable(pUI, false);
return;
}
void BasicApp::OnPluginCmd(uint32_t nID)
{
//! for (int plin = 0; plin < Plugin_Number; ++plin) { // Can cause problems - vide supra
for (plin = 0; plin < Plugin_Number; ++plin) {
piHandleFnc Handler = nullptr; void *pParam = nullptr;
if ((Plugin_CHCfnc[plin] != nullptr) && Plugin_CHCfnc[plin](nID, &Handler, &pParam) && (Handler != nullptr)) {
Handler(pParam);
return;
}
}
return;
}
Note that, Plugin_UDCfnc and Plugin_CHCfnc are arrays of function pointers, loaded as described above.
And, finally, what was my question, again?
Two-fold:
Is it ‘safe’ to ignore the warnings?
Is there a better way, using the Standard Library (I’m still getting used to using this)
– maybe something like std::bind()?
Any help, suggestions or recommendations will be greatly appreciated.
EDIT: I use the native MSVC compiler for my “Release” builds (with /Wall), and a few specific warnings explicitly disabled (locally) in code. From time to time, I run my entire code base through the clang-cl compiler, to look for other warnings of possible dodgy code (very useful, actually).
I think C/C++ are lacking a generic function pointer type, like void* as a generic object pointer type.
Generally, converting from one function pointer into another is supported, provided that you don't call the wrong function pointer type. See [expr.reinterpret.cast]/6:
A function pointer can be explicitly converted to a function pointer of a different type.
A warning that is issued when casting one function pointer type to another is generally useful. Having such casting might cause a call to a function with the wrong signature. Such a problem might affect only a certain CPU architecture, or be noticed only with certain OS builds, so it might not be apparent after initial testing. The Standard just says unspecified, see [expr.reinterpret.cast]/6:
Except that converting a prvalue of type “pointer to T1” to the type “pointer to T2” (where T1 and T2 are function types) and back to its original type yields the original pointer value, the result of such a pointer conversion is unspecified.
Whether void* can be converted to function pointer type and whether it even has enough bits is implementation specific. True for Windows, though. I wouldn't endorse Windows-specific habits for a generic problem. See
[expr.reinterpret.cast]/8:
Converting a function pointer to an object pointer type or vice versa is conditionally-supported.
Type punning with unions raises an issue with strict aliasing (What is the strict aliasing rule?), so not a good way to outsmart a compiler.
So, live with local warning suppression near your GetProcAddress calls, or in a GetProcAddess wrapper. Use reinterpret_cast.
If you're going to use a helper function that casts one function type into another without a warning, be sure to use it only in GetProcAddress-like scenario, when you use some generic signature to temporary store function pointer, but that signature is not an actual signature -- not to call a function pointer by a not intended type.
Sorry.
I have a very simple method with the following prototype:
void *station_0(void* p1);
I am calling it like this:
product_record r;
pthread_create(thread, NULL, station_0, (void *)&r);
Inside this method all I need to do is cast p1 to an already defined struct product_record, I am currently trying this inside of my method:
product_record p = (product_record)p1
but the compiler complains on that line(above) saying error: invalid conversion from 'void*' to 'int' [-fpermissive]
I don't think I understand this warning at all. Why cannot I simply cast a void* to my struct?
You need two steps - convert the void pointer to a product_record pointer and then de-reference that. This can be done in the line
product_record p = *(static_cast<product_record *>(p1));
I want to compile a project that I know works.
So I creat a Makefile to compile it, but when I make it I have this error:
invalid conversion from ‘void*’ to ‘LIMITOR_3DSL_Limitor_32f* {aka LIMITOR_3DSL_Limitor_32f_tag*}’ [-fpermissive]
*ppStatus = ippMalloc(sizeof(LIMITOR_3DSL_Limitor_32f));
^
It is really strange how could a void* can't be cast ?
Can the compiler be the problem ? I am using g++
Opposite to C in C++ you may not assign a pointer of type void * to a pointer of any other type because such an assignment is unsafe. You have to cast the pointer explicitly to the required type using a C or C++ form of casting.
For example
LIMITOR_3DSL_Limitor_32f *ppStatus = ( LIMITOR_3DSL_Limitor_32f * )ippMalloc( sizeof(LIMITOR_3DSL_Limitor_32f ) );
or
LIMITOR_3DSL_Limitor_32f *ppStatus = static_cast<LIMITOR_3DSL_Limitor_32f*>( ippMalloc(sizeof(LIMITOR_3DSL_Limitor_32f ) ) );
LIMITOR_3DSL_Limitor_32f* ppStatus = (LIMITOR_3DSL_Limitor_32f*)ippMalloc(sizeof(LIMITOR_3DSL_Limitor_32f));
In C/C++ we should cast type explicitly. ippMalloc will return a void * pointer, so we should cast it from void * to LIMITOR_3DSL_Limitor_32f*
Error 1 error C2036: 'const void *' : unknown size file.cpp 111
I don't follow. GCC never complains about void * pointer arithmetic, even on -ansi -pedantic -Wall. What's the problem?
Here's the code-
struct MyStruct {
const void *buf; // Pointer to buffer
const void *bufpos; // Pointer to current position in buffer
};
...
size_t someSize_t, anotherSize_t;
MyStruct *myStruct = (MyStruct *) userdata;
...
if ( (myStruct->bufpos + someSize_t) >
(myStruct->buf + anotherSize_t) ) { // Error on this line
...
You can't do pointer math on a void * pointer. Cast oData->bufpos and oData->anotherConstVoidPtr to something the compiler knows how to deal with. Since you seem to be looking for sizes, which are presumably in bytes, casting to char * should work:
if (((char *)oData->bufpos + someSize_t) ...
On the line:
if ( oData->bufpos ...
The type of bufpos is still void*. The compiler doesn't know what that pointer points to, so it gives you that error.
For pointer arithmetic, void* has no size, so taking an offset, or doing other pointer arithmetic doesn't make sense. Cast it to char* if you want to offset it by a number of bytes:
if(((char*)oData->bufpos) + offset ...
Edited after more code/context was given
If you can help it, try to use char* instead of void*. People in C-land will know what you are talking about, because chars are bytes, and you'll save yourself the headache of casting.
$3.9.1/9-
The void type has an empty set of values. The void type is an incomplete type that cannot be completed. It is used as the return type for functions that do not return a value. Any expression can be explicitly converted to type cv void (5.4). An expression of type void shall be used only as an expression statement (6.2), as an operand of a comma expression (5.18), as a second or third operand of ?: (5.16), as the operand of typeid, or as the expression in a return statement (6.6.3) for a function with the return type void.
I suspect an improper use of 'void' beyond what is allowed by the Standard.
It is really old post but even Visual Studio 2022 supports C11 and c17 MSVC is returning error if you try to add size to void pointer address but for GCC that is totally fine.
void* array_get_ref(const arr_t* this, size_t index)
{
return this->buffer + (index * this->item_size);
}
To solve problem on MSVC you need to cast void pointer to for example char* like this and it will work fine.
void* array_get_ref(const arr_t* this, size_t index)
{
return (char*)this->buffer + (index * this->item_size);
}
If we think it about: any pointer is giving us memory address, so begin of array in this case and we just need to add byte offset , index * item_size which is stored to struct when we created array. (casting does nothing in this case just tricks MSVC compiler)