On Thu, Mar 06, 2014 at 01:13:35PM +0100, ☎ wrote:
That's why I referenced corresponding standard in the comment. I do not see how adding struct will help with remembering parameter names at night - I think it will increase code complexity and decrease readability. Besides those are parameters to internal-only functions - you are not supposed to work with this code without reading corresponding standard beforehand.
Maybe you don't remember but you wil get the order right. Why do you want/ need to export the methods then? :)
I was more thinking about what exactly do you want to test? Encode/Decode being compatible with each other? Corner cases? This is very difficult to understand code and I don't see your intend. I wonder/guess that there is a more simple approach to it.
I'll add more comments to clarify - in general, I do not see better approach for serialize/deserialize kind of functions than trying to read/write and compare the results.
Max, what do you want to test?
Would you mind to be more specific? I know that it's linux-kernel style but it would greatly help if you spend 3 more seconds to add few words to clarify what exactly you're unhappy about - for example in this particular case I've been confused by the undescriptive comments from previous email.
if (foo) {
and not if (foo)\n{
Is there some general way to mark function as internal-use only? For example the only reason I'm exposing _kasumi* is to be able to use them in test/kasumi_test code.
ANSI C. E.g. in C99 Chapter 7.1.3 Reserved identifiers: "All identifiers that begin with an underscore and either an uppercase letter or another underscore are always reserved for any use."
Okay _kasumi is actually fine, __kasumi would not, _KASUMI would be neither. My take is that it is best to avoid anything close to reserved symbols. :)
these tables were copied from the spec?
Yes, sure. The test vectors in kasumi_test were taken from the spec as well.
do you want to add another reference?