chflags(2)'s flags argument.

[Konstantin Belousov]

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:
> > On Sun, Mar 17, 2013 at 01:35:59AM +0100, Pawel Jakub Dawidek wrote:
> > > Hi.
> > > 
> > > Currently this is a bit messy: chflags(2) and fchflags(2) take 'flags'
> > > argument of type unsigned long and lchflags(2) takes the same argument
> > > of type int. At least this is what you can see in manual page and in
> > > prototypes of those functions in sys/stat.h.
> > > 
> > > However all of those syscalls are defined in syscalls.master to take the
> > > 'flags' argument of type int and this is what they use in kernel.
> > > 
> > > I'd like to proposed the following patch:
> > > 
> > > 	http://people.freebsd.org/~pjd/patches/chflags_int.patch
> > > 
> > > It changes type of the 'flags' argument from unsigned long to int where
> > > possible.
> > > 
> > > I believe this change won't break ABI, as the syscalls (apart from the
> > > prototypes) already expect int and I hope in doesn't break API in any
> > > really visible and destructive way. If you think otherwise, let me know.
> > 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.

The interface exported by the kernel for consumption of the libc syscall
wrappers is dufferent from the normal ABI on the architecture.

> 
> > Please note that API != ABI, and you found a case where the API
> > is broken indeed by your change.
> 
> 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'.
-------------- 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/05d5d4e0/attachment.sig>