chflags(2)'s flags argument.

[Konstantin Belousov]

On Sun, Mar 17, 2013 at 05:46:33PM +0100, Pawel Jakub Dawidek wrote:
> On Sun, Mar 17, 2013 at 06:25:33PM +0200, Konstantin Belousov wrote:
> > 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:
> > > > > 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 ?
> 
> Well, the main reason behind this change is to make all chflags(2)
> syscalls consistent. I didn't consider changing syscall argument to
> unsigned long, but then I'd need to update lchflags(2) to take unsigned
> long to make it consistent with others, which has the exact same
> implications.
> 
> Now that I think about this, changing lchflags(2) argument to unsigned
> long might be better option, because:
> 
> - It would make all those syscalls consistent with strtofflags(3) and
>   fflagstostr(3).
> 
> - It would decrease the risk of possible breakage, as lchflags(2) is
>   rarely used.

I would say that API and ABI stability is more important then the
consistency. I think we are in the agreement of changing the kernel
interface for the chflags/fchflags to use long for flags.

For lchflags, my opinion is that the best would be not to change it.
-------------- 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/00a1c851/attachment.sig>