Hi Jean-Pierre,
On Mon, 1 Oct 2007, [UTF-8] Jean-Pierre AndrĂŠ wrote:
> Another point, about endianness : I have redefined macroes
> to check endianness at compile-time,
Good. I'm also just working on full 32-bit endiannes validation.
Compile-time check, sparse are very useful but I don't trust them
exclusively. I also want to be sure that the NTFS metadata image
files are also exactly the same, after running the exact same static
tests on the same image file.
After running ntfsclone --metadata ... for "normalization", ntfscmp
can be used to compare the images which should match.
> but I had to redefine many fields in layout.h because most disk images
> are defined as u16, u32 etc. instead of le16, le32, etc.
What do you exactly mean by "disk images"?
> I think the option of enabling compile-time checks is
> useful. I have found several errors in my code, but also
> two errors outside my code :
>
> in ntfs_ie_get_next() from index.c there is a le16_to_cpu()
> which should be le32_to_cpu() and is wrong on BE boxes.
The longer term idea is to use macros to access on-disk fields,
e.g. instead of
le16_to_cpu(a->mapping_pairs_offset)
one could write
NAttrRecMPOffset(a)
which could make the source more readable, compact, less error-prone
and no need to care about such variable types and sizes __explicitely__.
> in ACCESS_ALLOWED_ACE from layout.h, the field
> mask is defined as an enum whose size depends both on
> the architecture and the compiler, whereas it should be
> defined as a le32.
Thank you for the bug reports. If you're sure that something is wrong and
can be fixed quickly then feel free to commit the fixes immediately.
Thanks!
Szaka
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
ntfs-3g-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ntfs-3g-devel
