linux-ext4 - Re: Use of consistent types in e2fsprogs

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, 17 May 2011 06:36:11 -0400
From:	Theodore Tso <tytso@....EDU>
To:	Andreas Dilger <adilger.kernel@...ger.ca>
Cc:	Ext4 Developers List <linux-ext4@...r.kernel.org>,
	Lukas Czerner <lczerner@...hat.com>
Subject: Re: Use of consistent types in e2fsprogs

On May 17, 2011, at 1:04 AM, Andreas Dilger wrote:

> I'm not suggesting a global search & replace of "long long" or anything.
> However, the current mish-mash of int vs. long vs. dgrp_t for group numbers,
> __u64 vs blk64_t, etc doesn't make it clear when something is intentionally
> that type, or just happens to be working for now.  Having separate types
> for groups vs. physical blocks vs. logical blocks as we do in the kernel
> will improve the quality of the code itself, I think.

But you are talking about doing a global search and replace of "e2_blkcnt_t"
for something else like "ext2_logblk_t", aren't you?   If we need to better
document all of the types, yes, that will probably help.

But I don't see how a global search and replace of "dgrp_t" for "ext2_group_t"
is going to help us find the places where a group number was assigned to
an int.

Yes, the naming scheme is inconsistent.   e2fsprogs is a very old code base,
and many of these decisions were made a very long time ago.  But I don't
see how a global search and replace of one typedef name for another will
_find _bugs_.   It won't help in the cases where we used a raw type, and it
won't help where we accidentally used the wrong typedef'ed name.

It might help a new comer to the code base when they are writing new code,
yes.   So would better documentation.   Against that we have to weigh
the cost of the code churn, and the fact that patches to the maint branch
won't be easily pulled to master, etc.

-- Ted

--
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