Date: Fri, 22 Mar 2013 08:50:46 +0100 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Bruce Evans <brde@optusnet.com.au> Cc: Konstantin Belousov <kostikbel@gmail.com>, freebsd-arch@freebsd.org Subject: Re: chflags(2)'s flags argument. Message-ID: <20130322075046.GD1356@garage.freebsd.pl> In-Reply-To: <20130322155410.D953@besplex.bde.org> References: <20130317111112.GC1364@garage.freebsd.pl> <20130317155743.GR3794@kib.kiev.ua> <20130317162021.GG1364@garage.freebsd.pl> <20130317162533.GT3794@kib.kiev.ua> <20130317164632.GI1364@garage.freebsd.pl> <20130317174205.GU3794@kib.kiev.ua> <20130317211027.GJ1364@garage.freebsd.pl> <20130318155059.V925@besplex.bde.org> <20130318210817.GA1367@garage.freebsd.pl> <20130322155410.D953@besplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--0IvGJv3f9h+YhkrH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable First of all, sorry Bruce, I saw you being active on other threads and assumed you have no other comments so I went ahead and committed this change to not to delay introduction of chflagsat(2) any further. On Fri, Mar 22, 2013 at 04:20:15PM +1100, Bruce Evans wrote: > On Mon, 18 Mar 2013, Pawel Jakub Dawidek wrote: > > I'd prefer leave u_long, as it breaks API as little as possible. This is > > also the type that's being used by consumers of this API, as it was > > documented in chflags(2) since forever. Also, as I already mentioned, > > strtofflags(3) and fflagstostr(3) uses this type too. >=20 > When changing an API, it is best to change it in the correct direction. I don't think we can change strtofflags(3) and fflagstostr(3) API in an non-disruptive way. Because of how chflags(2) and fchflags(2) were documented for so long and how their prototypes where defined in sys/stat.h I'm sure most applications assume they take u_long as flags. So when choosing between those two options (u_int vs. u_long) making it consistent with what applications expect is more important. For me the main goal was to make chflags(2), fchflags(2), lchflags(2) and chflagsat(2) to use the same type for the flags argument, so which tyoe exactly is secondary to me, but I still believe u_long is better (less risky) choice. > > Using u_long for chflags() prototypes in sys/stat.h will only work, > > because of this: > > > > #if !defined(_KERNEL) && __BSD_VISIBLE > > /* > > * XXX We get miscellaneous namespace pollution with this. > > */ > > #include <sys/time.h> > > #endif > > > > As sys/time.h will include sys/types.h, eventhough sys/stat.h is trying > > to avoid that at the begining. >=20 > I wrote the comment. mike@(gone) fixed the prototypes for *chflags() > so that they don't depend on the namespace pollution. But sys/time.h > still has massive namespace pollution with many other dependences on > the pollution in sys/types.h. >=20 > Of coarse the header must not use the polluting spelling, but the > implementation can use any spelling it wants. >=20 > Actually the header should use the flags type __fflags_t. That is > __uint32_t. This is currently unusuable since the prototypes are > incompatible with it. Changing the prototypes to it would fix them > in the way that I want. Fixed-width types in APIs are design errors, > but we don't worry about that for mode_t, uid_t, ... 32-bit fixed > width types cause fewer problems than most since vax is the only > supported arch so ints are always 32 bits. >=20 > In glibc-2.6, chflags() takes type int for hurd and the default > chflags() (a stub that returns ENOSYS) also takes int. So in ~20 years > when POSIX gets around to standardizing this, it would have to use a > typedefed type like fflags_t, and to support the FreeBSD mistakes it > would need different types for struct stat and the prototypes. >=20 > In linux-2.6.10, file flags are set by ioctl(). ioctl() in linux has > almost the same prototype as in BSD, so the arg type is unsigned long. > glibc-2.6 doesn't have any special support for this ioctl, and the > flags bits depend on the fs for both their name and their number, so > file flags are or were even harder to use in Linux than in FreeBSD, > and further from being standardizable. glibc-2.6 has an fs-independent > bit in mount.h, with a warning that only newer systems support it. > linux-2.6.10 is too old to support it. I you feel strong about using u_int for flags, I'm not oppose to you changing it, as long as you change it for all chflags syscalls:) --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --0IvGJv3f9h+YhkrH Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlFMDVYACgkQForvXbEpPzRJnACeLWV6pQ96EpkTABiHY8UOYMP+ AoUAoOCKM/GhDSrNg4WlMvNQB2HESqLo =sWzI -----END PGP SIGNATURE----- --0IvGJv3f9h+YhkrH--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130322075046.GD1356>