|
From: Richard R. <nt...@fl...> - 2002-07-11 12:01:10
|
Hi Anton,
> >attrib.c is getting much too big. it's more than triple the size of
> >anything else. I want to move the the runlist code into runlist.c
> >(about a third of the code).
>
> Great idea. I like the name. I take it you volunteer to do the split? (-;
> btw. This is so obvious that it is silly to write it so I appologise in
> advance, but please use a runlist.h header as well...
OK, the first stage is done.
> I would vote for ./configure --enable-debug -> print loads of stuff to
> stderr. ./configure --disable-debug -> print to stderr only in really
> serious cases like the segfault about to be caused.
OK
> >Testing. This word is the bane of all programmers. I hate it too, but
> >I understand the need for it. We cannot anticipate every use of the
> >library, but we should have some form of unit testing. The library is
> >still undergoing a lot of changes and it's hard to verify that nothing
> >has broken. Any suggestions or guidelines would be welcome.
>
> Sorry no suggestions or guidelines, but a regression test suite where we
> just need to type "make test" would be very nice indeed...
I'll start thinking what we can automate.
> >Back to attrib.c. It's a very complicated piece of code.
> Yes. It is code to edit a database... That is a complicated thing.
>
> It depends what exactly you want to simplify. You had mentioned to me
> before that you don't like the frequent offset additions like this:
>
> FILE_NAME *fn;
> ATTR_RECORD *attr;
>
> fn = (FILE_NAME*)((u8*)attr + le16_to_cpu(attr->value_offset));
>
> I agree those are quite horrible and very long. Considering how they are
> used we can make a generic macro, (please suggest a name!), lets call it
> GF() for now just to show what it could look like.
>
> fn = GF(attr, value_offset);
> #define GF(a, b) ...
> #define le_to_cpu(x) ...
That's the sort of thing I was toying with. Terrifying, but it covers
adjusting the le_to_cpu sizes according to the struct member. What
hadn't occurred to me, scribbling on bits of paper, was that because
it's all const, the whole thing would optimise away. Nice.
> The prize question is what to call the GF() macro!
Naming's always the hardest bit :-)
GM = get member
GV = get value
OFF = offset
PTR = pointer
Some combination of the above?
Cheers,
FlatCap (Rich)
nt...@fl...
WWW: http://linux-ntfs.sf.net
IRC: #ntfs on irc.openprojects.net
|
