The file drizzled/korr.h contains macros which read and write raw data
in a cross-architecture-compatible way. Something has always bothered
me about these macros: their names.
At the top of korr.h, we find the following comment:
/*
* Define-functions for reading and storing in
* machine independent format
* (low byte first)
*
* No one seems to know what "korr" means in this context.
* A global search and replace would be fine if someone
* can come up with a better description.
*/
I say it's time to do this. "korr" just doesn't seem to be either
descriptive or, well, in the English language.
In this file, we have the following macros:
sint2korr(A)
sint3korr(A)
sint4korr(A)
sint8korr(A)
uint2korr(A)
uint3korr(A)
uint4korr(A)
uint5korr(A)
uint6korr(A)
uint8korr(A)
in the above, A is a pointer which has been allocated on the heap.
Typically, the pointer A is the Field::ptr member variable, which is
usually allocated with the amount of storage for X number of bytes,
where X is the storage needed for the column type.
int2store(T, A)
int3store(T, A)
int4store(T, A)
int5store(T, A)
int6store(T, A)
int8store(T, A)
in the above, T is a pointer to store the value of A in a portable
fashion. Essentially, these are the counterparts for the "korr" functions.
doubleget()
doublestore()
float4get()
float8get()
float4store()
floatget()
floatstore()
The above are a little more aptly-named macros for doing similar things
with doubles and floats, though they are really not used except for a
couple specific places in the MyISAM and MEMORY storage engines. It
would be nice if someone verified their behaviour, as I am quite sure
these macros haven't been looked at in 10 years or so...
int4net()
This isn't used anywhere and I'm deleting it. Not surprising,
considering it seems to do nothing more than the ntohl() function
ushortget()
Dead code. Not used anywhere.
shortget()
ulongget()
longget()
shortstore()
longstore()
Mostly just refer to sint2korr() and uint2korr() but might be useful?
int64_tget()
int64_tstore()
These are defined the same regardless of architecture as:
#define int64_tget(V, M) memcpy(&V, (M), sizeof(uint64_t))
#define int64_tstore(T, V) memcpy((T), &V, sizeof(uint64_t))
I am completely unsure why these were added and the int8store() and
int8korr() macros not used? In addition, the definitions of uint8korr()
and int8store() are not the same as the definitions of int64_tget() and
int64_tstore(), though I am not sure why this is the case...
Anybody have votes or opinions on the following questions:
1) Should we rename "korr" to something more meaningful? If so, what?
change "korr" to "get"? or "read"?
2) Are these macros still needed? Are they premature optimization? Are
they available in an open source library already?
3) Can we safely change all references of unsigned char to uint8_t?
This would blend nicely with eday's new protocol library...
Thanks in advance for your thoughts.
Cheers,
Jay
_______________________________________________
Mailing list: https://launchpad.net/~drizzle-discuss
Post to : [email protected]
Unsubscribe : https://launchpad.net/~drizzle-discuss
More help : https://help.launchpad.net/ListHelp
