This is the mail archive of the
mailing list for the eCos project.
Re: Overlapping #defines in isoinfra/current/include/sys/stat.h
On Tue, Jul 08, 2003 at 04:40:29PM -0600, Gary Thomas wrote:
> Scott Wilkinson said:
> > I was having a problem mounting JFFS2, which I tracked down to what I
> > believe is a problem in /packages/isoinfra/current/include/sys/stat.h.
> > The problem is that the (somewhat recent) addition of:
> > #define __stat_mode_LNK (1<<8)
> > #define __stat_mode_SOCK (1<<9)
> > #define S_IFMT (S_IFDIR|S_IFCHR|S_IFBLK|S_IFREG| \
> > S_IFIFO|S_IFLNK|S_IFSOCK)
> > conflicts with the long-standing definition of:
> > #define S_IRUSR (1<<8)
> > #define S_IWUSR (1<<9)
> > This is a problem for JFFS which uses a single field to hold both
> > mode and permission information. This is manifested by problems when
> > using S_IFMT to mask off the mode bits. Problem is that it also catches
> > the S_IRUSR|S_IWUSR permission bits, which confuses things. (Check out
> > os_to_jffs2_mode() in jffs2/current/src/os-ecos.h specifically.)
> > I'm not sure what the correct answer is, but my solution was to change the
> > definition of S_IFMT to remove the S_IFLNK|S_IFSOCK bits. This may cause
> > trouble with people who use links though?
> I'd think it would be better to renumber the S_IRUSR... bits
> to start with 16 which would give longer-term stability.
> There shouldn't be any programs out there that use hard coded
> bits, so this should be OK - or at least it should be possible
> to make it work properly.
But there will be filesystems with these bits. Anybody with a romfs in
flash could have problems if we move these bits up to the second half
of the word. The access permissions suddenly mostly become 0. Luckly
the romfs does not seem to actually check the bits when opening a
file. So in practice it probably does not matter.
So what do people think? Move the bits and email a warning to