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, 19 May 2009 10:05:32 -0400
From:	Andreas Dilger <adilger@....com>
To:	Jan Blunck <jblunck@...e.de>
Cc:	viro@...iv.linux.org.uk, bharata@...ibm.com, dwmw2@...radead.org,
	mszeredi@...e.cz, vaurora@...hat.com, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [PATCH 30/32] union mount: ext2 fallthru support

On May 19, 2009  11:42 +0200, Jan Blunck wrote:
> On Mon, May 18, Andreas Dilger wrote:
> > For enums like this that require specific constant on-disk values
> > I prefer being safe:
> > 
> > enum {
> > 	EXT2_FT_UNKNOWN  = 0,
> > 	EXT2_FT_REG_FILE = 1,
> > 	EXT2_FT_DIR	 = 2,
> > 	EXT2_FT_CHRDEV   = 3,
> > 	EXT2_FT_BLKDEV   = 4,
> > 	EXT2_FT_FIFO     = 5,
> > 	EXT2_FT_SOCK     = 6,
> > 	EXT2_FT_SYMLINK  = 7,
> > 	EXT2_FT_WHT      = 8,
> > 	EXT2_FT_FALLTHRU = 9,
> >  	EXT2_FT_MAX
> > 
> > 
> > It probably also makes sense to include a patch for ext3/ext4 to ensure
> > these values are not used by some unrelated feature.
> 
> In ext3 these are preprocessor defines. IIRC defines and enums are identical
> for C (both an int) so I leave this untouched and just add the new filetypes,
> right?

The problem is - what happens if, for whatever reason, EXT2_FT_WHT is
removed?  In a regular enum EXT2_ET_FALLTHRU would get the old value for
EXT2_FT_WHT (=8).  Alternately, if someone accidentally adds a value
before EXT2_FT_WHT because this isn't in the upstream e2fsprogs[*] and
this would push the values of EXT2_FT_WHT and EXT2_FT_FALLTHROUGH up.

That is why, when using enums for on-disk or "external" interfaces, I
prefer that the values are explicitly specified.  It also makes it more
clear when reading the code that these values are static and should not
be changed, instead of just a grouping of related constants.


[*] should be the canonical resource for new on-disk assignments, IMHO

Cheers, Andreas
--
Andreas Dilger
Sr. Staff Engineer, Lustre Group
Sun Microsystems of Canada, Inc.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ