This library, libpgeasy (ebuild alias dev-libs/libpgeasy) has an incorrect memory handling when getting raw values from PostgreSQL server, providing the values multiplied by 256^(field size in Bytes - 1). The bug is ocurring because it gets data (for example, for value 1) in this way from server: 0x0 0x0 0x0 0x1, and then uses it as it was given when the order has to be inverted to be usable. In particular, all the anormality is caused for calling memcpy() in functions fetch() and fetchwithnulls(). I'll attach a patch at the end of this message.
Created attachment 146173 [details, diff] Patch that should fix the incorrect handling
(In reply to comment #1) > Created an attachment (id=146173) [edit] > Patch that should fix the incorrect handling > ebuild name is not dev-libs/libpgeasy but dev-db/pgeasy.
Created attachment 146216 [details, diff] Patch that fixes the BUG in a Linux-based system. Apparently unnecessary in BSD systems. The old attachment inverted strings, copying, i.e., ANITNEGRA instead of ARGENTINA.
Created attachment 146217 [details] Program that shows the problem. This simple program in C shows how the order of the bytes affected the result.
Created attachment 146218 [details, diff] This patched header just adds C++ compatibility
(In reply to comment #3) > The old attachment inverted strings, copying, i.e., ANITNEGRA instead of > ARGENTINA. LOLZ....
The provided patch applies for Linux only. In BSD, the original code would work properly, as it was tested with the memcpy_t.c attachment.
Created attachment 146236 [details, diff] Fixes the BUG, AND is cross-platform,
Created attachment 146238 [details] Program that shows the problem and shows the proper way for the system (memcpy or memrev) This program implements a function to detect if it is needed or not to reverse the bytes order.
I'm sorry. But pgeasy seems to be dead. I've therefore masked it for removal. And I therefore won't fix this.
