linux-ext4 - Re: [PATCH 1/7] ext4: Introduce le32_t and le16

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 25 Sep 2007 21:15:47 +0530
From:	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
To:	Dave Kleikamp <shaggy@...ux.vnet.ibm.com>
CC:	linux-ext4@...r.kernel.org, adilger@...sterfs.com, cmm@...ibm.com
Subject: Re: [PATCH 1/7] ext4: Introduce le32_t and le16_t



Dave Kleikamp wrote:
> On Tue, 2007-09-25 at 14:33 +0530, Aneesh Kumar K.V wrote:
>> ext4 file system layout contain different split members
>> like bg_block_bitmap  and bg_block_bitmap_hi. Introduce
>> data type le32_t and le16_t to be used as the type of
>> these split members. This prevents these members frome
>> being accessed directly. Accesing them directly gives
>> a compiler warning. This helps in catching some BUGS
>> due to direct partial access of these split fields.
> 
> Ugh.  I don't like this typedef at all. It just makes the data type more
> confusing.


Confusing enough to make people look at them more carefully.



> 
> Why not just change the name of bg_block_bitmap to something like
> bg_block_bitmap_lo or _bg_block_bitmap?  It should be clear from the
> name that it shouldn't be used without careful consideration.
> 

even if we rename the variables, I guess we would like to have helper functions
for accessing these values. That would mean the code is finally going to look more
or less the same except the typedef. But the typedef actually save us from serious
misuse of these variables.


-aneesh
-
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html