Re: history and val-tags locks.

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Derek Price <derek@ximbiot.com> writes:

> Mark D. Baushke wrote:
> 
> > >Note that HistoryFile has an argument that would basically be run
> > >through strftime, to enable log rotation. Also see the HistorySearch,
> > >which would be used as a file glob to locate history files to be read
> > >for executions of the `cvs history' command.
> >
> >
> > Hmmm.... I do not like the BSD glob(3) function and its introduction in
> > CVS would not make sense given we already have POSIX fnmatch()
> > available... It would be better to specify looking for history files in
> > terms of fnmatch() semantics if that is what you intend to use to do the
> > resolution.
> 
> 
> Hey Mark,
> 
> Revisiting this since you brought it up, what don't you like about BSD
> glob(3)?

Not all systems provide a glob(3) function. Those that do provide a
glob(3) function provide many different variations of implementation
because glob existed a long time before the more general fnmatch was
written.

If you are only planning to use the subset of flags specified by POSIX.2
for glob, then you might be okay with a number of implementations.
However, my recollection is that there were a number of implementations
that did follow POSIX.2 closely.

I think something like these flags are 'standard':

  GLOB_APPEND, GLOB_DOOFS, GLOB_ERR, GLOB_MARK, GLOB_NOCHECK,
  GLOB_NOESCAPE, GLOB_NOSORT

while some implementations will also provide additional flags like
these that are found on OpenBSD and FreeBSD:

  GLOB_ALTDIRFUNC, GLOB_BRACE, GLOB_MAGCHAR, GLOB_NOMAGIC, GLOB_QUOTE,
  GLOB_TILDE, GLOB_LIMIT

while some GNU implementations add

  GLOB_ONLYDIR, GLOB_PERIOD

some glob() implementations provide those extensions, but have slightly
different semantics for them.

As for return values, I believe that GLOB_NOSPACE, GLOB_ABORTED and
GLOB_NOMATCH are standard, but some implementations may return
GLOB_NOSYS to indicate that the function is not supported.

In some implementations gl_pathc and gl_offs are not of type size_t as
mandated by POSIX.2, but are instead 'int' which was used in many *BSD
implementatiosn for years. This can cause interesting problems unless
care is taken with how you use glob().

> As near as I can tell, the POSIX.2 glob spec implies that it should
> basically be a wrapper for fnmatch() that opens intervening
> directories and performs intermediate matches. I ask because I am
> looking at reimplementing glob at the moment to allow the history
> search path to include multiple directories. For example, to match a
> path like:
> 
>     HistoryLogPath=/cvsroot/CVSROOT/history/%Y/%m/%d
>     HistorySearchPath=/cvsroot/CVSROOT/history/*/*/*
> 
> I need to open /cvsroot/CVSROOT/history, open each directory that
> matches *, open each directory in those directories that matches *, then
> open each file in those directories that matches *.
>
> IT seems to me that it would be much easier to import the glibc glob()
> function in GNULIB style, probably by actually first importing it into a
> GNULIB module, then use that if the local glob() functoin doesn't look
> useful.

I believe that most modern glob() implementations may indeed internally
be implemented using fnmatch(), but not all of them are. If you are
considering using an internal glob() instead of relying on a library
version from the system, then I don't have as much of a problem with it.

        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFCemka3x41pRYZE/gRAnCpAKCcCec+kR6cfo0aGPmk3G6iXnRi7gCgmFLA
Fry9D/09sR2uD7pb+mOLlsc=
=wiw0
-----END PGP SIGNATURE-----