Date: Sun, 30 Apr 2000 19:22:52 +0100 From: Joe Karthauser <joe@pavilion.net> To: Bruce Evans <bde@FreeBSD.org> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/usr.bin/chflags chflags.c Message-ID: <20000430192252.A72668@pavilion.net> In-Reply-To: <200004041412.HAA01023@freefall.freebsd.org>; from bde@FreeBSD.org on Tue, Apr 04, 2000 at 07:12:36AM -0700 References: <200004041412.HAA01023@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 04, 2000 at 07:12:36AM -0700, Bruce Evans wrote:
> bde 2000/04/04 07:12:36 PDT
>
> Modified files:
> usr.bin/chflags chflags.c
> Log:
> Fixed prototype for setflags(). setflags() returns int, not u_long,
> and "extern" in function prototypes is a style bug. The type mismatch
> broke chflags(1) on i386's with 64-bit longs and may have broken it on
> alphas.
I want to revisit this issue now that the 4.0 release is well out
of the way. There was a lot of discussion that {g|s}etflags are
too generic names for these functions. Does anyone have a constructive
opinion of why I shouldn't rename them to {g|s}etfflags instead
and re-add them to libc? (Would that require a minor version bump
also?)
Joe
p.s. for those who don't know, these functions provide the ability
to translate between the u_long and string representions of chflags
style file flags (schg, nodump, uunlnk, etc).
They're used by 'ls -ol', chflags, install, find, mtree, amongst
others.
pps. they were named {g|s}setflags in keeping with the preexisting
{g|s}etmode function calls for manipulating file modes.
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000430192252.A72668>
