Skip site navigation (1)Skip section navigation (2)
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>