chflags(2)'s flags argument.

Konstantin Belousov kostikbel at gmail.com
Sun Mar 17 16:25:38 UTC 2013


On Sun, Mar 17, 2013 at 05:20:22PM +0100, Pawel Jakub Dawidek wrote:
> 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 where
> > > > sizeof(int) != sizeof(long), uses register calling conventions.
> > > 
> > > Actually I'd rephrase that. If I understand correctly, because we use
> > > register calling conventions on architectures where sizeof(int) !=
> > > 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.
> > 
> > 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) != 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).
Yes, you are right.

> 
> > > 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:
> > > 
> > > /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
> > > 
> > 
> > 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?

No, I do not object. But, did you considered changing the syscall argument
to unsigned long instead ?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20130317/e90029c2/attachment.sig>


More information about the freebsd-arch mailing list