zgimbutas
commented
4 years ago Hi Alex,
We have had an issue with portability of int64_t type and friends between C and C++ compilers. Together with Libin we decided to include support for int64_t only if _INT64_T is defined, so the code is behaving as it should. int64_t is only in the new standards of C (starting from C99) and C++, and does not work well with older C. Including support for int64_t by default does break old compilers. The main question is whether there is a standard/portable way to detect int64_t support inside the compiler. I am not aware of one. Defining _INT64_T is a workaround.
Or should we drop pre-C99 compilers? This will include all gcc compilers before version 4.5.0 or so. I am still using gcc 4.4.7 as a windows cross-compiler but I can switch. Do you still use older gcc?
Best, Zydrunas
P.S. In my head: rap a.k.a. Weird Al Yankovich: In a 64-bit world you are a 32-bit user, you’ve got a new subreddit /r/total-loser
On Jun 10, 2020, at 8:44 AM, Alex Barnett notifications@github.com wrote:
Dear Zydrunas, I am using your new 0.33.9 with our finufft mex interface, but find (by looking in the generated .cpp) that unless _INT64_T is #defined, it can't compile:
/home/alex/numerics/finufft/matlab/finufft_plan_mex.cpp: In function ‘void mexStub5(int, mxArray, int, const mxArray)’: /home/alex/numerics/finufft/matlab/finufft_plan_mex.cpp:842:16: error: ‘mxWrapGetArray_int64t’ was not declared in this scope in2 = mxWrapGetArray_int64_t(prhs[2], &mw_errtxt); ^
~~~~~Our .mw is here: https://github.com/flatironinstitute/finufft/tree/guruInterface_v2/matlab https://github.com/flatironinstitute/finufft/tree/guruInterface_v2/matlab If I put -D_INT64_T on mex compile line, it works. However, int64_t is a standard type, so shouldn't this be included by default?
The whole reason I'm using int64_t is because long is ambiguous; a compilation of such types on different platforms is here:
https://stackoverflow.com/questions/13604137/definition-of-int64-t#:~:text=int64_t%20is%20guaranteed%20by%20the,so%20it%20could%20be%20more.&text=Thus%2C%20int8_t%20denotes%20a%20signed,width%20of%20exactly%208%20bits https://stackoverflow.com/questions/13604137/definition-of-int64-t#:~:text=int64_t%20is%20guaranteed%20by%20the,so%20it%20could%20be%20more.&text=Thus%2C%20int8_t%20denotes%20a%20signed,width%20of%20exactly%208%20bits.
Best, Alex
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/zgimbutas/mwrap/issues/1, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABWJ3GQNYCZTIS44TVH5M7TRV6L4JANCNFSM4N2OOVJA.
ahbarnett
Dear Zydrunas, I am using your new 0.33.9 with our finufft mex interface, but find (by looking in the generated .cpp) that unless _INT64_T is #defined, it can't compile:
/home/alex/numerics/finufft/matlab/finufft_plan_mex.cpp: In function ‘void mexStub5(int, mxArray, int, const mxArray)’: /home/alex/numerics/finufft/matlab/finufft_plan_mex.cpp:842:16: error: ‘mxWrapGetArray_int64t’ was not declared in this scope in2 = mxWrapGetArray_int64_t(prhs[2], &mw_errtxt); ^
~~~~~Our .mw is here: https://github.com/flatironinstitute/finufft/tree/guruInterface_v2/matlab
If I put -D_INT64_T on mex compile line, it works. However, int64_t is a standard type, so shouldn't this be included by default?
The whole reason I'm using int64_t is because long is ambiguous; a compilation of such types on different platforms is here:
https://stackoverflow.com/questions/13604137/definition-of-int64-t#:~:text=int64_t%20is%20guaranteed%20by%20the,so%20it%20could%20be%20more.&text=Thus%2C%20int8_t%20denotes%20a%20signed,width%20of%20exactly%208%20bits.
Best, Alex