Please rename them. I remember "korr" being very confusing when I first started working on mysql.
On Mon, Jan 5, 2009 at 1:20 PM, Jay Pipes <[email protected]> wrote: > 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 > -- Eric Bergen [email protected] http://www.provenscaling.com _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
