Closed edwardhartnett closed 1 year ago
This same problem seems to happen with numbck()
As noted in #399 and some other discussions, there are many library routines that are only ever expected to be called internally , and where everything is now built as _4 only inside the library. Both nemock() and numbck() are in that category, so they don't contain the needed im8b wrappers which would allow them to be called and work correctly with 8-byte integers.
Now that said, in these particular routines, there are no integer arguments, and it's only the return code (the function value itself) that's an integer that we need to worry about. So this is a slightly different bird and the im8b wrappers aren't really needed. However, and again, since the library is only built as _4 now, then these routines will always return 4-byte integer values, even when they're called from a code where the default integer size is 8-byte. And if you try to interpret that return value as anything other than a 4-byte integer, you may indeed get unexpected results.
So bottom line, in test_misc.F90 you have two choices for these routines:
integer*4 nemock, numbck
. In other words, hardcode those function declarations as 4-byte values, and then it should work correctly under all of the test_misc_4, test_misc_8, test_misc_d, etc. variations. This is how we do it in many of the test/intest and test/outtest codes for other library functions which return integer values (e.g. ireadmg, ireadsb, ireadns, nmsub, iupbs01, etc.)Yes, I understand now. I will close this issue.
We have function nemock(), which I have some tests for in test_misc.F90:
These tests fail for the 8-byte build of the test. It seems to want to return nemock()'s value as a 4-byte int, even in the 8-byte build.
I have left this test in test_misc.c, commented out, for future investigation.