@all Lately found some issues in some port, and reduced it to some test case which simple fail on amigaos4 compiled with both clib2 and newlib. Through, one of many tests works for clib2, but not all. So, there is test case:
test <uintptr_t> (1, "%" PRIuPTR);
test <uint_least64_t> (1, "%" PRIuLEAST64);
test <uint_fast64_t> (1, "%" PRIuFAST64);
test <uint64_t> (1, "%" PRIu64);
test <intptr_t> (1, "%" PRIdPTR);
test <int_least64_t> (1, "%" PRIdLEAST64);
test <int_fast64_t> (1, "%" PRIdFAST64);
test <int64_t> (1, "%" PRId64);
Your test code has a problem where "int x" is 32-bit, but %llu/%lld needs a 64-bit value. The code might happen to work correctly on little-endian machines, provided that the next 32-bit value in memory happens to be 0. On big-endian machines like ours you're guaranteed to get a big number...
You should replace "int x" with "T x". T gets replaced with the template parameter (e.g., uintptr_t, uint64_t). Then the code should work.
%lu & %ld are for 32-bit values, which is why some clib2 tests are passing. Your results suggest that PRIuPTR is 32-bit for clib2 but 64-bit with newlib for some reason.
As far as I understand the newlib inttypes.h header file that was included with the SDK was an internal newlib header that should only be used for building newlib itself. When I encountered and reported this problem a few years back I was told to either remove the file or make a new one with the correct values.
I added a fixed version of the inttypes.h header to be used instead, in newlib V53.49 but since the latest public SDK is much older it still has the broken header file.
If your trying to port a linux program you could try to look for a HAVE_INTTYPES_H define and disable it (what I did for dvdauthor IIRC) or you could edit the inttypes.h header to replace the macros with correct definitions.
That's correct. My suggestion would screw up the %d snprintf() above. Your modification will ensure that the input value is the correct type.
@kas1e Try salass00's suggestion. If it still isn't working, then check what sizeof() says it the size of each of the types you're testing. Sizeof() should report 4 for 32-bit types, and 8 for the 64-bit ones.
@kas1e Forget all the stuff from above (edit: well, not all, I overlooked Salass' newlib inttypes.h issue). There simply is a little typo in your code:
const T y = x; char buf_2[20] = {0}; snprintf(buf_2, sizeof(buf_2), fmt, x);
You see, you never use y... That's how it should be:
const T y = x; char buf_2[20] = {0}; snprintf(buf_2, sizeof(buf_2), fmt, y);
Salass' cast (T)x would do too, of course, but the true problem here is the x/y typo. And in C++ you'd actually prefer to write static_cast<T>(x) instead of (T)x, but well.
Edited by Daytona675x on 2020/2/6 13:20:33 Edited by Daytona675x on 2020/2/6 17:03:58
@All Thanks all for help ! Yeah, there was a typo indeed. With that typo fixed all the clib2 tests passes fine, but newlib's ones fail on PRIuPTR and on PRIdPTR. Once i replaced inttypes.h from latest public SDK on one from latest beta of newlib as Salas00 says: all tests passes.
And I think the moral of the story here is "Don't take code from other platforms as being bug free and great examples of talented coders".
:)
Simon
Comments made in any post are personal opinion, and are in no-way representative of any commercial entity unless specifically stated as such. ---- http://codebench.co.uk
"Don't take code from other platforms as being bug free and great examples of talented coders"
Exactly. Just a few days ago I ported a piece of Linux code that allowed writing 200 bytes into a 140-byte buffer. When I pointed that out, the author just said, "Oops..." )
Well, it was just a fast written test case, to check if we have issues in newlib. So, once the test case was fixed it indeed points out us on newlib's issue, which was fixed in a beta of newlib.
If newlib didn't have that bug in the first place, there weren't needs for test-example, as we create it only when start to have issues related to it.
I mean it's wasn't code from the real-life app, its just test-case which was written because some bigger program give us related bugs, and so we made a test case to find out the real bug, and we find it in newlib, just lucky it was already fixed in beta by Salas00.
And moral there not only that endianes matter and programmers less and less care about, but that our official libc newlib have issues from time to time :)
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
)