|
From: Szakacsits S. <sz...@si...> - 2004-02-29 03:21:28
|
Hello, I CC: this to linux-ntfs-dev, the origin of the email is here, http://sourceforge.net/forum/forum.php?thread_id=1030888&forum_id=44084 On Sat, 28 Feb 2004, john doe wrote: > I'm directing this message to you becouse I assume it would > not have (much) public intrest. It has, we discuss issues. > I followed you advice, and went through the dev's mailing list > archive, till I found a year back discussion about the > -fms-extensions. due to that thread I noticed that the kernel > driver is actually not using unnamed structures, but the patch > was not applied to the lib. > > I havn't found a direct reason in the mailing-list, but that > thread, and your reply of "would make developers life harder" > implied that you (the main developers) simply do not like that > fix. > > I am only holding on to that matter becouse I can't use for > some reason the "-fms-extensions", but still want the ability > to distibute my code with the standard library (not a hevily > patched one). > > can you please enlight me about that matter? http://marc.theaimsgroup.com/?l=linux-ntfs-dev&m=104878222521219&w=2 My recommended solution was here, http://marc.theaimsgroup.com/?l=linux-ntfs-dev&m=104887740430985&w=2 In more verbose, what could be beneficial for everybody is 1) making the unnamed -> named conversion AND 2) encapsulating the details in macros or inline functions Let's see an example: now: a->data_size = cpu_to_le32(le32_to_cpu(a->data_size) + 2); you want: a->n.data_size = cpu_to_le32(le32_to_cpu(a->n.data_size + 2); could be: ntfs_attr_datasize_set(a, ntfs_attr_datasize_get(a) + 2); The last one might be even more simple if it made sense in the future, ntfs_attr_datasize_add(a, 2); This has the following advantages: - better portability - more readable - more reliable code (endianness can't be forgotten) - with well chosen names, much less to type/read/print Would you be willing to do both conversations, not only the unnamed one? Cheers, Szaka |
