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?