Bug 144 - AbstractDb: numeric values stored and retrieved in host byte order
Summary: AbstractDb: numeric values stored and retrieved in host byte order
Status: NEW
Alias: None
Product: repro
Classification: Unclassified
Component: proxy (show other bugs)
Version: unspecified
Hardware: All All
: P1 normal
Assignee: Owner of all unassigned bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-02-14 10:17 CST by Daniel Pocock
Modified: 2019-02-14 10:17 CST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Pocock 2019-02-14 10:17:42 CST
When encoding numeric values for storage into BDB or SQL, the numeric values are written to a buffer in host byte order, e.g the len value in the encodeString method:

https://github.com/resiprocate/resiprocate/blob/master/repro/AbstractDb.cxx

static void 
encodeString(oDataStream& s, const Data& data)
{
   short len = (short)data.size();
   s.write( (char*)(&len) , sizeof( len ) );
   s.write( data.data(), len );
}

This happens in various places in the code, not just the encodeString method.

This would be troublesome for somebody who tries to access the same database from both little endian and big endian systems.  It is also difficult for somebody implementing views and stored procedures in the database to know the byte order of the host accessing the data.  Ideally, these values would be stored in network byte order.

As each row includes a numeric version value written in host byte order, that could be used as a clue to determine the byte order of the numbers stored in the database and implement some kind of safety check at startup or call a function to automatically convert the whole database to network byte order.

This issue would be resolved for SQL backends if the (attr,value) tables are split into individual columns, as for the users table.  It would still need to be fixed for the BDB backend though.