Date: Sun, 17 Mar 2013 17:20:22 +0100 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: freebsd-arch@FreeBSD.org Subject: Re: chflags(2)'s flags argument. Message-ID: <20130317162021.GG1364@garage.freebsd.pl> In-Reply-To: <20130317155743.GR3794@kib.kiev.ua> References: <20130317003559.GA1364@garage.freebsd.pl> <20130317064123.GM3794@kib.kiev.ua> <20130317111112.GC1364@garage.freebsd.pl> <20130317155743.GR3794@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
--yZnyZsPjQYjG7xG7 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Mar 17, 2013 at 05:57:43PM +0200, Konstantin Belousov wrote: > On Sun, Mar 17, 2013 at 12:11:12PM +0100, Pawel Jakub Dawidek wrote: > > On Sun, Mar 17, 2013 at 08:41:23AM +0200, Konstantin Belousov wrote: > > > The patch seems to keep ABI intact for all useful purposes, at least > > > on all architectures the FreeBSD supports. A FreeBSD architecture whe= re > > > sizeof(int) !=3D sizeof(long), uses register calling conventions. > >=20 > > Actually I'd rephrase that. If I understand correctly, because we use > > register calling conventions on architectures where sizeof(int) !=3D > > sizeof(long), this mess is working correctly now. Remember that syscalls > > are defined to take int, but prototypes say unsigned long. > It needs some untangling. >=20 > The ABI exported by libc is what I care about when referring to the ABI. > And this is the ABI which is not broken due to the reason I stated above. Right, but what I was trying to say is that if we had architecture where sizeof(int) !=3D sizeof(long) and where we don't use register calling conventions chflags(2) and fchflags(2) will never work in the first place. So one might say it is a lucky coincidence. Am I correct? Without committing my patch if we ever add such an architecture chflags(2) and fchflags(2) will not work there properly (maybe depending also on the byte order). > > I know it can break API in some rare cases like in chflags(1), but it > > results in compilation error (at least with the compilation flags we > > use), so can be easly spotted and fixed, hopefully: > >=20 > > /usr/home/pjd/p4/capkern/bin/chflags/chflags.c: In function 'main': > > /usr/home/pjd/p4/capkern/bin/chflags/chflags.c:120: warning: assignment= from incompatible pointer type > >=20 >=20 > Project aims to maintain better compatibility then to claim that > the changes could be 'spotted'. Should I read this as you being against the proposed change? --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl --yZnyZsPjQYjG7xG7 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iEYEARECAAYFAlFF7UUACgkQForvXbEpPzQEaQCbBg4qQaP7jO+C5tmlbMvdUfoO r1AAoMK4gXZLgFrotZJbZkueiRh/R5ZF =ia0+ -----END PGP SIGNATURE----- --yZnyZsPjQYjG7xG7--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130317162021.GG1364>