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  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:	Sun, 2 Nov 2008 22:09:36 -0500
From:	Theodore Tso <>
To:	Valerie Aurora Henson <>
Cc:, "Jose R. Santos" <>
Subject: Re: 64-bit dblists

On Mon, Oct 27, 2008 at 04:59:10PM -0400, Valerie Aurora Henson wrote:
> Hi all,
> In my continuing quest to finish the 64-bit conversion of e2fsprogs, I
> ran into this structure exported in ext2fs.h:
> struct ext2_db_entry {
>         ext2_ino_t      ino;
>         blk_t   blk;
>         int     blockcnt;
> };
> The "blk_t" is the problem here - we need a blk64_t.  A pointer to
> this structure is passed to the user-provided directory block iterator
> in ext2fs_dblist_iterate().
> Assuming the goal is to preserve the ext2fs_dblist ABI, I can see two
> ways of doing this:
> 1. Define ext2_db_entry2, ext2_dblist2, and ext2fs_dblist_*2() and do
> the usual translation/conversion function business.

The dblist.c and dblist_dir.c functions are so small that it's
probably not worth it to do translaction/conversation functions; it's
basically just a linked list convenience function implementation.

My suggestion is to just create a dblist2.c and dblist_dir2.c, and
just make a 64-bit version of the directory block list abstraction.
My guess that size of the conversaion functions would be bigger than a
new 64-bit version of the abstraction.  (The object size of dblist.o
and dblist_dir.o combined is only about 1.5k)

    		 	     	  	- Ted
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to
More majordomo info at

Powered by blists - more mailing lists