Date: Tue, 1 Jul 2014 15:31:04 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: unsure about the correctness of O_ACCMODE definition On Tue, Jul 01, 2014 at 09:08:15PM +0200, u-igbb@...ey.se wrote: > Hello, > > I am troubleshooting lilo linked against musl. The combination does not > work which is not surprising: > > It looks like there are two incompatible interpretations of O_ACCMODE > in musl and in lilo. > > musl: > > ---- > #define O_ACCMODE (03|O_SEARCH) > ---- > > lilo: > > ---- > #ifdef O_ACCMODE > # define O_NOACCESS O_ACCMODE > #else > ... > ---- > (it makes open(...,O_NOACCESS) which succeeds, fully according to > opengroup.org: O_SEARCH in open(<non-dir>) leads to "undefined results" > but doesn't have to fail; then lilo tries ioctl() on the resulting fd, > which fails) Using a value of 3 as the argument to open is a traditional Linux extension for getting an fd that's usable only for ioctls. That's reasonable. What's not reasonable or correct is using O_ACCMODE as a way to get a 3. > Then there is > http://pubs.opengroup.org/onlinepubs/7908799/xsh/fcntl.h.html : That document is from 1997. The current version of it is: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/fcntl.h.html And as you can see, O_SEARCH and O_PATH are required to be included in the bits for O_ACCMODE. > I feel that the heuristics used in lilo is flawed but I lack firm > arguments to be able to say it is a bug (O_NOACCESS per se > seems to be obscure / non-standard / hardly documented). Simply the current version of the standard is all you need to show it's wrong. > I feel on the other side that the definition of O_ACCMODE in musl is > questionable and wonder whether anybody can comment on what and why > is right. Because it's required by the standard. Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.