Date: Fri, 28 Jan 2000 17:02:19 -0500 (EST) From: Brian Fundakowski Feldman <green@FreeBSD.org> To: Bruce Evans <bde@FreeBSD.org> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libc/gen Makefile.inc Message-ID: <Pine.BSF.4.21.0001281637390.41451-100000@green.dyndns.org> In-Reply-To: <Pine.BSF.4.21.0001281625270.41316-100000@green.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 28 Jan 2000, Brian Fundakowski Feldman wrote:
> Am I the only one that's disturbed by the fact that this (nonstandard)
> function pair has such generic names? Already, it has broken world
> in two places. It's just not a good idea to have such generic functions
> in our headers (even if it's more okay for them to be in the libaries...)
>
> How about (for instance) strflags() for getflags() and strtoflags() for
> setflags()? The names right now are extremely ambigous, plus getflags()
> returns a pointer to a STATIC BUFFER, a very bad and inherently messy,
> thread-unsafe, etc. etc. thing. Plus, it's not even noted in the manpage.
Rationalization: (blatant POSIX emulation)
The strflags(3) function will follow the convention of strerror(3) and
return a string which expressed the (first argument) "u_int32_t flags"
as well as possible. If possible, a non-NULL character pointer would
be returned, which will have been allocated from malloc(3)d memory
and must be freed by the user. If there are no flags, the second
argument "const char *none" will be returned in a separate malloc(3)d
buffer, consistent with the return value behavior when "flags" contains
valid flags. If not possible to return a character pointer to malloc(3)d
memory containing comma-delimited string of characters representing the
"flags" argument (if malloc(3) fails), NULL will be returned and errno
will not be changed by strflags(3) itself.
The strtoflags(3) function will be based on standard convention of strtol(3):
in the form
int strtoflags(const char *flagstr, u_int32_t *posflags, u_int32_t *negflags,
char *const *endptr);
The return value of strtoflags(3) is an int expressing the number of
valid flags found in the string and processed. In all cases, "*posflags"
and "*negflags" will have a value upon return; if 0 is returned, since
no valid flags were processed, "*posflags" and "*negflags" will both be
0. The value of "*endptr" will be a valid position somewhere in the
"flagstr" string, where processing has stopped. Processing stops when
an invalid sequence of characters occurs in the flagstr, or the trailing
'\0' has been found. The string "flagstr" contains a comma-delimited
and optionally per-token hyphen-prefixed sequence of characters which
list any positive and negative flags that shall be converted. If
any of "posflags", "negflags", or "endptr" are NULL, that argument
shall not be set. The variable "*posflags" will contain the
non-hyphenated (positive) flags found in "flagstr", and "*negflags" will
contain the hyphen-prefixed (negative) flags). It is safe to assume
that the entirety of "flagstr" was processed correctly if "*endptr"
is equal to the string terminator ('\0'). The return value is not
an indication of success or failure, but an indication of the exact
number of tokens processed.
The "u_long" type is not used in strflags(3) nor in strtoflags(3). It
is a historical artifact that u_long is used in chflags(2), since in
stat(2), the "st_flags" stat structure member is a "u_int32_t". The
use of u_long to store flags in program code should be discouraged,
and the only case where u_long shall be necessary is when casting the
correctly u_int32_t type argument passed to chflags(2) or fchflags(2)
to the historical u_long it expects.
Or something.
>
> I really have huge beef with these functions... Am I really the only
> one, and everyone else likes them as they are?
>
--
Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! /
green@FreeBSD.org `------------------------------'
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?Pine.BSF.4.21.0001281637390.41451-100000>