Re: Unable to install CVS Server on Windows OS

2005-07-07 Thread Derek Price
[EMAIL PROTECTED] wrote:

So, My requirement is to install CVS Server one machine and CVS Client on
other machine for Windows OS Network which configuration is given below:-

Operating System: Microsoft Windows 2000 Professional (32-bit)
  


The GNU CVS project does not run as a server by default on Windows.  If
you must use a Windows CVS server and GNU CVS, you need to install the
Cygwin UNIX tools and most likely follow the Cygwin SSHD HOWTO to set up
a Windows OpenSSH Server, then follow the CVS instructions for setting
up a CVS server for SSH access in the CVS manual.

Alternately, you might try the CVSNT project.  They forked from GNU CVS
some time ago, but implement a CVS-like Server on Windows NT and its
derivatives (2000, XP, ...).

Derek




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: CVS problem with ssh

2005-07-07 Thread Derek Price
Richard M. Stallman wrote:

I wrote the code, checking the specs, and got it to compile correctly.
I don't have any easy way to test it--Emacs is not well suited to that
purpose.  Could you test it?
  


You neglected to include a wrapper for at least fflush().

  subst_fwrite (buffer, 1, out_count, stdout);

  return out_count;
  


You need to free BUFFER after writing it in all your *printf variants.

int
subst_fwrite (char *buffer, size_t size, size_t count, FILE *stream)
  


POSIX says fwrite accepts a BUFFER of type `const void *', not `char *'.

{
  int count_left = count;
  int desc = fileno (stream);

  while (1)
{
  int written;
  fd_set set;

  written = fwrite (buffer, size, count_left, stream);
  


According to POSIX, a short return from fwrite does not guarantee that a
portion of the following item was not written for items of SIZE  1, so
you need to convert BUFFER to COUNT * SIZE items of size 1 and loop
around writes of that to avoid writing data twice.  I'm not sure of the
most appropriate way to deal with overflow in COUNT * SIZE here.

  if (written == count_left)
   break;
  


If errno != EAGAIN here, the function should return the short item count
anyhow, without molesting errno.  For instance, POSIX states that fputc
(and thus fwrite) can return a short count with errno = ENOSPC for a
disk full error.  This wrapper should not continue to attempt writes in
such a case.

  /* Wait for space to be available.  */
  FD_ZERO (set);
  FD_SET (desc, set);
  select (desc + 1, NULL, set, NULL, NULL);

  buffer += written;
  count_left -= written;
}

  return count;
}
  


Regards,

Derek



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: CVS problem with ssh

2005-07-06 Thread Derek Price
Larry Jones wrote:

Richard M. Stallman writes:
  

If this is what it takes for you to fix the bug, I will do this.



Instead of spending large amounts of effort on half-assed workarounds,
why don't you make a concerted effort to explain the problem to the
OpenSSH developers and encourage them to fix the actual problem?


Though I agree that it appears, at the least, to be rude to change the
blocking status of a potentially shared file descriptor, I can also see
the argument from the SSH side that they wish to be able to expect the
behavior they request from said file descriptor.

Since there is no actual standard on the matter, a widely available set
of *_block stdio variants seems a reasonable way to satisfy everybody,
to me, and could be used in other tools which encounter similar problems.

  As far
as I can tell, no one has actually bothered to do that, which leads me
to believe that it's not really a serious problem for anyone.
  


This is possible, though, as I previously presented, I am fairly certain
the race condition still exists.  Even if no one is currently reporting
problems, it may crop up again as networks and platforms change, or
perhaps as the new code gets tested on new variants of the same.

Of course, you may be correct that it makes the most sense to wait until
we see more actual problem reports with the new code before spending
time fixing it, but then, as long as someone else submits a complete
patch (i.e. it isn't my time being spent writing it), I don't mind
applying it so much since I am fairly sure the problem is still present,
if currently dormant.

Cheers,

Derek



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: CVS problem with ssh

2005-07-06 Thread Derek Price
Richard M. Stallman wrote:

Not exactly.  If a solution like this were to go into GLIBC, then it
becomes much more likely that it can be shared with GNULIB, which means
that the infrastructure for it is already in CVS and that supporting it
won't rely exclusively on the extremely small and overworked CVS team. 

If this is what it takes for you to fix the bug, I will do this.
  


If you can get this done, great!  I think it is the most complete way to
fix this bug since it also handles future (currently unknown and
arguably broken) tools that also set shared file descriptors to a
non-blocking status, as well as making the
stdio-always-blocks-and-no-data-sent-will-be-lost functionality
available to other applications that may need it.

Regards,

Derek



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: CVS problem with ssh

2005-07-05 Thread Derek Price
Richard M. Stallman wrote:

Why not have glibc incorporate the moral equivalent of the unlocked
stdio routines (fwrite_unlocked, printf_unlocked, etc.), like
fwrite_block?

I am not sure what unlocked means, 


I'm referring to the non-thread-safe stdio variants exported by glibc
and supported as a GNULIB module.

but any solution like this would
only work on GNU.  It would be better to use an equally simple
approach that will work on other systems also: to define simple
functions inside CVS to replace fwrite, fprintf, etc.
  


Not exactly.  If a solution like this were to go into GLIBC, then it
becomes much more likely that it can be shared with GNULIB, which means
that the infrastructure for it is already in CVS and that supporting it
won't rely exclusively on the extremely small and overworked CVS team. 
Even if it isn't shared with GNULIB, we can probably rely on the GLIBC
folks to handle portability issues and import a file or two from GLIBC
directly into the CVS tree.

My suggestion is to write a function cvs_fprintf that uses vsnprintf
and alloca so as to generate the entire message, and then calls fwrite
in a suitable loop with select to output the message.  That should be
simple enough.  How about it?

I will write the function for you if you don't want to write it.
It would give me an opportunity to restudy how varargs works.
  


Again, I am less afraid of writing this than maintaining it, though I
feel I have the time to do neither just now.  The whole of stdio would
need replacement functions in CVS for this to work consistently: fwrite,
fflush, fprintf, printf, etc. - not just fwrite and not just fprintf. 
If anyone were to contribute such a complete patch, I would consider it
more seriously, still subject, of course, to further comment from the
other CVS developers.

To summarize, if such a patch were accepted into GNULIB, I would have no
problem importing the module into CVS.  Only accepted into GLIBC, I
would have to think about it some more and examine how easy it would be
to make the wrappers stand-alone.  Applied only to CVS, I remain
reluctant to accept the probable maintenance cost but may consider a
complete patch, pending further comment from the other CVS developers
and the results of tests on diverse platforms.

Regards,

Derek



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: CVS problem with ssh

2005-06-29 Thread Derek Price
Why not have glibc incorporate the moral equivalent of the unlocked
stdio routines (fwrite_unlocked, printf_unlocked, etc.), like
fwrite_block?  Similarly for printf_block, fprintf_block, etc.  Most of
the stdio code would not need to be reimplemented since it is already
present in glibc and applications which wanted to rely on the blocking
behavior of stdout and stderr could use these routines instead of the
usual stdio?  In fact then they (and CVS) could probably get it down to
some #defines in a header without changing the existing stdio calls.

Regards,

Derek



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: Terminated with fatal signal 11

2005-06-28 Thread Derek Price
More modern systems sometimes leave a file named core.PID, where PID is
a number.  There may be other variations.  I usually search for
`*core*'.  Some systems need the command `ulimit -c unlimited' run
before the program which dumps core, though probably the default may be
changed to unlimited via some system pref parameter somewhere.

A CVS server would most likely be leaving the cores under a directory
under /tmp named `cvs-servXX', where XX is a random combination
of letters and numbers.  Normally CVS will remove the server tmp
directory, but it isn't supposed to after a core dump.

I can't do a whole lot without a core dump.  If none of the above work
for you, it is also possible to set CVS_SERVER_SLEEP to some number of
seconds on the server (most likely in inetd, xinetd, or a cvs server
wrapper script), then quickly connect to the server process using a
debugger while it sleeps, after starting it via Tortoise or whatever.

Good luck,

Derek


Gary Wake wrote:

 Love to but we don't have a 'core' file anywhere on the system

 Derek Price wrote:

 Gary Wake wrote:

  

 Terminated with fatal signal 11

 Error, CVS operation failed
   



 Can you find the server core dump and get us a stack trace from the
 debugger?

 Regards,

 Derek



 ___
 Bug-cvs mailing list
 Bug-cvs@gnu.org
 http://lists.gnu.org/mailman/listinfo/bug-cvs
  


 ---
 This email message and any attachment(s) is intended only for the
 person(s) or entity(entities) to whom it is addressed. The information
 it contains may be classified as IN CONFIDENCE and may be
 legally privileged. If you are not the intended recipient any use,
 disclosure or copying of the message or attachment(s) is strictly
 prohibited. If you have received this message in error please notify
 us immediately and destroy it and any attachment(s).
 Thank you. The Ministry of Social Development accepts no
 responsibility for changes made to this message or to any
 attachment(s) after transmission from the Ministry.
 ---





___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: CVS problem with ssh

2005-06-28 Thread Derek Price
Richard M. Stallman wrote:

  Currently CVS does a single select on the stdout fileno
before dumping as much data as it last received from the network to
stdout via fwrite.  There is *no looping or checking for EAGAIN
returns*, which I believe you advocated but, I am informed by Larry
Jones and Paul Eggert, would likely be unportable to non-GNU systems.

What do you mean by unportable?  As far as I can see, that change
could not do any harm on any system.  If it fixes the problem on GNU
systems, that's an important improvement, so why not do it?
  


It might not do any additional harm.  I won't claim to understand the
issue completely, but I was told that there might be data loss since
EAGAIN may not mean what it is supposed to on some systems.  I suppose
that we would be no worse off than we are now.

Paul Eggert was also claiming that a successful select on STDOUT_FILENO
wouldn't necessarily imply a successful write of even a single byte to
the stdout stream (in a loop context, so I don't believe he was
referring to any potential race condition), though I know of no set of
conditions where that would happen.

It sounds like you can rely on stdio on a GNU system.  


In the loop we are avoiding, perhaps.  In its current context, obviously
not, which is where I wanted to be able to rely on it.

If other
systems don't handle this reliably, maybe that is their fault.  You
could report bugs in fwrite if they fail to write the data and don't
return EAGAIN.
  


Again, we could install loops around fwrite in handle_m, handle_e,
handle_mbinary, and handle_mt and transfer most of the data coming
across from the server correctly to stdout/stderr, but this still
wouldn't handle other client output.  That would require a complete
stdio wrapper, replacing all our calls to printf, fprintf, fflush, etc. 
This would be serious work and not easily maintainable.  It really seems
the much simpler solution for ssh to play nice with the standard file
descriptors.

Regards,

Derek



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: Terminated with fatal signal 11

2005-06-27 Thread Derek Price
Gary Wake wrote:

 Terminated with fatal signal 11

 Error, CVS operation failed


Can you find the server core dump and get us a stack trace from the
debugger?

Regards,

Derek



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: CVS problem with ssh

2005-06-27 Thread Derek Price
Richard M. Stallman wrote:

The code currently works by making the assumption that network reads
will always return chunks of data small enough to be written to stdout
in a single call to fwrite after a single select on fileno (stdout).

What would make some data too long?  The nmemb argument of fwrite is a
size_t, and unless fwrite has a bug, it should handle whatever amount
of data you specify.

I don't see why a large amount of data would cause a failure.
Previous messages claimed that it could, but I think I've refuted that
claim.  Is there a flaw in the argument I gave?
  


I've simply been describing what I believe is the current race
condition.  Perhaps you misunderstood the status of the current
workaround in CVS (you may be thinking fix, but I am attempting to
refute that)?  Currently CVS does a single select on the stdout fileno
before dumping as much data as it last received from the network to
stdout via fwrite.  There is *no looping or checking for EAGAIN
returns*, which I believe you advocated but, I am informed by Larry
Jones and Paul Eggert, would likely be unportable to non-GNU systems.

Currently, this workaround appears to prevent the original problem, but
I think it is working because the select usually implies there is more
room for writing to stdout than we have data only because reading from
the network is slower than writing to disk.  The whole point of this
discussion, I thought, was that we could rely on an EAGAIN return from
GNU fwrite and could retry the write with the remaining data when there
was no room?

Since there is no looping going on and any single fwrite of an arbitrary
amount of data  1 byte should be able to sometimes trigger the EAGAIN
even after a select, I suspect the race condition described above
exists.  On a fast network with a slow disk, the problem should still be
reproducible.  Perhaps this could be verified by piping the CVS stdout 
stderr to netcat across an even slower network or somesuch.  I don't
know and I don't really have the facilities here to test it.


Though it was not what I was arguing in the above thread - I only meant
to point out that, as I understand the problem, the current situation is
not a true fix, I will reiterate that I still agree with Larry and am
loathe to reimplement stdio in CVS.  I would much prefer to be able to
rely on stdio for a situation like this.

I most certainly don't have the time to reimplement it myself at the
moment and even were a complete patch submitted I would still be
reluctant to accept it due to potential maintenance hassles.  I
understand a similar stdio reimplementation happened in Emacs in the
past and the team eventually gave up on it due to unmaintainability.

Cheers,

Derek



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: CVS problem with ssh

2005-06-23 Thread Derek Price
Richard M. Stallman wrote:

It's possible that this fix is a full and correct solution.  If the
descriptor has room for at least one byte, `write' won't return
EAGAIN; it will write at least one byte.  It may write less than the
whole buffer that was specified.  If the stdio code handles that case
correctly, the results should be correct.


Are you telling me that the glibc implementation of streams provides a
buffer with infinite space?  POSIX 1003.1 says fwrite() returns errors
as fputc().  POSIX 1003.1 says about fputc:

The fputc() function shall fail if either the STREAM is unbuffered
or the STREAM's buffer needs to be flushed, and:

[EAGAIN]

The O_NONBLOCK flag is set for the file descriptor underlying
/stream/ and the thread would be delayed in the write operation.



Roland, does GNU libc
handle that case correctly?  I expect it does, since that case can
arise in many situations.  If it were not handled correctly, we would
hear lots of screaming--I think.
  


I bumped CVS's test for this error up to dumping about 110MB of data to
stdout, and it still passes, but not for the reason you think, I think. 
I'm watching the file fill more slowly than it should if limited only by
the disk, and the data is coming from both the network and diff.  I'm
guessing that the file writes are simply usually faster than the reads
of data produced at a high CPU cost and transferred across a network. 
Regardless of the fact that this will usually hold true, the algorithm
still contains a race condition, might not hold true across diverse
platforms, and is not a true fix.

Regards,

Derek



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: CVS problem with ssh

2005-06-22 Thread Derek Price
Richard M. Stallman wrote:

Couldn't this be fixed easily by changing cvs to handle EAGAIN
in a simple way when outputting to stdout?  If it just sleeps for a second
and tries again, that ought to fix the problem.
  


Mark Baushke installed Frank Hemer's partial work-around for this
problem some time ago.  This should have been released with CVS 1.11.18
 1.12.10:

2004-08-17  Mark D. Baushke  [EMAIL PROTECTED]

* sanity.sh (sshstdio): Fix comment typo plus gratuitous
reformatting.

* client.c (handle_m): Workaround to deal with stdio getting put
into non-blocking via redirection of stderr and interaction with
ssh on some platforms. On those boxes, stdio can put stdout
unexpectedly into non-blocking mode which may lead to fwrite() or
fflush() failing with EAGAIN, but cvs not checking for the error.
(Patch suggested by Frank Hemer [EMAIL PROTECTED].)

* client.c (handle_e): Similar fix for stderr.
* sanity.sh (sshstdio): New test for non-blocking stdio via ssh.


This fix selects on the file descriptor associated with the stream
before writing to the stream via stdio, which is probably wrong on
several levels, as Paul Eggert pointed out in this discussion:
http://lists.gnu.org/archive/html/bug-gnulib/2004-09/msg00010.html. 
This is also definitely only a workaround and I suspect won't work for
very large file sizes since the select only guarantees that the
descriptor is ready for a single byte, not an arbitrary amount of data,
though it appears to handle the original test case.

I agree with Larry Jones, that the problem is deeper.  It seems to me
that any program writing to stderr or stdout via stdio should have the
reasonable expectation that the stream will remain blocking, or perhaps
remain non-blocking, as the case may be.

If we have to fix anything on the CVS side, I think the only complete
fix (read working in all cases) would be to replace all our stdio calls
with our own buffering writes that handled things regardless of EAGAIN. 
Much of the code that would be necessary is already in CVS 1.12.x - it's
used for the network buffers on the server side, but nobody has
submitted the patch to apply it everywhere and, as I said, I agree now
that this change would be wrong so I have not written it myself.  The
same would need to be done in any program piping output through ssh,
some of which don't have CVS's infrastructure, and this seems unreasonable.

Regards,

Derek



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: Core dump during CVS Commit

2005-06-16 Thread Derek Price
Smruti wrote:

Hi Dreek,

Thanks for the mail.
Could you update me how shall I take stack trace from core?
  


Using the GNU debugger (gdb), the command is `bt' (for backtrace). 
Thus, assuming that you were using /usr/bin/cvs and that your core dump
created a file named core.1234 (where 1234 couild be any process id):

$ gdb /usr/bin/cvs core.1234
...assorted gdb bootup output...
(gdb) bt
...SEND THIS OUTPUT...
(gdb)


The commands may be slightly different if you need to use the Solaris
debugger.

The core dump file should have been created in whatever directory you
ran the offending CVS command from.  If it wasn't, you might have to run
the command `ulimit -c unlimited' to enable core dumps.  At least,
that's the command on Linux - I'm not sure that is the same on Solaris
either.

Regards,

Derek



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: OpenBSD 3.6 sparc64 Build Failure on TRUNK

2005-06-15 Thread Derek Price
Alexander Taler wrote:

 $ make
 make  all-recursive
 Making all in lib
 cp ./alloca_.h alloca.h-t
 mv alloca.h-t alloca.h
 /bin/sh ../build-aux/ylwrap getdate.y y.tab.c getdate.c y.tab.h
 getdate.h y.output getdate.output -- /bin/sh
 /home/dissent/prj/libcvs/var/ccvs-1.12/build-aux/missing --run bison -y
 /home/dissent/prj/libcvs/var/ccvs-1.12/lib/getdate.y:202:
 unrecognized: %parse-param
 /home/dissent/prj/libcvs/var/ccvs-1.12/lib/getdate.y:202:Skipping
 to next %
 /home/dissent/prj/libcvs/var/ccvs-1.12/lib/getdate.y:203:
 unrecognized: %lex-param
 /home/dissent/prj/libcvs/var/ccvs-1.12/lib/getdate.y:203:Skipping
 to next %
 *** Error code 1


There are a few issues here:

   1. getdate.y from GNULIB requires at least Bison 1.875.
   2. getdate.y shouldn't be recompiled unless it has changed, but
  sometimes the timestamps can get munged when checking out of CVS.
   3. When either of the above two problems are not avoided, the
  build-aux/missing script is supposed to just update the
  timestamps, print a warning message, and exit with a success
  code.  This may not happen if your lib/getdate.c file is actually
  missing, for instance if you ran a `make maintainerclean'.


If your `missing' script is failing for any reason other than a bad
bison AND a missing lib/getdate.c, then I would like to get to the
bottom of it.  Otherwise, your solution should be to update to a more
recent Bison (which we assume for anyone willing to run `make
maintainerclean'), or pull the current lib/getdate.c from CVS and avoid
the rebuild.

I have documented the Bison 1.875 requirement in HACKING.

Regards,

Derek



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: OpenBSD 3.6 sparc64 Build Failure on TRUNK

2005-06-15 Thread Derek Price
Alexander Taler wrote:

 case $1 in
 --run)
   # Try to run requested program, and just exit if it succeeds.
   run=
   shift
   $@  exit 0

 Where do you suppose that check should be?


Actually, `missing' only `exit 0's when the program exited with a
success code.  Otherwise it will fall through and perform various
actions depending on the argument to --run.

One of the things it does is verify that the requested executable exists
and that it is a GNU application.  This is what caught us - the script
was assuming that any GNU program is good and therefore that its failure
meant a real failure.  I added a new bison wrapper based on missing to
handle the version check.  Let me know if it doesn't work for you.

This problem should go away when we start using Automake 1.10 since it
won't allow Yacc targets to be built without the
--enable-maintainer-mode argument to configure.

Regards,

Derek



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: Conditional/Comment Error? lib/canonicalize.c

2005-06-14 Thread Derek Price
Conrad T. Pino wrote:

Can someone suggest which one of the following 2 changes (if any)
is the best one to commit?
  


Neither.  Apparently we have been breaking the GNU commenting
conventions for #ifdefs and GNULIB has it right:
http://www.gnu.org/prep/standards/standards.html#Comments, though they
left off the comment on the #else, if you would like to submit a patch
to bug-gnulib.

Regards,

Derek



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: CVS update: /ccvs/lib/

2005-06-14 Thread Derek Price
Conrad T. Pino wrote:

I added lib/lstat.c because linker didn't have definition for external
symbol _rpl_lstat and a grep found only 1 definition.  I had seen this
commit to windows-NT/config.h files:
https://ccvs.cvshome.org/servlets/ReadMsg?list=cvsmsgNo=3881
which I assume meant the reference to rpl_lstat was intentional.

I've always assumed commits to windows-NT config files reflected a well
considered plan so I often don't examine the committed changes other than
noting the file names.  I now see room for process improvement.  What are
your thoughts?
  


Well-considered, perhaps, but without a test platform it can be
challenging to verify that I did not make any mistakes.  In this case, I
thought I knew what I was doing and was just trying to save you some
work.  Apparently I neglected to consider that the #include lstat.h
was going to override my windows-NT/config.h changes in this case.

Sounds like the `#define lstat stat' can be removed from
windows-NT/config.h.in.footer in conjunction with the other changes we
discussed.

Please feel free to review any committed changes that you see fit to and
discuss them on bug-cvs.  :)

Regards,

Derek



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: CVS update: /ccvs/lib/

2005-06-13 Thread Derek Price
[EMAIL PROTECTED] wrote:

Log:
 * libcvs.dsp: Add files filenamecat.h and lstat.c to project.
  


Your change to filenamecat.h is correct - that's a rename of the
path-concat module from GNULIB, but I don't think you want lib/lstat.h 
lib/lstat.c on Windows.  lib/lstat.c contains a wrapper for lstat that
works around a very specifc lstat bug on some UNIX systems  lib/lstat.h
is going to override the definition of lstat from windows/config.h. 
Perhaps leaving out lib/lstat.c  lib/lstat.h and adding a
windows-NT/lstat.h like the following would be a more complete solution?

#ifndef LSTAT_H
# define LSTAT_H
# include unistd.h
# define lstat stat
#endif


I think window-NT/filesubr.h will need to include lstat.h after this
change as well.

By the way, while I am thinking about it, re our earlier discussions of
Cygwin and Windows replacement functions, Cygwin settled on using .lnk
files (Windows shortcuts) as the Windows representation of UNIX
symlinks.  It might make sense for CVS on Windows to use stat  lstat
wrappers that behaved similarly.  i.e. stat would follow .lnk references
until they resolved to something real or failed to (check POSIX but I
think this would mean an error) and an lstat that returned the actual
stat information from the .lnk file.  Of course, this would probably
also require wrappers for open and fopen that also followed
shortcuts as if they were symlinks.

At the very least, this would make it much easier for an admin to set up
symlinks in a Windows CVS repository.  They could just create shortcuts
from Windows Explorer.

Regards,

Derek



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: patch: implement %{t} for loginfo

2005-06-10 Thread Derek Price
Todd Vierling wrote:

NetBSD, among other projects, has used a change similar to this for many
years, to allow the tag name to be passed to loginfo scripts.  This allows
the popular log_accum script to supply the tag name in the Subject line.

Below is a diff against 1.12.12, and is really very trivial; I wonder if
it's just oversight that prevented this from being contributed sooner.  It
would be really nice if this didn't require external maintenance anymore.  :)
  


It was an oversight, basically.  I've committed your change plus a
parallel change in taginfo, except I used a capital `T' rather than
`t'.  `t' was already in use in the taginfo file as the tag name being
added/moved/deleted.

I also added documentation and tests.

Regards,

Derek



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: GZip level restriction

2005-06-03 Thread Derek Price
Derek Price wrote:

Derek Price wrote:
  

On the other hand, it would be nice if there were a way to specify a
default compression level or range of levels (both for the server and
the client) that could be used in the absence of any explicit
specification by the user. Of course, reconciling conflicting defaults
could be an interesting challenge.
  

To some extent this would be happening with my proposed change.  A
client that had requested -z9 on a fast machine would always compress
their data at level 9, but the server would only compress its data at
whatever maximum level had been set, limiting the load on its CPU.

Similarly for a client -z3 and a server with a min level of 9.  The
client would compress at 3 and the server at 9, saving most the
bandwidth and not bombing the client CPU.




Hey Larry,

Can I assume that no comment for almost two weeks means you have no
further objections to this patch going into feature?
  


Since I haven't heard any further objections to this change in several
days, I have committed it to feature.

Cheers,

Derek



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: CVS update: /ccvs/windows-NT/

2005-06-01 Thread Derek Price
Conrad T. Pino wrote:

The timer code in lib/nanosleep.c looks very good but I'm uncomfortable
making a commitment to making the change because:

* I don't understand UNIX style signal behavior well.
  


Basically, signals normally cause a process to exit unless a handler is
installed.

* Millisecond resolution delays without surrendering the time slice are
  possible by creating an unsignaled Event then waiting for that Event
  with a time out value.  This feature requires hardware support in CPU
  otherwise behavior reverts to the PC BIOS rate.

I'll work up a test program to measure select time out granularity in
the next few days.

I'll support you to the best I can should you choose to make the change.
  


This was just a suggestion as I thought it might simplify things.  You
can make the call.

I would argue that the signal handling is no argument since
windows-NT/run.c is making calls to signal, I would assume that the API
is likely similar to UNIX and whoever wrote lib/nanosleep.c knew what
they were doing until we discover problems.

Your timer granularity argument sounds reasonable, however.  If you need
to reimplement usleep anyhow, then you can't really compuile
lib/nanosleep.c on Windows without rewriting it anyhow.  I found this
thread where we discussed this previously:
http://lists.gnu.org/archive/html/bug-cvs/2004-05/msg00161.html.  Jim
Hyslop suggests that NTP (www.ntp.org) uses QueryPerformanceCounter()
and QueryPerformanceFrequency() to hack around the problem with about a
300ns granularity.

Can you share some ideas on what I need to do to get sanity.sh to run
on Windows 2000?
  


I have had it up and running before using a version of CVS built with
cygwin (http://cygwin.com), using the bash and other tools from cygwin. 
Most of the hacks I made to get that to work should still be in sanity.sh.

IIRC, however, testing an executable built with MSVC is a different
story because it can sometimes use \ and sometimes / as a file
separator.  No one has ever installed the machinery in sanity.sh to
handle that.  It might be possible to make a small change in
dotest_internal() that seds the program output and replaces all
backslashes with forward slashes before the text goes to expr for the
comparison.  That is where I think I would start trying to get this running.

Does the MKS Tool Kit sh implementation help any?

Is Windows 2000 bash combined with MKS Took Kit a better start?
  


Like I said, I started with Cygwin and the Cygwin bash.  Don't know what
the differences are between MKS and Cygwin.  sanity.sh requires a
working /bin/sh and a few standards compatible tools: expr, id, tr, and
sed are the most sensitive tools, I believe.  If you are attached to MKS
but one of those tools is broken, you might get sanity.sh running by
building and installing the GNU versions there.  The TESTS file
describes where to get them.

* filesubr.c: Modify get_homedir to use woe32_home_dir.
* pwd.c: Modify getpwuid to use woe32_home_dir  woe32_shell.
Append USERNAME to login_strings array.
  

Again, unless USERNAME is a read-only env var, if there is a Windows API
for retrieving these sorts of values, it should probably be used in the
POSIX replacements in favor of writable environment variables.



I agree in principle but several things indicate this is a non-issue:

* Microsoft's workstation security practices commonly grant the CVS user
  root equivalent privilege on the executing platform.  Why infringe on
  the user's right to destroy local resources since they're effectively
  all owned by the workstation user?
  


One more time:

   1. I think a POSIX-compliant getpwuid function, or as near as we can
  get on Windows, should not use environment variables if at all
  possible if you wish to implement it in such a way that it
  complies as closely as possible with the POSIX spec so that it may
  be shared with other projects.
   2. I think there is no harm in the CVS get_homedir function using env
  variables.  CVS does that on UNIX on exactly the principle you
  state.  If the user set it then we will presume they knew what
  they were doing and let system security measures take care of
  things if the user is asking us to do something we shouldn't.


* The better security route indicates we should remove login_strings
  altogether since the addition/removal of a single variable doesn't
  close the security vulnerability.
  


This is exactly what I was advocating.  To meet the POSIX specs, these
functions should try to obtain the login name securely.  The POSIX
argument stands regardless, but a get_homedir-like wrapper would be
wrong here for CVS as well.  This value is entered in the repository as
the author of a commit and I would rather know that the user had to have
a password for the userid being used.  At the least, it shouldn't be so
easy to forge the author of a commit by setting an env var.

Regards,

Derek




Re: windows-NT/pwd.c - struct passwd - Home Directory

2005-06-01 Thread Derek Price
Conrad T. Pino wrote:

My ideas for the API are UNIX/POSIX specifications are non-negotiable and
internal APIs below that are discardable upon discovery of the better way.
  


Basically.

In theory, you could take up desired changes with the POSIX spec with
IEEE.  Of course, if you did get some changes through, it would likely
be years before we could support them fully in CVS and GNULIB - that
doesn't happen until it is determined that hosts which require older
(i.e. POSIX2) specifications are no longer reasonable porting targets. 
As an example, GNULIB and CVS both still support ANSI C89
specifications.  I would not hazard a guess as to when C99 will be
judged a reasonable assumption.  GNULIB just finally dropped support for
SunOS 4.1.4, about a year and a half after Sun did.  Of course, the
official policy of GNULIB is to drop support when the provider of the OS
does, but it isn't always noticed right away.

Also, for a traget like Windows, compliance may be as close as
possible to the POSIX spec.  Sometimes a POSIX spec will make reference
to other POSIX specs, and if, for instance, the getpwuid spec referenced
the /etc/passwd file directly, we might only be able to approximate the
desired result.  What you and I are debating, I think, is what is
morally closest to the POSIX spec on Windows.


As an aside, it might sometimes be interesting to look at what Cygwin
did in some of these cases.  Their code is GPL'd.  Of course, I've
looked at it before, and it tends to be much too involved to import into
CVS easily - they have their own userid system overlaid on top of
Windows, for instance, which would likely make getpwuid a challenge to
import, and similar things happen with their file descriptor
implementation, but something like their implementation of usleep() or
nanosleep() might not have so many internal dependencies.

Cheers,

Derek



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: CVS update: /ccvs/windows-NT/sys/

2005-06-01 Thread Derek Price
Conrad T. Pino wrote:

Hi Derek,

  

From: Derek Price

I think renaming this file sys_types.h, starting it with `#include
sys/types.h', then defining what else you need would be an easier
interface to maintain.



Are you implying changing all #include sys/types.h in CVS? I assume no.
  


Well, it may be an option if necessary, similar things have been
proposed for GNULIB modules, but none has turned out to be necessary yet.

In this case I was thinking that the Windows config.h.in.footer could
#include sys_types.h and get the effect you are looking for.

I intend the windows-NT version be used in all locations cited at the
end of this message.

My first try was your suggestion with the current name only to discover VC6
reopens the windows-NT file because windows-NT is in the include path.
  


Which is why I proposed renaming the Windows include to sys_types.h. 
I also dislike polluting the windows-NT source directory space with a
directory structure mimicing a standard C89/POSIX include structure with
no differentiation from the other source files if you can avoid it.  If
you must, I might prefer moving your sys directory under a
windows-NT/include directory and making the other changes you needed to
to accomodate that, but I still prefer avoiding the sys directory
entirely in favor of the sys_types.h file.

Regards,

Derek



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [bug-gnulib] New GNULIB glob module?

2005-06-01 Thread Derek Price
Paul Eggert wrote:

Derek Price [EMAIL PROTECTED] writes:

  

   1. Corrects an incorrect check for a successful return from
  getlogin_r to assume only 0 means success, per the POSIX2 spec:
  
 http://www.opengroup.org/onlinepubs/009695399/functions/getlogin_r.html.
   2. Moves the check for GLOB_MARK directory status (and the append of
  `/') into glob_in_dir, where it is more efficient than performing
  a second pass and sometimes calling stat a second time on each
  file or directory.  All calls to stat are avoided when
  dirent-d_type is available.  No call to realloc of the directory
  name is ever necessary since room for the slash can be allocated
  in the first pass.



These changes sound reasonable, though we should submit them as
separate patches.
  


The attached  glibc-understand-getlogin_r.diff may come off as a little
fuzzy, but it should work for (1).  I've also reattached the patch for 2
 3 minus the above chunk, as glibc-glob-list-links2.diff.

Is (2) independent of (3)?  (Please see below for why this is important.)
  


(2) could be separated with a little more work, but lets finish the
discussion below before I provide a second patch.

   3. Ignores broken links only when GLOB_ONLYDIR is set.  With glibc
  versions 2.3.3 through 2.3.5, the following in an empty directory
  would return nothing:

  ln -s doesnt-exist linkname
  glob (*, ...)

  This fix syncs with the comments in the file, syncs with the
  POSIX2 spec, restores the pre-glibc-2.3.3 behavior, and simply
  makes more sense - why should `ls *' fail to list broken links?



This change sounds controversial to me.  glibc 2.3.5 behaves similarly
  


It may be.  It looks like the change was intentional
(http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sysdeps/generic/glob.c?rev=1.52content-type=text/x-cvsweb-markupcvsroot=glibc),
but I still disagree.

to Solaris 8 and to Solaris 10 -- I just checked, with the following
program and with the working directory containing only a dangling
symlink:

  #include glob.h
  #include stdio.h

  int
  main (void)
  {
glob_t g;
int r = glob (*, 0, NULL, g);
int i;

if (r != 0)
  {
fprintf (stderr, glob failed (%s)\n,
 r == GLOB_NOMATCH ? GLOB_NOMATCH
 : r == GLOB_NOSPACE ? GLOB_NOSPACE
 : other glob failure);
return 1;
  }

for (i = 0; i  g.gl_pathc; i++)
  puts (g.gl_pathv[i]);
return 0;
  }

Solaris 8 and 10 both report glob failed (GLOB_NOMATCH).

Let's separate (3) into a separate patch and think about it more
carefully before submitting it.
  


This would involve creating at least one new function for (2) which
would just need to be removed again for (3), and the POSIX2 glob spec
states that glob returns GLOB_NOMATCH only when, the pattern does not
match any existing pathname, and GLOB_NOCHECK was not set in flags. 
(http://www.opengroup.org/onlinepubs/009695399/functions/glob.html)

Nowhere does the POSIX2 glob spec specify that a broken symlink should
not be considered an existing pathname.  After all, the link exists,
only its target does not.  Interpreted in this way, glob cannot be used
by a program which, for instance, wished to verify that all links
matching a pattern had valid targets since the broken links would not be
returned by glob.

If glob is only going to consider a link as if it is its target, then
what about the case where a matching link points to a file in the same
directory that also matches the pattern?  Should glob only return one or
the other?

Perhaps a GNU extension similar to GLOB_ONLYDIR is in order
(GLOB_VERIFY_SYMLINKS?), but I do not think glob should be making these
value judgements when the user did not request it.  It certainly does
not appear to be implied by the POSIX spec as I read it.

Have you investigated with FreeBSD glob does?  


No, but I ran your test program on NetBSD 1.6.1 and it does return the
broken symlink.

I copied and pasted most of my above commentary on why this should be
considered a bug into
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=126460, where I
found the discussion that apparently caused the original bug fix that
broke this.

Cheers,

Derek

--- ../glob-glibc2gnulib/lib/glob.c 2005-05-31 18:12:01.0 -0400
+++ lib/glob.c  2005-05-27 13:52:28.0 -0400
@@ -538,7 +539,7 @@ glob (const char *pattern, int flags,
buflen = 20;
  name = __alloca (buflen);
 
- success = getlogin_r (name, buflen) = 0;
+ success = getlogin_r (name, buflen) == 0;
  if (success)
{
  struct passwd *p;
--- ../glob-glibc2gnulib/lib/glob.c 2005-05-31 18:12:01.0 -0400
+++ lib/glob.c  2005-05-27 13:52:28.0 -0400
@@ -175,6 +175,7 @@
 # define __glob_pattern_p  glob_pattern_p
 #endif /* _LIBC */
 
+#include stdbool.h
 #include fnmatch.h

Re: GZip level restriction

2005-06-01 Thread Derek Price
Derek Price wrote:

 On the other hand, it would be nice if there were a way to specify a
 default compression level or range of levels (both for the server and
 the client) that could be used in the absence of any explicit
 specification by the user. Of course, reconciling conflicting defaults
 could be an interesting challenge.

 To some extent this would be happening with my proposed change.  A
 client that had requested -z9 on a fast machine would always compress
 their data at level 9, but the server would only compress its data at
 whatever maximum level had been set, limiting the load on its CPU.

 Similarly for a client -z3 and a server with a min level of 9.  The
 client would compress at 3 and the server at 9, saving most the
 bandwidth and not bombing the client CPU.


Hey Larry,

Can I assume that no comment for almost two weeks means you have no
further objections to this patch going into feature?

Cheers,

Derek




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: windows-NT/pwd.c - struct passwd - Home Directory

2005-05-31 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Conrad T. Pino wrote:

What I don't understand is why . is a reasonable home directory according
to the getpwuid implementation:

 static char *home_dir = .; /* we feel (no|every)where at home */


I don't agree that it is.  I think it was a poor, arbitrary
implementation decision at some point in the past before Windows had the
concept of a home dir, which did not show up until NT, I believe.

My thought was along the lines of:

 struct passwd *
 getpwuid (int uid)
 {
 pw.pw_name = getlogin ();
- pw.pw_dir = home_dir;
+ pw.pw_dir = get_homedir ();
 pw.pw_shell = login_shell;
 pw.pw_uid = 0;

 return pw;
 }


If the getpwuid function in windows-NT/pwd.c worked, then the
get_homedir in src/filesubr.c might be moved into src/subr.c and shared
with the Windows implementation, or so I was thinking.

Regardless, I do think this basic idea is correct.  My reconsideration
is that perhaps all user-settable environment variable references,
should be in get_homedir, and getpwuid would need to return the secure
home directory, as it is defined to on UNIX, where it is often read from
the /etc/passwd file, for instance.  The closest thing might be the
value from the registry on Windows.  Windows must read this from
somewhere in order to set USERPROFILE, HOMEDRIVE, and HOMEPATH on boot. 
You need to read the Windows specifications and determine where these
values are coming from to implement this correctly.  Is there no
equivalent to this function on Windows, where the home dir value may
have come from a domain server or whatever?

The UNIX specification for getpwuid is here:
http://www.opengroup.org/onlinepubs/009695399/functions/getpwuid.html.

Another thought can take use one step closer to using src/filesubr.c
instead
of windows-NT/filesubr.c by defining wnt_homedir in woe32.c:


This would be fine if we decide the proper place for all env var lookups
is in get_homedir.

A grep of get_homedir usage (below) leads me to believe that whichever way
we choose, functions getpwuid and get_homedir should present a
consistent
view of where the home directory is on a given platform.


Once again, to summarize, if getpwuid is to be implemented,
functionality should be divided as follows:

getpwuid: to POSIX spec as much as possible, secure source if possible,
output not user settable
get_homedir: to CVS requirements, uses env vars, possibly set by user

You should be able to get POSIX specs for the other functions in
windows-NT/pwd.c from opengroup.org as well.  Try changing the
getpwuid in the URL above to other function names as needed.

:)

Regards,

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCnI8ILD1OTBfyMaQRArjFAKCEmq0ApQTuiZKSjEIAsR/q2D/DNQCfW6sq
hERtcrUGiZhhgTBwUBWNhKE=
=62BD
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: Feature Branch - windows-NT/pwd.h windows-NT/unistd.h

2005-05-31 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Conrad T. Pino wrote:

Hi Derek,

File windows-NT/pwd.h declares several functions that
are declared in unistd.h according to the NetBSD man
pages.

Since I created windows-NT/unistd.c do you object in
principle to migrations from pwd.c to unistd.c?

If you agree, I'll enumerate the functions to migrate
for review before actually doing so.


That's fine.  If the function has a counterpart in unistd.h on UNIX, I
likely won't have a problem with any such migration you propose.

Cheers,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCnI+kLD1OTBfyMaQRAjtUAJ9pdcUy4+wWBcQ3itMPrT61EUyraQCg10oF
idmDhjfxUlMKzCTHeOW/l4Q=
=5rNC
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: Windows 2000 - HOMEDRIVE,HOMEPATH vs. USERPROFILE

2005-05-31 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

It sounds to me like we probably want to ignore USERPROFILE, then, and
just use the home dir settings.  How does the home directory get set to
something other than undefined in your examples?  Is there an API to
read it from the system or must all applications rely on malleable
environment variables for this information?

Cheers,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCnK6RLD1OTBfyMaQRAnWqAKC/KHPySouyvYPIcS+eCfXAOnRXWgCfbjT0
whrOdCPGQpoGKGn1J85SME8=
=4gdk
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: CVS update: /ccvs/windows-NT/sys/

2005-05-31 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[EMAIL PROTECTED] wrote:

#ifdef _MSC_VER

#pragma once

/* Compatable with Visual C++ 6.0 - cl.exe 12.00 */
#if _MSC_VER != 1200
#pragma message ( Please email Microsoft's sys/types.h )
#pragma message ( file to [EMAIL PROTECTED] )
#endif /* _MSC_VER != 1200 */

/***/
/* Mimic what Micrsoft defines in their sys/types.h */


I think renaming this file sys_types.h, starting it with `#include
sys/types.h', then defining what else you need would be an easier
interface to maintain.

Regards,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCnLbULD1OTBfyMaQRArmUAKD8v6H424DG0POXEl7sNAfC3GKWzwCdF4U7
Zzt7J1nnG24jYChR8DKE7Jg=
=3dJw
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: CVS update: /ccvs/windows-NT/

2005-05-31 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

[EMAIL PROTECTED] wrote:

Log:
 * unistd.c, unistd.c: Add new usleep function using my_usleep
 logic taken from woe32.c file.
 * woe32.c, woe32.h: Add new (woe32_home_dir,woe32_shell) functions.
 * woe32.c: Modify woe32_nanosleep to use unistd.h usleep.


Glancing at lib/nanosleep.c, the usleep() implementation in
windows-NT/unistd.c, and based on the fact that signal() and select()
appear to be used elsewhere in windows-NT/*.c, it looks like
lib/nanosleep.c would compile on Windows with the right config.h.in.in
definitions.  Then the woe32_nanosleep and unistd.c usleep could be
removed in favor of the rpl_nanosleep in lib/nanosleep.c.

 * filesubr.c: Modify get_homedir to use woe32_home_dir.
 * pwd.c: Modify getpwuid to use woe32_home_dir  woe32_shell.
 Append USERNAME to login_strings array.


Again, unless USERNAME is a read-only env var, if there is a Windows API
for retrieving these sorts of values, it should probably be used in the
POSIX replacements in favor of writable environment variables.

Regards,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCnLXVLD1OTBfyMaQRAqR1AJ9b7K8yExwUCc0EIj4jUrersoSyJQCgsjec
sHEymcNNNjRzXscCVdl36pY=
=1rqH
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: OpenBSD 3.6 sparc64 stable crash

2005-05-31 Thread Derek Price
Alexander Taler wrote:

+2005-05-31  Alexander Taler [EMAIL PROTECTED]
+
+  * rcscmds.c: Change type of call_diff_argc_allocated from int to
+  size_t, to match the prototype of run_add_arg_p().  This fixes a
+  bus error in OpenBSD 3.6 sparc64.
  


Makes sense.  int  size_t probably have different sizes on this 64 bit
platform, which could explain the bus error.  Thanks for the patch! 
I've committed it on stable and feature.

Regards,

Derek




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: Module run.c Interface Standardized - Feature To Stable Branch

2005-05-30 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Conrad T. Pino wrote:

I'll implement at least Option 2 by Wednesday. Do you have any preferred
language or points you'd want covered in the FIXME note?


Nothing in particular.  Have at it.

Cheers,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCm5FkLD1OTBfyMaQRAt79AKCuZL4zTBKRpmBRYNCEPlPjjpdYqQCeIpNK
A157dndVzb7yQq/1HFrO4dA=
=788F
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: Feature Branch Windows Build Broken - lib/glob.c WINDOWS32

2005-05-30 Thread Derek Price
Conrad T. Pino wrote:

I suggest using %USERPROFILE% only as the next fall back for cases where any
of %HOMEDRIVE%%HOMEPATH% are missing.
  


I suggest some more research may be in order here first.  Make sure that
setting %USERPROFILE% isn't the perscribed method for overriding
%HOMEDRIVE%%HOMEPATH% when you want to use a network login or somesuch. 
If this is the case then %USERPROFILE% would need to have priority...

We've documented:

   %HOME%
  


It might be worth reconsidering %HOME% for a general, i.e. GNULIB or
GLIBC glob, implementation.  See below.

If all of %HOME%, %HOMEDRIVE%%HOMEPATH%, %USERPROFILE% are missing then we
are indeed down to very improbable cases.  I introduced %ALLUSERSPROFILE%
only as another fallback that's a better alternative to hard coded values.
  


Again, I'm not sure I agree here.  If you expected ~soandso/*.c to
search soandso's home directory for C sources, would you be happier if
your program told you, No such user `soandso', or happily returned
with a list of C sources that came from who-knows-where.  I think most
users would prefer the easier to spot error message in the problem
case.  I think a big part of the task here is simply going to be getting
the order-of-precedence for potential home directory values straight on
Windows.

There is no environment variable to locate the Default User profile.
I consider that only because the current glob.c hard coded value is a
now obsolete reference to that profile.

The registry is the only way to locate the Default User profile and
the default root directory for creating local profiles.

I'm not proposing we use these and enumerated them as alternatives to
consider.  Earlier in this message I committed to preparing as list of
possibilities and will includes these for discussion purposes.
  


Can you justify that using a Default User directory is the correct
thing to do when the logged in or requested user's directory cannot be
found?  I suspect this may be another case where an error message is
better, but perhaps you have a use case on Windows I am unfamilar with?

1. You proposed modifying pwd.c but when I searched for HOME, HOMEDRIVE
 HOMEPATH references I found this in windows-NT/filesubr.c:

   char *
   get_homedir ()
   {
   static char *pathbuf;
   char *hd, *hp;

   if (pathbuf != NULL)
   return pathbuf;
   else if ((hd = getenv (HOME)))
   return hd;
   else if ((hd = getenv (HOMEDRIVE))  (hp = getenv (HOMEPATH)))
   {
   pathbuf = xmalloc (strlen (hd) + strlen (hp) + 5);
   strcpy (pathbuf, hd);
   strcat (pathbuf, hp);

   return pathbuf;
   }
   else
   return NULL;
   }

which looks like the natural place to make the modifications.
  


I disagree.  pwd.c is implementing several standard UNIX/POSIX APIs for
locating information about a logged in or other user.  As such, they
seem like the likliest candidates for acceptance into GNULIB.  Such a
module could be plugged directly into a UNIX app on Windows and
potentially allow it to compile and work there.

Also, since %HOME% is non-standard on Windows, perhaps it is best to
leave %HOME% in the CVS get_homedir function, and implement whatever
seems to make standard sense on Windows in the pwd.c stuff.  When we
submit it to GNULIB/GLIBC, we can mention that we made this choice in
case there is disagreement.

2. In the get_homedir implementation shown above, disposal of the xmalloc
provided pathbuf is moot since it's allocated once and process termination
cleans up all messes.  Do you agree?
  


Yes.

3. The windows-NT/pwd.c implementation is broken because it does NOT call
the get_homedir function.  Do you agree?
  


No.  Again, pwd.c should implement the UNIX/POSIX APIs.  get_homedir can
wrap CVS functionality we think it is unlikely others will wish to
share, like consulting %HOME%.

4. Should we back port these changes to stable branch?
  

I don't think so.  You are welcome to explore the code paths and try to
determine where the pwd.c stubs may have been disabling functionality on
Windows such that fixing pwd.c should be considered a bug fix, but I am
inclined to call all of this new functionality.

It is probably worth noting that even in glob.c, these windows-NT/pwd.c
fixes wouldn't fix much in CVS.  The glob is being used to find files in
the repository and for the new HistorySearchPath config option.  Only in
the second case could processing `~' occur and I'm not sure it is
particularly useful.  Of course, that's not to say that GNULIB and GLIBC
might not value the contribution.

Cheers,

Derek



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: CVS update [cvs1-11-x-branch]: /ccvs/windows-NT/

2005-05-29 Thread Derek Price
Conrad T. Pino wrote:

Hi Derek,

  

From: Derek Price

There is an xnrealloc function in lib/xmalloc.c.  Isn't that being
compiled on Windows?



No, stable branch Windows build omits it because it doesn't exist.
My tests (see below) say lib/xmalloc.c is on feature branch only.
  


Ah, okay.  Sorry.  I already forgot that I put this diff bugfix into
stable and didn't read the tag on your commit.  I had to make that same
change to the src/run.c on stable when I ported the change from feature.  :)

Thanks,

Derek



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: Module run.c Interface Standardized - Feature To Stable Branch

2005-05-29 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Conrad T. Pino wrote:

1. Who is able to run the OS/2 feature and stable builds?


I don't know.  Ocassionally, someone pokes their head in and sends us a
patch to get it up and running, but I think it's been at least a year
since that has happened.

2. If no one steps forward to assist with building should
we attempt a fix that can't be tested nevertheless?


The policy, as I thought was documented in HACKING or somesuch, is that
we do not bother.  I can't find the original text in a quick scan, however.

In general, if there is no way to tell if it works, what is the point? 
In reality, I ocassionally cut and paste a new function or API change
when I change it elsewhere, but more often lately, I don't bother.  If
someone decides to fix the platform up, it should be easy enough to
trace the missing functions to their counter-parts in src, lib. or wherever.

Cheers,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCmlwmLD1OTBfyMaQRAqHtAKCtAxvzfZs0P2NUZvsPfXcUxRiyEwCgghx+
CDzN9M0fdJ8XuA1afbezSd8=
=+LUk
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: Feature Branch Windows Build Broken - lib/glob.c WINDOWS32

2005-05-28 Thread Derek Price
Conrad T. Pino wrote:

I propose we do both, I'll edit and test, you coach:
  


Sure.

I'm OK with leaving WINDOWS32 undefined in our project.  I'd like to see
an improvement in the WINDOWS32 code for the benefit of other projects if
for no other reason than saying thank you to GLib and GNULib by sending
back some useful code.

I will improve pwd.c also so long as cutting and pasting is acceptable
between pwd.c and glob.c is acceptable.
  


Hrm?  Cutting and pasting in which direction.  You can try and get the
pwd.c module into GNULIB it might work.  I just ran across the GNULIB
execute module which seems to have some Windows specific code.  The
macros stuff is already in GNULIB, so if you could abstract some of the
Windows specific stuff out into those macros, I think it can only simplify.

The bit of work concerns me only if we have an open issue that breaks the
Windows build.  If the Windows build works I'll work on this issue.
  


I believe the Windows build was working last night and probably is again
after my recent commit..

I assume inadvertantly fix...former is the pwd.c improvement.  If so
I share your motivation and agree.
  


Yes.

Do you really expect this to be set if %USERPROFILE% is not?  It depends
on it...



Windows NT, 2000, XP and 2003 will set the values.  I expect trouble only when
the user has used command window to undefine or redefine which is unlikely.
  


I'm not sure why earlier CVS developers missed the %USERPROFILE% value
then, unless it was missing in earlier versions of NT, but if you say
so...  Anyhow, if we leave %HOMEDRIVE%%HOMEPATH% as a fallback value, it
shouldn't be a big deal to add hte new handling.

No ALLUSERSPROFILE does not depend on USERPROFILE and you are correct on
it's use as shorthand to illustrate they typically have a common root.
  


Why even process ALLUSERSPROFILE here?  As long as %USERPROFILE% and
%HOMEDRIVE%%HOMEPATH% are susually set, then if they are unset then
something is wrong, I would think.  It just doesn't sound like a
reasonable fallback to me.  The UNIX fallback, or even secure method
is to read the /etc/passwd file.  Maybe the closest fallback on Windows
is to read the registry?

Power users to modify the registry can relocate their profile away from the
default profile root.

Networked users with file server resident profiles is another case.
  


True.  Is %USERPROFILES% the best we can do here?

Windows has no support for ~ and similar.  We can provide it as a reference
to $HOME, $USERPROFILE and/or $HOMEDRIVE, $HOMEPATH combination.
  


As part of glob, and to support consistent usage in CVS config files,
supporting ~ still seems reasonable.  Determining what that means is
up to us.  CVS supported the non-standard $HOME on Windows 95/98/ME
because there was nothing standard.  It is possible that continuing to
support that for glob is fine sine it won't normally be set anyhow, but
what we should aim at is whatever seems morally closest in Windows.


+  if (home_dir == NULL || home_dir[0] == '\0')
+  {
+  /*$SystemDrive/users is Windows NT 4 specific
+
+NEW INSTALLS of Windows 2000 and later use
+$SystemDrive/Documents and Settings
+
+UPGRADES use previous location
+
+The default user profile can't be found with an 
environment
+variable.  It's location is in the Windows 
registry.
+
+The SystemDrive environment variable is an 
alternative.
+*/
+  home_dir = c:/users/default; /* poor default */
+  }
  

CVS already uses %HOMEDRIVE%%HOMPATH% on windows (set automatically for
a long time on NT and carried through to XP), which sounds like another
good possibility.  I think it might predate %USERPROFILE%, so
%USERPROFILE% should probably be checked first.  It might be nice to
roll this all together into one place, like the pwd.c stuff, to avoid
having different portions of hte program do different things on Windows
with respect to $HOME.  Then the get_homedir() function from
windows-NT/filesubr.c should just check %HOME% then make the getpwname
(getlogin()) call.



I can't say which came first but it's not particularly relevant to me.
  


Newest is probably best, from the standpoint of supporting what
Microsoft declares most current first.  Supporting the legacy stuff in
chronologically reverse order should manage to support both old systems
and those who unset their %USERPROFILE% to allow their old setup, which
knew how to deal with %HOMEDRIVE%%HOMEPATH%, or whatever, to work.

Is %USERPROFILE% and %HOMEDRIVE%%HOMEPATH% really the same thing?  Now
that you have me talking about it, old memories that say the
%USERPROFILE% was just the equivalent of the UNIX .login script are
starting to surface.

I suggest we continue CVS past practice in a backwards compatible fashion.
  


Yes.

I 

Patch to protect spaces in diff arguments.

2005-05-27 Thread Derek Price
I just committed the attached patch to the stable branch.  This problem
has been listed in BUGS for some time, so I felt justified despite it
being a fairly large patch.  I went to some lengths to keep it clean and
I think that it mostly actually simplifes the code.

Cheers,

Derek
Index: BUGS
===
RCS file: /cvs/ccvs/BUGS,v
retrieving revision 1.55.6.18
retrieving revision 1.55.6.19
diff -u -p -r1.55.6.18 -r1.55.6.19
--- BUGS25 Aug 2004 03:14:01 -  1.55.6.18
+++ BUGS27 May 2005 16:25:41 -  1.55.6.19
@@ -88,13 +88,6 @@ an incorrect value, though this does not
 noticed under BSDI.
 
 
-* Spaces in arguments to `cvs diff' are currently split on spaces and tabs
-before being passed to diff.  This can often cause diff to abort since it can
-no longer interpret its options string and if it can, coincidentally,
-interpret its option string, then the problem may be output in unexpected
-formats.
-
-
 * Status
 
  /*---.
Index: ChangeLog
===
RCS file: /cvs/ccvs/ChangeLog,v
retrieving revision 1.692.2.209
retrieving revision 1.692.2.210
diff -u -p -r1.692.2.209 -r1.692.2.210
--- ChangeLog   4 May 2005 02:35:14 -   1.692.2.209
+++ ChangeLog   27 May 2005 16:25:41 -  1.692.2.210
@@ -1,3 +1,8 @@
+2005-05-27  Derek Price  [EMAIL PROTECTED]
+
+   * NEWS: Note diff space split fix.
+   * BUGS: Remove diff space split note.
+
 2005-05-03  Derek Price  [EMAIL PROTECTED]
 
* INSTALL: Add footnote about compiling a CVS checkout of CVS on a
Index: NEWS
===
RCS file: /cvs/ccvs/NEWS,v
retrieving revision 1.116.2.131
retrieving revision 1.116.2.132
diff -u -p -r1.116.2.131 -r1.116.2.132
--- NEWS2 May 2005 17:07:20 -   1.116.2.131
+++ NEWS27 May 2005 16:25:41 -  1.116.2.132
@@ -3,6 +3,8 @@ Changes since 1.11.20:
 
 BUG FIXES
 
+* `cvs diff' no longer splits its arguments on spaces.
+
 * Thanks to an old report and patch from Stewart Brodie [EMAIL PROTECTED], a
   potential crash in response to a corrupt RCS file has been fixed.
 
Index: src/ChangeLog
===
RCS file: /cvs/ccvs/src/ChangeLog,v
retrieving revision 1.2336.2.371
retrieving revision 1.2336.2.373
diff -u -p -r1.2336.2.371 -r1.2336.2.373
--- src/ChangeLog   2 May 2005 19:39:10 -   1.2336.2.371
+++ src/ChangeLog   27 May 2005 16:28:00 -  1.2336.2.373
@@ -1,3 +1,25 @@
+2005-05-27  Derek Price  [EMAIL PROTECTED]
+
+   * client.c (send_arg): Make arg const.
+   (send_option_string): Rename to...
+   (send_options): ...this and accept argc/argv in place of string.
+   * client.h: Update protos to match the changes to client.c.
+   * cvs.h (RCS_exec_rcsdiff, diff_exec): Update protos.
+   (run_add_arg_p, run_arg_free_p): New protos.
+   * diff.c (opts, opts_allocated): Replace with...
+   (diff_argv, diff_argc, diff_arg_allocated): ...these.
+   (add_diff_args): New convenience function.
+   (diff): Use new constructs and APIs.
+   * patch.c (patch_fileproc, RCS_checkin, RCS_delete_revs), rcscmds.c
+   (call_diff_add_arg, call_diff_setup, RCS_merge, RCS_exec_rcsdiff,
+   diff_exec, RCS_output_diff_options), update.c (patch_file): Use new
+   APIs.
+   * run.c (run_add_arg_p, run_arg_free_p): New functions.
+   (run_argc_allocated): Make size_t.
+   (run_setup, run_add_arg): Use new functions.
+   * sanity.sh: Accomodate above changes.
+   (rcslib-diffrgx-3): Slip in test for space splitting.
+
 2005-05-02  Derek Price  [EMAIL PROTECTED]
 
Remove unnecessary level of indirection.
Index: src/client.c
===
RCS file: /cvs/ccvs/src/client.c,v
retrieving revision 1.318.4.27
retrieving revision 1.318.4.28
diff -u -p -r1.318.4.27 -r1.318.4.28
--- src/client.c17 Mar 2005 15:39:09 -  1.318.4.27
+++ src/client.c27 May 2005 16:25:10 -  1.318.4.28
@@ -4903,10 +4903,10 @@ start_rsh_server (root, to_server, from_
 /* Send an argument STRING.  */
 void
 send_arg (string)
-char *string;
+const char *string;
 {
 char buf[1];
-char *p = string;
+const char *p = string;
 
 send_to_server (Argument , 0);
 
@@ -5404,36 +5404,15 @@ send_dirleave_proc (callerdat, dir, err,
 }
 
 /*
- * Send each option in a string to the server, one by one.
- * This assumes that the options are separated by spaces, for example
- * STRING might be --foo -C5 -y.
+ * Send each option in an array to the server, one by one.
+ * argv might be --foo=bar,  -C, 5, -y.
  */
-
 void
-send_option_string (string)
-char *string;
+send_options (int argc, char *const *argv)
 {
-char *copy;
-char *p;
-
-copy = xstrdup

Re: Feature Branch Windows Build Broken - lib/glob.c WINDOWS32

2005-05-26 Thread Derek Price
Conrad T. Pino wrote:

Yes, the Windows build completes.  Can you explain what home_dir value
will be in the WINDOWS32 undefined logic?
  


It looks like it would call, basically, getpwnam (getlogin()).  There
are substitutes for both in windows-NT/pwd.c, though it doesn't look
like they are doing much useful.

How about defining WINDOWS32 and using the patch below?
  


Maybe this would be preferable.  This would enable some of the [a-z]:/
swithcing other places in the file as well.  Of course, it's possible
much of that could be abstracted out using the FILE_SYSTEM_PREFIX_LEN 
ISSLASH macros.

My feeling is that it might be nice to move as much of your patch as
possible into pwd.c, abstract out as much of the drive letter prefix
stuff as possible into the aformentioned macros, skip defining
WINDOWS32, and see how things look, but it might be a bit of work.  If
you'd rather take the easy way out, I won't argue, but the former might
inadvertantly fix a few other hitherto unnoticed or ignored bugs on Windows.

Is it too much to hope for that Windows has dirent.h and implements
the readdir() family of functions and defining HAVE_DIRENT_H would be
enough here?



Yes, that's entirely too much to hope for.  The Windows build fakes an
ndir.h implementation in the windows-NT director and I committed a
patch to lib/glob_.h that supports the ndir.h flavor.

The #if logic was cut from lib/glob.c lines 53 through 71 with the
extras discarded.  My patch is a quick hack.  I would appreciate it if
you choose to make improvements.
  


No, I think what you did is fine, at least until more than one #ifdef is
needed.  The version in glob.c is nice for making the rest of the
dirent/direct switching pretty transparent, but it's not needed yet.

Index: lib/glob.c
===
RCS file: /cvs/ccvs/lib/glob.c,v
retrieving revision 1.15
diff -u -p -r1.15 glob.c
--- lib/glob.c 25 May 2005 20:23:38 -  1.15
+++ lib/glob.c 26 May 2005 10:57:36 -
@@ -524,8 +525,45 @@ glob (const char *pattern, int flags,
   home_dir = SYS:;
 # else
 #  ifdef WINDOWS32
+/* Windows doesn't set HOME, honor it if user sets it */
 if (home_dir == NULL || home_dir[0] == '\0')
-home_dir = c:/users/default; /* poor default */
+{
+/* Windows sets USERPROFILE like UNIX sets HOME */
+home_dir = getenv( USERPROFILE );
+}
+if (home_dir == NULL || home_dir[0] == '\0')
+{
+/* Windows sets APPDATA to $USERPROFILE/Application Data */
+home_dir = getenv( APPDATA );
+}
  


Do you really expect this to be set if %USERPROFILE% is not?  It depends
on it...

+if (home_dir == NULL || home_dir[0] == '\0')
+{
+/* Windows sets ALLUSERSPROFILE to $USERPROFILE/../All 
Users */
+home_dir = getenv( ALLUSERSPROFILE );
+}
  


Does this really depend on %USERPROFILE% too or is this just your
shorthand to refer to the user-profile directory?

+if (home_dir == NULL || home_dir[0] == '\0')
+{
+/* Windows sets SystemRoot to installation value typically
+   C:/WinNT but frequently C:/Windows */
+/* This may be a bad idea but it's an alternative to the root 
*/
+home_dir = getenv( SystemRoot );
+}
  


I'm not sure how I feel about using SystemRoot as a fallback for ~ or
~username...  sounds unintuitive and possibly dangerous.

+if (home_dir == NULL || home_dir[0] == '\0')
+{
+/*$SystemDrive/users is Windows NT 4 specific
+
+  NEW INSTALLS of Windows 2000 and later use
+  $SystemDrive/Documents and Settings
+
+  UPGRADES use previous location
+
+  The default user profile can't be found with an 
environment
+  variable.  It's location is in the Windows 
registry.
+
+  The SystemDrive environment variable is an 
alternative.
+  */
+home_dir = c:/users/default; /* poor default */
+}
  


CVS already uses %HOMEDRIVE%%HOMPATH% on windows (set automatically for
a long time on NT and carried through to XP), which sounds like another
good possibility.  I think it might predate %USERPROFILE%, so
%USERPROFILE% should probably be checked first.  It might be nice to
roll this all together into one place, like the pwd.c stuff, to avoid
having different portions of hte program do different things on Windows
with respect to $HOME.  Then the get_homedir() function from
windows-NT/filesubr.c should just check %HOME% then make the getpwname
(getlogin()) call.

Regards,

Derek



___
Bug-cvs mailing list
Bug-cvs@gnu.org

Re: [bug-gnulib] New GNULIB glob module?

2005-05-26 Thread Derek Price
Paul Eggert wrote:

Derek Price [EMAIL PROTECTED] writes:

  

I chose the _SYS_CDEFS_H route since it seemed simplest to me, though I
chose to name the macro `MISSING_SYS_CDEFS_H'.



Sorry, that's not right, since it fails in the following scenario:

  #define MISSING_SYS_CDEFS_H 27
  #include glob.h

in an ordinary program that is not using gnulib, but is using glibc.
MISSING_SYS_CDEFS_H is part of the user's namespace, and should not affect
how glob.h works.

Let's just use _SYS_CDEFS_H.  We can then remove all mention of
MISSING_SYS_CDEFS_H from glob_.h and undo the most recent change to
glob.m4.  This should be OK: if we run into some non-glibc that has
this problem it will probably use some other include file anyway.
  


Fair enough, but why undo the change to glob.m4?  Shouldn't I just
change the target of the AC_DEFINE from MISSING_SYS_CDEFS_H to _SYS_CDEFS_H?

Regards,

Derek



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


extensions.m4 patch (was Re: [bug-gnulib] New GNULIB glob module?)

2005-05-26 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Paul Eggert wrote:

--- extensions.m4.~1.6.~ 2005-02-23 05:49:36 -0800
+++ extensions.m4 2005-05-24 12:35:48 -0700
@@ -21,6 +21,10 @@ AC_DEFUN([gl_USE_SYSTEM_EXTENSIONS], [
 [/* Enable extensions on Solaris. */
 #ifndef __EXTENSIONS__
 # undef __EXTENSIONS__
+#endif
+#ifndef _POSIX_PTHREAD_SEMANTICS
+# undef _POSIX_PTHREAD_SEMANTICS
 #endif])
 AC_DEFINE([__EXTENSIONS__])
+ AC_DEFINE([_POSIX_PTHREAD_SEMANTICS])
 ])


I've installed this since it worked as advertised.

Cheers,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFClgh2LD1OTBfyMaQRAgWtAJ9OPSu9ONkQPFzzdXu8u+DSZadXaQCgsTWK
kIxtjhOf4KIbO/mVbj+jpEc=
=091c
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: Feature Branch Windows Build Broken - lib/canonicalize.c - ELOOP lstat

2005-05-25 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Conrad T. Pino wrote:

Hi Derek,

Here's a rough draft of a patch that allows Windows build to complete.
The draft includes edited files only and ignores generated files and
Windows build projects files are also omitted.

Briefly the plan is:

 #define stat wnt_stat
 #define lstat wnt_stat

 int wnt_stat (const char *file, struct wnt_stat *sb);

 Delete wnt_lstat definition


Are stat and lstat really equivalent on Windows?

Index: lib/system.h
===
RCS file: /cvs/ccvs/lib/system.h,v
retrieving revision 1.76
diff -u -p -r1.76 system.h
--- lib/system.h 24 May 2005 21:05:37 - 1.76
+++ lib/system.h 25 May 2005 01:20:36 -
@@ -371,7 +371,7 @@ extern int errno;
 otherwise return it unchanged. */
 #define convert_blocks(b, k) ((k) ? ((b) + 1) / 2 : (b))

-#ifndef S_ISLNK
+#if !defined(lstat)  !defined(S_ISLNK)
 # define lstat stat
 #endif


I suspect this was only relevant on Windows anyhow and the entire block
can be removed.

Index: windows-NT/config.h.in.footer
===
RCS file: /cvs/ccvs/windows-NT/config.h.in.footer,v
retrieving revision 1.4
diff -u -p -r1.4 config.h.in.footer
--- windows-NT/config.h.in.footer 1 Mar 2005 14:37:39 - 1.4
+++ windows-NT/config.h.in.footer 25 May 2005 01:20:37 -
@@ -11,11 +11,7 @@
 #define CVS_MKDIR wnt_mkdir
 int wnt_mkdir (const char *PATH, int MODE);

-#define CVS_STAT wnt_stat
-int wnt_stat ();
-
-#define CVS_LSTAT wnt_lstat
-int wnt_lstat ();
+int wnt_stat (const char *file, struct wnt_stat *sb);


This may prove unnecessary.  See below.

 #define CVS_RENAME wnt_rename
 int wnt_rename (const char *, const char *);
@@ -95,3 +91,6 @@ char *sock_strerror (int errnum);
 /* getpagesize is missing on Windows, but 4096 seems to do the right
 thing. */
 #define getpagesize() 4096
+
+/* Windows has no ELOOP value in errno.h */
+#define ELOOP 1


How about #define ELOOP EMLINK?  At least if this error ever comes up,
sterror will then produce a somewhat meaningful error message on Windows.

Index: windows-NT/config.h.in.in
===
RCS file: /cvs/ccvs/windows-NT/config.h.in.in,v
retrieving revision 1.30
diff -u -p -r1.30 config.h.in.in
--- windows-NT/config.h.in.in 2 May 2005 14:08:18 - 1.30
+++ windows-NT/config.h.in.in 25 May 2005 01:20:37 -
@@ -92,8 +92,9 @@
 message to be appended to the temp file when the editor is started. */
 #undef FORCE_USE_EDITOR

-/* Define if gettimeofday clobbers localtime's static buffer. */
-#undef GETTIMEOFDAY_CLOBBERS_LOCALTIME_BUFFER


Why are you removing these lines?

Cheers,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFClJehLD1OTBfyMaQRAghmAJ92Y1HxX1mz9Nr5N/vGtEQeu3XORQCfaFP1
5XRVx2RxZSdqN4YiqT1jrsw=
=I2jp
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: Feature Branch Solaris Build Broken - lib/glob.c errors

2005-05-25 Thread Derek Price
Conrad T. Pino wrote:

Hi Derek,

  

From: Conrad T. Pino



From: Derek Price

Perhaps the problem is in your GCC installation or usage?
  


A gcc upgrade sure helps.  I installed gcc 3.4.2 binary from SunFreeWare.\
  


I brought up changes to the GNULIB stat module up on bug-gnulib and
found out that this problem has been encountered before.  GNULIB is
going to continue supporting the older gccs without the fix you found in
3.4.2, so I have updated the glob.c file to use struct_stat64 in place
of struct stat, and #defined struct_stat64 to struct stat64 or struct
stat as appropriate.  Does this work for you with whichever compiler you
choose to stick with?

Regards,

Derek



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [bug-gnulib] New GNULIB glob module?

2005-05-25 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Paul Eggert wrote:

Derek Price [EMAIL PROTECTED] writes:

+# ifdef HAVE___POSIX_GETPWNAM_R
+ /* Solaris. */
+# define getpwnam_r(name, bufp, buf, len, res) \
+ __posix_getpwnam_r (name, bufp, buf, len, res)
+# endif


I don't see why this is needed. The Solaris include files already
contain the magic necessary to convert getpwnam_r to
__posix_getpwnam_r, right? Or is it because that depends on
_POSIX_PTHREAD_SEMANTICS? If so, why not define that, as follows? I
don't see why any gnulib-using application would want the nonstandard
Solaris versions of the *_r functions.

--- extensions.m4.~1.6.~ 2005-02-23 05:49:36 -0800
+++ extensions.m4 2005-05-24 12:35:48 -0700
@@ -21,6 +21,10 @@ AC_DEFUN([gl_USE_SYSTEM_EXTENSIONS], [
 [/* Enable extensions on Solaris. */
 #ifndef __EXTENSIONS__
 # undef __EXTENSIONS__
+#endif
+#ifndef _POSIX_PTHREAD_SEMANTICS
+# undef _POSIX_PTHREAD_SEMANTICS
 #endif])
 AC_DEFINE([__EXTENSIONS__])
+ AC_DEFINE([_POSIX_PTHREAD_SEMANTICS])
 ])


I really have no idea.  Larry, can you tell us if defining
_POSIX_PTHREAD_SEMANTICS would work to get the POSIX version of
getpwnam_r on Solaris?

Regards,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFClKxWLD1OTBfyMaQRAot/AKDvKB48aoCE0kys6bB3zxx0KT06sACgijeV
z/hTtSVzW3MRjWbCzAZy7pg=
=4CER
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [bug-gnulib] New GNULIB glob module?

2005-05-25 Thread Derek Price
Larry Jones wrote:

Derek Price writes:
  

Larry, can you tell us if defining
_POSIX_PTHREAD_SEMANTICS would work to get the POSIX version of
getpwnam_r on Solaris?



It looks like it.
  


I've committed Paul's patch to the CVS CVS tree, as well as removing the
associated glob.c changes, and I will install it in GNULIB if it passes
CVS nightly testing on Solaris.

Regards,

Derek



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: Feature Branch Solaris Build Broken - lib/glob.c errors

2005-05-25 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Conrad T. Pino wrote:

I loaded the gcc 2.95 compiler for the sole purpose of compiling CVS on
this platform since previously CVS Home didn't offer a binary for this
platform. I loaded the gcc 3.4 compiler for the sole purpose of fixing
the CVS compile on this platform. I assume both versions can coexist
with appropriate configuration. I turn the questions around:


Does what I just checked in work for you on Solaris?

How can we use both versions to the CVS Project's advantage?
Which version should be canonical for next binary release?


With luck, it doesn't matter now.

Regards,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFClNl3LD1OTBfyMaQRAuw0AKCNgFRpezLlLdiqkdB20fWAgTc+YwCeK08B
0w1T6Fqgvd+DX2ysEtKdNAQ=
=Zx0Q
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: Feature Branch Windows Build Broken - lib/glob.c WINDOWS32

2005-05-25 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Conrad T. Pino wrote:

Oops, I forgot the error message which follows.

Compiling...
glob.c
h:\conrad\projects\cvs-1.12\lib\glob.c(535) : warning C4013: 'sysconf'
undefined; assuming extern returning int
h:\conrad\projects\cvs-1.12\lib\glob.c(535) : error C2065:
'_SC_LOGIN_NAME_MAX' : undeclared identifier


I've checked in what I hope is a fix for this.

h:\conrad\projects\cvs-1.12\lib\glob.c(1171) : warning C4133: ':' :
incompatible types - from 'struct direct *' to 'struct dirent *'
h:\conrad\projects\cvs-1.12\lib\glob.c(1171) : warning C4133:
'initializing' : incompatible types - from 'struct dirent *' to
'struct direct *'


Is it too much to hope for that Windows has dirent.h and implements
the readdir() family of functions and defining HAVE_DIRENT_H would be
enough here?

Cheers,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFClN+OLD1OTBfyMaQRAi6LAJ0WECXd7eJETb52st5XbAcwTPsCyACg61oc
X0Mj+ydzrG/osYJ1DCtmIWo=
=2GBK
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: Feature Branch Windows Build - lib/dup-safer.c dup

2005-05-25 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Conrad T. Pino wrote:

Hi All,

The dup function call in lib/dup-safer.c has no
prototype included. Windows Visual C 6.0 does NOT
implement dup but does implement _dup as:

 int _dup( int handle );

I've added #define dup _dup to config.h chain
but Microsoft provides the prototype in io.h
which is NOT referenced in lib/dup-safer.c and
perhaps should be.


Are you willing to take this up on GNULIB?

I don't know the m4 stuff and can't provide the
complete solutions. Suggestions are welcome.


This won't matter since the configure stuff doesn't run on Windows
anyhow.  We just need to get the correct define, in this case probably
HAVE_IO_H, into config.h and only include it when it is present in
dup-safer.c.

The warning is below and it could be ignored since
the assumed and actual return types are the same.


Alternatively, you could just provide the prototype in
config.h.in.footer too.

Cheers,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFClOaWLD1OTBfyMaQRAgeeAKCW+h10H3ycXyKVp6x4c4zNASzlDACfZYuM
EKdxgEAkk+A4uJ95YOcxz8g=
=0WDE
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: Feature Branch Solaris Build Broken - lib/glob.c errors

2005-05-24 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Conrad T. Pino wrote:

Hi Derek,

We have a new lib/glob.c error today which I hope to
understand before committing #include sys/stat.h
addition to lib/glob_.h you suggested.


Adding #include sys/stat.h to glob_.h doesn't help with this new
error?  I wouldn't expect this error in glob.c anyhow, since it includes
sys/types.h  sys/stat.h unconditionally.  According to POSIX.2,
struct stat should be defined in sys/stat.h.  This same code, short of
a few recent changes, was compiling and passing tests on Solaris 8 the
other night.

Regards,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCk3f2LD1OTBfyMaQRAtuHAJ98+uXWGRexlVslLWvfCE1+yCbMQQCgqvo6
JgiejX7f4tv94fJ5EEAz1Rk=
=9D5+
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: Feature Branch Solaris Build Broken - lib/glob.c errors

2005-05-24 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

It looks like your header is using some sort of #pragma to redefine the
function names, which I would hope would make them look less like macros
and actually remap the functions, allowing us to use the macros in
glob.c as they stand.

You are still encountering this problem with the latest glob.c?  We were
encountering problems using the *64 structs and functions on HP-UX and I
rewrote the file this morning to attempt to let compiler magic take care
of the 64 bit conversion, which is supposed to work transparently on all
systems.

Regards,

Derek


Conrad T. Pino wrote:

Hi Derek,

This platform's sys/stat.h implementation in this case
defines macros for stat, fstat and lstat to be the
tokens stat64, fstat64 and lstat64 respectively.
My analysis of sys/stat.h relevent section is below.

These macro definitions are in effect when struct stat
definition is encountered which becomes struct stat64.

Line 187 of lib/glob.c redefines stat64 as:

 # define stat64 stat

which causes later struct stat references to be become
struct stat64 which becomes struct stat which is an
empty forward declaration at best.

It seems defining macros for stat, fstat, lstat,
stat64, fstat64 and lstat64 on this platform is
a risky proposition.

Conrad

/*
 * large file compilation environment setup
 */
#if !defined(_LP64)  _FILE_OFFSET_BITS == 64
// This is true #error Die
#ifdef __PRAGMA_REDEFINE_EXTNAME
// This is false #error Die
#pragma redefine_extname fstat fstat64
#pragma redefine_extname stat stat64

#if (!defined(_POSIX_C_SOURCE)  !defined(_XOPEN_SOURCE)) || \
 defined(_XPG4_2) || defined(__EXTENSIONS__)
// This is false #error Die
#pragma redefine_extname lstat lstat64
#endif
#else /* __PRAGMA_REDEFINE_EXTNAME */
// This is true #error Die
#define fstat fstat64
#define stat stat64
#if (!defined(_POSIX_C_SOURCE)  !defined(_XOPEN_SOURCE)) || \
 defined(_XPG4_2) || defined(__EXTENSIONS__)
// This is true #error Die
#define lstat lstat64
#endif
#endif /* __PRAGMA_REDEFINE_EXTNAME */
#endif /* !_LP64  _FILE_OFFSET_BITS == 64 */


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCk5rLLD1OTBfyMaQRAhbVAJ4weUVLak0/PGsMQUPYxK+mVgy91gCeMJSV
Z/A53LJrStIsU8S9irOFLlY=
=MgP1
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: Feature Branch Solaris Build Broken - lib/glob.c errors

2005-05-24 Thread Derek Price
Conrad T. Pino wrote:

Hi Derek,

  

From: Derek Price



1. #include sys/stat.h within glob_.h file.
  

This would be the way to go.  You may commit this if you wish.



I committed an inclusion immediately before struct stat forward
declaration to assure the Solaris stat macro is used but on 2nd
reflection the forward declaration is moot.  I'm considering it's
removal.  Any objection on your part?
  


No objections here.  Please do so.  Also, please shorten this comment to
something like get struct stat:

/* Solaris may #define stat stat64 in some cases */

Thanks,

Derek



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: Feature Branch Solaris Build Broken - lib/glob.c errors

2005-05-24 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Conrad T. Pino wrote:

Defining macro __PRAGMA_REDEFINE_EXTNAME on the command line stops all
errors
and warnings in lib/glob.c compile.


(For those new to this thread, this is because the Solaris headers
#define stat stat64 when the __PRAGMA_REDEFINE_EXTNAME macro is not
defined).

Why isn't gcc defining this value?  According to what I could find on
the web, the compiler should define __PRAGMA_REDEFINE_EXTNAME if it
supports the redefine_extname pragma, which this compiler apparently does.

http://docs.sun.com/app/docs/doc/816-5175/6mbba7f3u?a=view.

Why haven't we seen this error before?  Is this a common problem on
Solaris 10?  Is this problem true of any gcc on any Solaris?  Is it
specific to your setup?  What happens if you use a native Soalris compiler?

A quick google search on __PRAGMA_REDEFINE_EXTNAME Solaris 10 gcc
brings up a few discussions of this.  The gist of the first few I read
is that some people ocassionally end up with broken GCCs which do not
properly define this macro, but most GCCs should.  The reason for the
difference was not apparent in the first several pages I scanned.

Digging a little deeper, this is even documented in the Linux info
manual for gcc:

 Solaris Pragmas
 ---

 For compatibility with the SunPRO compiler, the following pragma is
 supported.

 `redefine_extname OLDNAME NEWNAME'
 This pragma gives the C function OLDNAME the assembler label
 NEWNAME. The pragma must appear before the function declaration.
 This pragma is equivalent to the asm labels extension (*note Asm
 Labels::). The preprocessor defines `__PRAGMA_REDEFINE_EXTNAME'
 if the pragma is available.


Perhaps the problem is in your GCC installation or usage?

Regards,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCk+etLD1OTBfyMaQRAs9VAJ9KrtbzdH5ikvAiviVanqIfsSQOZwCglN4c
RbnHOR4yXu7wBbG9E9s5P4U=
=78Ar
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: Feature Branch Solaris Build Broken - lib/glob.c errors

2005-05-21 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Conrad T. Pino wrote:

Excuse me for perhaps being slow but why is configure choosing to
use lib/glob.h when the platform has /usr/include/glob.h whose
contents follow?


Partly because the GNU glob semantics are more extensive than the POSIX
spec, partly because Mark Baushke reported that even glob functions that
are supposed to meet the POSIX spec often don't, the new glob module
only uses a system glob when it appears to be GNU glob.  I can't tell
for sure without reviewing your configure.log, but the specific reason
configure noticed that your glob.h doesn't work is probably the lack of
a gnu-versions.h defining the _GNU_GLOB_INTERFACE_VERSION macro.

Cheers,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCj7VRLD1OTBfyMaQRAjPjAKDIQrjsR+KcEDO+I1s5VvDLoq1uKgCg6zB2
TbTb97b7MY0vBc5ksWkTY6U=
=FvX6
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: Feature Branch Solaris Build Broken - lib/glob.c errors

2005-05-21 Thread Derek Price
Conrad T. Pino wrote:

1. #include sys/stat.h within glob_.h file.
  


This would be the way to go.  You may commit this if you wish.

2. Move #include glob.h below #include sys/stat.h in glob.c file.
  


This is incorrect.  The GNULIB convention is to include a module's
header immediately following the include of config.h in its associated
source file (i.e. glob.c first including config.h then immediately
including glob.h) to test the module's interface.

Regards,

Derek



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: Feature Branch Solaris Build Broken - lib/glob.c errors

2005-05-20 Thread Derek Price
Conrad T. Pino wrote:

From: Derek Price [mailto:[EMAIL PROTECTED]

I think I just checked in fixes for both Solaris compile problems, this
one and one with getpwnam_r.  Could you let me know if they work?  I
have no way to test here.



The compile completes but we have warnings (see below).  Problem may
be struct stat definition and I've include this platform's definition.
  


This should be irrelevant, since all reference to struct stat should
be made using the Solaris definition.  Our code never attempts to define
it and I am fairly certain that the struct stat; line in glob_.h only
declares the existance of said structure.

 719: ? ((*pglob-gl_stat) (dirname, st) == 0
1066:? (*pglob-gl_stat) (fullname, st) == 0  S_ISDIR (st.st_mode)
1116: ? (*pglob-gl_stat) (fullname, st)

gcc -DHAVE_CONFIG_H -I. -I. -I..-Ino/include  -g -O2 -c glob.c
glob.c: In function `rpl_glob':
glob.c:719: warning: passing arg 2 of pointer to function from incompatible 
pointer type
glob.c: In function `is_dir_p':
glob.c:1066: warning: passing arg 2 of pointer to function from incompatible 
pointer type
glob.c: In function `glob_in_dir':
glob.c:1116: warning: passing arg 2 of pointer to function from incompatible 
pointer type
  


I am more suspicious of the __restrict keyword.  restrict should not
cause this sort of warning by my understanding of the C99 spec, but is
it possible that this is doing something we don't understand on
Solaris?  Here's the prototype of those function calls:

#ifdef __USE_GNU
int (*gl_lstat) (__const char *__restrict, struct stat *__restrict);
int (*gl_stat) (__const char *__restrict, struct stat *__restrict);
#else
int (*gl_lstat) (__const char *__restrict, void *__restrict);
int (*gl_stat) (__const char *__restrict, void *__restrict);
#endif

So, I am guessing that the problem is here.  ST is definitately a
struct stat in all three of the calls your compiler is warning about. 
We should also be able to assume __USE_GNU is set by the line at the
beginning of glob_.h.  Even if this wasn't so, by C89 any pointer type
should be castable to void *, so the problem should still be with the
restrict keyword.

Regards,

Derek



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


GZip level restriction

2005-05-20 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hey all,

I discussed adding a compression level restriction on the server as a
work-around for another bug that has since been fixed a few months back.

I can't find the email, but I believe Mark Baushke suggested a
restriction format like:

AllowedGZipLevels=0123456789

where 0 meant allowing no compression, and failing when the level
requested by the client was not in the list.

I think I actually prefer something more like:

DefaultGZipLevel=6
MinGZipLevel=3
MaxGZipLevel=6

and code that says:

if (level == 0) level = DefaultGZipLevel;
if (level  MinGZipLevel) level = MinGZipLevel;
if (level  MaxGZipLevel) level = MaxGZipLevel;

In preference to actually issuing an error, though perhaps a warning
would still be appropriate.  This way, users that put cvs -z9 in their
.cvsrc will always get the maximum gzip level allowed by any server and
still be able to use their .cvsrc with all the servers they access. 
Also, decompression is much less CPU intensive than compression, so it
shouldn't hurt to let the client compress at whatever level it likes and
clients should still use level 9 for compression in this scenario, and
the server would use whatever was declared its max level.

Just wanted to run this by the list before I begin coding.  I suppose
that all four config keywords could be added.  Then, default, min, and
max could be processed as I am suggesting and AllowedGZipLevels could be
used if an admin wanted their server to emit real errors for some
reason.  I'm not sure I see the utility here, though, so I'd just as
soon leave it out unless someone can come up with a believable scenario
which demonstrates its utility.

Cheers,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCjiRpLD1OTBfyMaQRApggAKDewo8mJtB5OEiYRn3Dtt1o9Ljm0QCeIZEY
SC55YocLuAh4P8bMPQN6KaA=
=y45z
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: GZip level restriction

2005-05-20 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Larry Jones wrote:

Derek Price writes:

I discussed adding a compression level restriction on the server as a
work-around for another bug that has since been fixed a few months back.


I don't think hard restrictions are a good idea. The best compression
level depends on the total system: the server machine, the client
machine, and the communication path between them. The server doesn't
know enough about the whole system to impose absolute restrictions. If
I'm at the other end of a 300bps phone line, I want -z9 no matter how
much CPU time it takes. If I'm trying to debug the connection, I want
-z0 even if the server is at the other end of a 300bps phone line.
Since the client is most likely to have an intelligent operator behind
it who *can* determine the properties of the entire system, I think the
server should always try to provide what the client asks for.


I don't agree.  First off, once Min and Max configs are implemented, an
adminstrator who agrees with you can simply not touch their config file
or explicitly set MinCompressionLevel=0 and MaxCompressionLevel=9 and
allow users to make their own decision about what level is best.

Secondly, if I am an administrator running a 200Mhz server behind a
high-speed DSL, I might want to set MaxCompressionLevel=0 or 1 depending
on how I felt about hard errors and avoid trusting any tom, dick or
harry to get it right and not bring my server to a crawl.  This actually
applies to an admin running a 3GHz server behind a T1 with enough users
that -z9 can still bog down the system when 20 of them hit the server at
once.  A max compression level of, say, 3, might double the number of
clients that can hit the server before it reaches maximum load.

This is especially relevant for admins dealing with lazy users out there
like me who run on fast client machines behind a medium-speed DSL and
lazily specify -z9 in their .cvsrc for all servers.

Similarly, if my server is up on a fast machine behind a slow modem,
perhaps I could confidently set my MinCompressionLevel=9.

In short, there are scenarios where it makes sense for the server admin
to want to restrict the compresssion level, this feature wouldn't be
disabling any old functionality, and I am offering to do the work. 
Where is the harm?

On the other hand, it would be nice if there were a way to specify a
default compression level or range of levels (both for the server and
the client) that could be used in the absence of any explicit
specification by the user. Of course, reconciling conflicting defaults
could be an interesting challenge.


To some extent this would be happening with my proposed change.  A
client that had requested -z9 on a fast machine would always compress
their data at level 9, but the server would only compress its data at
whatever maximum level had been set, limiting the load on its CPU.

Similarly for a client -z3 and a server with a min level of 9.  The
client would compress at 3 and the server at 9, saving most the
bandwidth and not bombing the client CPU.

Regards,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCjlJALD1OTBfyMaQRAqeeAKDlAgwm32k1C5WoXaPjPZuv6vGXBQCfZv6+
s8/5+7gP1IHGn/ZDh7/m998=
=5OIj
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [bug-gnulib] New GNULIB glob module?

2005-05-20 Thread Derek Price
Paul Eggert wrote:

There is one change I know I made that might have an effect.  I added
the !defined _LIBC to the following block because I was unsure what
__REDIRECT_NTH was supposed to be doing



I think that one's OK.
  


Larry Jones on the CVS team just made a comment that makes me wonder if
it is, at least if we still plan on sharing this header with glibc... 
isn't the conversion to 64 bit file sizes and offsets supposed to be
transparent and handled by compile-time magic?

So, all the HAVE_.*64 stuff in glob.c shouldn't be necessary when !_LIBC.

Also, this particular bit in glob_.h would need to be used when !_LIBC
as well, since user-space programs compiling against the glob.h system
header from glibc would want glob64 used as compile-time magic, correct?

Please excuse me if this is way off, I don't have much experience at the
64-bit file offset stuff, myself.  One thing that leads me to believe I
may be wrong is that it looks like the glob64 from glibc 2.3.5 is only a
stub function.

Regards,

Derek



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: Feature Branch Solaris Build Broken - lib/glob.c errors

2005-05-19 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Conrad T. Pino wrote:

The Solaris function declaration from

 /usr/include/unistd.h:850: previous declaration of `getlogin_r'

looks like:

 extern char *getlogin_r(char *, int);

and lib/glob.c line 194 looks like:

 extern int getlogin_r (char *, size_t);


I think I just checked in fixes for both Solaris compile problems, this
one and one with getpwnam_r.  Could you let me know if they work?  I
have no way to test here.

Regards,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCjSJNLD1OTBfyMaQRAu1zAKCQHUN7hUIRF3cg8ifF5SZhhMYCVgCgqVVM
qHJtNR8Jvse2ww0zgw/MR5s=
=H0VL
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [bug-gnulib] New GNULIB glob module?

2005-05-18 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Paul Eggert wrote:

Answering my own question: yes it will, in general, because perhaps
the gnulib version fixes a bug that's in the glibc version, and the
user wants the gnulib version. So we should worry about this.
And (as far as I can see) the simplest fix is to do this:

#if defined _LIBC || HAVE_SYS_CDEFS_H
# include sys/cdefs.h
#endif

with the appropriate change to glob.m4 to define HAVE_SYS_CDEFS_H.


Done.  Patch delayed.

Regards,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCi2ApLD1OTBfyMaQRAtapAJ47AVMRrJV5FEhKkybHBWaYRrcrXgCgspg9
PuWjxQRih2G3aP9omCCowAU=
=s6g2
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: Feature Branch Windows Build Broken - New GNULIB glob module

2005-05-18 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Conrad T. Pino wrote:

I updated with the recent commit of the glob module and we have a
new warning on line 1184 of lib/glob.c file (see below)


Let's revisit this after you provide definitions for the following
macros in windows-NT/config.h.in.in:

../config.h.in line 101 has #undef GLOB_PREFIX not found in ./config.h.in.in
../config.h.in line 234 has #undef HAVE_DECL_STRDUP not found in
./config.h.in.in
../config.h.in line 297 has #undef HAVE_GETLOGIN_R not found in
./config.h.in.in
../config.h.in line 309 has #undef HAVE_GETPWNAM_R not found in
./config.h.in.in
../config.h.in line 533 has #undef HAVE_SIGINTERRUPT not found in
./config.h.in.in
../config.h.in line 548 has #undef HAVE_STAT64 not found in ./config.h.in.in
../config.h.in line 577 has #undef HAVE_STRDUP not found in ./config.h.in.in
../config.h.in line 607 has #undef HAVE_STRUCT_DIRENT64 not found in
./config.h.in.in
../config.h.in line 611 has #undef HAVE_STRUCT_DIRENT_D_TYPE not found
in ./config.h.in.in
../config.h.in line 632 has #undef HAVE_SYS_CDEFS_H not found in
./config.h.in.in


GLOB_PREFIX should be #defined to `rpl_'.  The rest of the macros are
looking for particular function declarations (prototypes), functions,
headers, or type definitions and need to be defined or undefined as such
are found or not on Windows with MSVC (or in the substitute functions in
windows-NT/*.[ch]).  HAVE_STRUCT_DIRENT_D_TYPE, in particular, wants to
know if struct dirent has a member named `d_type'.

Glancing at the lines that #define dirent direct in lib/glob.c, they
depend on the absence of dirent.h.  Assuming that Windows has
dirent.h then, since it did not complain about a missing definition
for struct dirent, but only about a bad typecast, a #define
HAVE_DIRENT_H 1 may also be appropriate in config.h.in.in.

Cheers,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCi2aELD1OTBfyMaQRAqQAAJ9bS1iHmJGQtBfs9dPxaKbxSX6aqwCeIDmB
Y4z8mNkcVDh+Yq2saXEQVHY=
=xVwO
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: history and val-tags locks.

2005-05-18 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mark D. Baushke wrote:

 For pserver, the administrator has full control over
 the command line.

 For server, if the administrator is using a
 restricted shell for users, they may or may not be
 able to restrict command-line arguments (it
 depends on how the restricted shell is
 implemented).


For server, OpenSSH, at the very least, allows the command line to be
restricted.  Are we really worried about the security of the command
line if the user is still using a vulnerable tool like RSH to access
their server?

 I have used (am using) a set-gid cvs and it does
 not disable the use of UNIX uids at all. Yes, it
 does inhibit gids as the entire repository uses
 the same gid ('cvs'), but the cvs_acls deals with
 permissions for commit and anyone with a login to
 the special-purpose CVS server has already been
 granted read permissions for checkout in any case.

 I will grant you that this is not necessarily a
 normal situation, but I make note of it as setuid
 is not the only configuration possiblity here.


Well, no, but for a secure setup, aren't we still recommending that the
admin rely on a transport such as SSH and filesystem permissions or ACLs
for access restriction in the repository?  The stated position of the
CVS developers has been that users should rely on systems that get more
thorough security audits than CVS does to provide the secure portions of
their setups.  This means using SSH as a transport, restricting the
command line, and relying on system permissions/ACLs to restrict access
to the various portions of a repository.

setuid and setgid CVS executables both disable the fine-grained access
restrictions that would otherwise be possible, limiting you, basically,
to one group per repository/server.

 As an alternative, I would not have a problem with
 allowing cvs to be built with a list of
 directories that could be searched for a valid
 config file. So, a --enable-config-prefix=/etc/cvs
 might mean that /etc/cvs/$CVSROOT/config would looked
 at before $CVSROOT/config ... doing that means that
 the administrator would still have complete control
 over the configurations and would not need to rely
 on the user to make the right choice.


This compromise does sound reasonable.  Would you then consider a
default value of `--enable-config-prefix=/etc' as reasonable here?  i.e.
the ability to override the config would default to `on', with access to
config files restricted to /etc and subdirs.

 The downside is that src/sanity.sh tests for this
 case would be more painful.


Well, we could test that the restricted paths were disabled, at least.

 As far as your src/sanity.sh tests, I believe you
 should use the -c CONFIG-FILE to determine if cvs
 has been configured with this option or not before
 you fail the tests (granted STABLE does not have
 that available to sanity.sh)


If it defaults to on, with config-prefix used as you suggest, would you
still consider this last important?

Regards,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCi525LD1OTBfyMaQRAjERAKDuDciHLatseYmpN/PlQABI4Kcy7gCghAs8
KpNygtYAx/ZTx2+JWGjNaQI=
=G/xc
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [bug-gnulib] New GNULIB glob module?

2005-05-17 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thanks for the latest round.  I'm going to be out of the office today,
but I should get to it by tomorrow.

Regards,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCiICvLD1OTBfyMaQRAsMbAJ96UgJcf/G+zBfOlXBJM+nBJzff/ACglQte
CYnnsSKWV74qlZJbIcVNNWk=
=0b5Z
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: Feature Branch Windows Build Broken - New GNULIB glob module

2005-05-17 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Conrad T. Pino wrote:

The following patch lets me get this far in the Windows IDE build:
Configuration: libcvs - Win32 Debug
Compiling...
glob.c
H:\Conrad\Projects\cvs-1.12\lib\glob.c(253) : warning C4028: formal
parameter 1 different from declaration
H:\Conrad\Projects\cvs-1.12\lib\glob.c(253) : warning C4028: formal
parameter 4 different from declaration
H:\Conrad\Projects\cvs-1.12\lib\glob.c(668) : warning C4090: 'function'
: different 'const' qualifiers
H:\Conrad\Projects\cvs-1.12\lib\glob.c(668) : warning C4024: 'getpwnam'
: different types for formal and actual parameter 1
H:\Conrad\Projects\cvs-1.12\lib\glob.c(739) : warning C4013:
'glob_pattern_p' undefined; assuming extern returning int
H:\Conrad\Projects\cvs-1.12\lib\glob.c(334) : fatal error C1600:
unsupported data type
Error executing cl.exe.

cvs.exe - 1 error(s), 5 warning(s)
===
The following patches do the following:

1. Add WIN32 conditional #defines to lib/glob_.h to hide compile
errors.

2. Modify lib/libcvs.dsp to make lib/glob.h file
from lib/glob_.h file.

3. Modify Modify lib/libcvs.dsp to build lib/glob.c which is
where the compile is failing after my hacks to lib/glob_.h file.
===
Index: lib/glob_.h
===
RCS file: /cvs/ccvs/lib/glob_.h,v
retrieving revision 1.5
diff -u -p -r1.5 glob_.h
--- lib/glob_.h 15 May 2005 16:44:04 - 1.5
+++ lib/glob_.h 17 May 2005 04:18:51 -
@@ -19,6 +19,12 @@
 #ifndef _GLOB_H
 #define _GLOB_H 1

+#ifdef WIN32
+#define __BEGIN_DECLS
+#define __END_DECLS
+#define __const const
+#endif


I'm going to suggest something a little more general to the GNULIB
maintainers:

#ifndef __BEGIN_DECLS
# define __BEGIN_DECLS
#endif
#ifndef __END_DECLS
# define __END_DECLS
#endif
#ifndef __const
# define __const const
#endif

I won't comment on the Windows build stuff - it sounds like you are
mirroring what the UNIX build is doing, but otherwise I prefer to stay
out of it.

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCigN0LD1OTBfyMaQRAnTvAJsHGOa5tqkD9crYZZ1/lFoYrsIS4QCgkChQ
eVG7KDjY6HnZUNK+LuIeUP0=
=FheJ
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [bug-gnulib] New GNULIB glob module?

2005-05-17 Thread Derek Price
Paul Eggert wrote:

Derek Price [EMAIL PROTECTED] writes:

  

 /* Enable GNU extensions in glob.h.  */
-#ifndef _GNU_SOURCE
+#if defined _LIBC  !defined _GNU_SOURCE
 # define _GNU_SOURCE 1
 #endif



I just checked the glibc source file include/libc-symbols.h, and it
defines both _LIBC and _GNU_SOURCE.  So this stuff isn't needed at
all; please remove these lines from glob.c instead.
  


Done.

+   HAVE_STRUCT_DIRENT_D_TYPE is defined by GNULIB's glob.m4 when the same
+   member is found.  */



A bit wordy; please rephrase to HAVE_STRUCT_DIRENT_D_TYPE plays the
same rule in gnulib.
  


Rephrased.

-  qsort ((__ptr_t) pglob-gl_pathv[oldcount],
+  qsort ((void *) pglob-gl_pathv[oldcount],



You can remove the cast entirely, right?
  


So you agreed in an earlier message.  I've now removed all typecasts to
and from void * which are declared unnecessary by C89.

-   free ((__ptr_t) pglob-gl_pathv[pglob-gl_offs + i]);
-  free ((__ptr_t) pglob-gl_pathv);
+   free ((void *) pglob-gl_pathv[pglob-gl_offs + i]);
+  free ((void *) pglob-gl_pathv);



Similarly, these casts aren't needed.

-  free ((__ptr_t) array[--i]);
+  free ((void *) array[--i]);

Nor these.

  

- free ((__ptr_t) array[--i]);
+ free ((void *) array[--i]);



Nor this one.

  

+   p = mempcpy ((void *) new-name, name, len);



Nor this one.

  

- free ((__ptr_t) names-name);
+ free ((void *) names-name);



Nor this.
  


Removed, removed, removed, removed, and removed, per the above.

-  return (((flags  GLOB_ALTDIRFUNC)
-? (*pglob-gl_stat) (fullname, st)
-: __stat64 (fullname, st64)) == 0);
+  return ((flags  GLOB_ALTDIRFUNC)
+   ? (*pglob-gl_stat) (fullname, st) == 0  S_ISDIR (st.st_mode)
+   : __stat64 (fullname, st64) == 0  S_ISDIR (st64.st_mode));



As long as you're reparenthesizing you might as well get rid of
the unnecessary ones around (flags  GLOB_ALTDIRFUNC).
  


Are you sure?  You asked me to restore similar parens around bit-ands
back at several other locations despite other work that changed the
lines, in an earlier email.  Not that I disagree now.  I actually prefer
the version without the unnecessary parens around the  bit-and.  I just
think we should be consistent.

+   new-name = malloc (len + 1
+   + ((flags  GLOB_MARK)  isdir));



This line is 80 columns; should probably shrink it to 78, e.g., via.

  new-name =
malloc (...);
  


Done.

glob.c is looking pretty good now.  I gotta run now, but I'll look at
glob.h later today I hope.
  


Thanks.  I'm not attaching a patch - I'll include a complete one
shortly, after I process your next two emails.

Cheers,

Derek



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [bug-gnulib] New GNULIB glob module?

2005-05-17 Thread Derek Price
Paul Eggert wrote:

Now for commentary on glob.h.

Derek Price [EMAIL PROTECTED] writes:

  

--- ../glibc-2.3.5/posix/glob.h   2004-09-16 20:55:15.0 -0400
+++ lib/glob_.h   2005-05-13 12:21:39.0 -0400
@@ -19,29 +19,48 @@
 #ifndef  _GLOB_H
 #define  _GLOB_H 1
 
-#include sys/cdefs.h
+#ifdef _LIBC
+# include sys/cdefs.h
+#else
+# include sys/types.h
+# include stddef.h
+# undef __size_t
+# define __size_t size_t
+#endif



Why do we need to include sys/types.h here?  All we need is size_t,
right?  And stddef.h gives us that.
  


If I don't, I get the following error:

In file included from glob.c:23:
glob.h:107: error: syntax error before struct
In file included from /usr/include/errno.h:36,
 from glob.c:25:
/usr/include/bits/errno.h:38: error: syntax error before extern

Hrm.  Tracing this a little farther, it is only features.h, or even
the sys/cdefs.h, that glob_.h was originally including, and not
sys/types.h, which is needed to avoid the above error.  features.h
appears to define __USE_GNU (which the glob_.h file uses) when
_GNU_SOURCE is defined, but a #define __USE_GNU prior to the include of
stddef.h isn't sufficient to do the trick.  Have you seen anything
like this before?  I can't really tell the difference between
sys/cdefs.h and features.h with a simple test since they each appear
to include the other.  I'm personally inclined to leave the #include
sys/types.h since it is the standard header and it seems to fix
things, but perhaps you can give me more information?

+/* Some system libraries erroneously define these.  */
+#undef   GLOB_ERR
...



Which system libraries are these?  Perhaps a comment?
  


I don't know.  I copied and pasted this comment and the #undef block
from the glob.c file.  It was previously placed just prior to the
#include of glob.h.  This looked the better place for it since I
assumed that we wouldn't want applications using the GNULIB glob module
to issue lots of redefinition warnings.

+# define getopt __GLOB_ID (getopt)



Surely this line is spurious and can be removed.
  


Done.

-#if !defined __USE_FILE_OFFSET64 || __GNUC__  2
+#if !defined _LIBC || !defined __USE_FILE_OFFSET64 || __GNUC__  2



Can't we remove at least the || __GNUC__  2 here?  glibc assumes
recent versions of GCC.
  


I'll take your word for it.  I've also followed through to remove the
following block:

#if __USE_FILE_OFFSET64  __GNUC__  2
# define glob glob64
# define globfree globfree64
#endif

And replaced this block:

# ifndef __size_t
#  if defined __GNUC__  __GNUC__ = 2
typedef __SIZE_TYPE__ __size_t;
#   ifdef __USE_XOPEN
typedef __SIZE_TYPE__ size_t;
#   endif
#  else
#   include stddef.h
#   ifndef __size_t
#define __size_t size_t
#   endif
#  endif
# else

with this block:

# ifndef __size_t
typedef __SIZE_TYPE__ __size_t;
#  ifdef __USE_XOPEN
typedef __SIZE_TYPE__ size_t;
#  endif
# else

 extern void __REDIRECT_NTH (globfree, (glob_t *__pglob), globfree64);
 #endif
-
 #ifdef __USE_LARGEFILE64
 extern int glob64 (__const char *__restrict __pattern, int __flags,
 int (*__errfunc) (__const char *, int),



Let's omit this change; it's a different matter.
  


Done.

Still withholding my patch.  I have one more email to process.

Regards,

Derek



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [bug-gnulib] New GNULIB glob module?

2005-05-17 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Paul Eggert wrote:

Derek Price [EMAIL PROTECTED] writes:

Are you sure? You asked me to restore similar parens around bit-ands
back at several other locations despite other work that changed the
lines, in an earlier email. Not that I disagree now. I actually prefer
the version without the unnecessary parens around the bit-and. I just
think we should be consistent.


It's a minor point, but expressions like (a  b  c) are assumed to
be confusing, as they depend on obscure precedence rules, whereas
expressions like (a  b ? c : d) are not confusing in the same way:
there's only one way to parse them, even if you have forgotten the
precedence.


Okay, parens removed.  Delaying new patch until I've processed the rest
of your emails.

Cheers,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCii0TLD1OTBfyMaQRAgE0AKCMyzvr5P31kyXB2aDTDdUSOTp6HQCg2+dm
CjcxyJKKkqFEyexvpoMajtE=
=h/Cn
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: history and val-tags locks.

2005-05-17 Thread Derek Price
Patch actually attached this time.

Cheers,

Derek


Derek Price wrote:

I've implemented this as an option to server  pserver.  Installing as a
global option would have create problems in multiroot mode anyhow.

Preliminary patch against 1.11.x attached.  The final version will go
into feature - I'm not advocating putting this in stable, but this is
what I have now and I thought I would request a review.  This patch also
finally disables the sourcing of the ~/.cvsrc file for the server
commands as an added protection against a user setting the path to the
config file.

2005-05-17  Derek Price  [EMAIL PROTECTED]

* configure.in: Add --enable-config-override.
* main.c (main): Don't source .cvsrc in server mode.  Remove
obsolete comment.
* parseinfo.c (ConfigPath): New global.
(parse_config): Open ConfigPath when provided.
* server.c (server): Parse -c option.
* sanity.sh (server_usage): New static global.
(sever): Add tests of ConfigPath and .cvsrc.
  

I've been thinking about this more, and I'm starting to feel that as an
option to server/pserver/etc, this really isn't so insecure.  In
general, an admin will be able to and probably does restrict the
arguments to the server  pserver commands, and a user with shell access
to the server could run a hacked CVS against a repo or even alter a repo
directly anyhow, so the argument about security is mostly moot.

The only exception would be where the admin only used a setuid CVS
executable to restrict repo access to a specific CVS executable.  I'm
not sure how common this is however, as it also disables the ability to
use UNIX uids  gids for finer control over read  write access.

Regards,

Derek
  

Index: configure.in
===
RCS file: /cvs/ccvs/configure.in,v
retrieving revision 1.176.2.60
diff -u -p -r1.176.2.60 configure.in
--- configure.in18 Apr 2005 17:46:13 -  1.176.2.60
+++ configure.in17 May 2005 16:06:53 -
@@ -965,9 +965,32 @@ dnl end --enable-rootcommit
 dnl
 
 
+dnl
+dnl begin --enable-config-override
+dnl
+
+AC_ARG_ENABLE(
+  [config-override],
+  AC_HELP_STRING(
+[--enable-config-override],
+[Cause the CVS server commands to allow the config file to be specified
+ on the command line.  (enabled by default)]), ,
+  [enable_config_override=yes])
+
+if test x$enable_config_override = xyes; then
+  AC_DEFINE(ALLOW_CONFIG_OVERRIDE, 1,
+[Define this to allow the path to CVS's config file to be set on the
+ command line.])
+fi
+
+dnl
+dnl end --enable-config-override
+dnl
+
+
 
 dnl
-dnl end --enable-*
+dnl end --enables
 dnl
 
 
Index: src/main.c
===
RCS file: /cvs/ccvs/src/main.c,v
retrieving revision 1.172.4.14
diff -u -p -r1.172.4.14 main.c
--- src/main.c  9 Mar 2005 19:47:15 -   1.172.4.14
+++ src/main.c  17 May 2005 16:06:53 -
@@ -478,6 +478,17 @@ main (argc, argv)
use_cvsrc = 0;
 }
 
+#ifdef SERVER_SUPPORT
+/* Don't try and read a .cvsrc file if we are a server.  */
+if (optind  argc
+(!strcmp (argv[optind], pserver)
+# ifdef HAVE_KERBEROS
+   || !strcmp (argv[optind], kserver)
+# endif /* HAVE_KERBEROS */
+   || !strcmp (argv[optind], server)))
+   use_cvsrc = 0;
+#endif /* SERVER_SUPPORT */
+
 /*
  * Scan cvsrc file for global options.
  */
@@ -693,10 +704,7 @@ distribution kit for a complete list of 
if (strcmp (cvs_cmd_name, pserver) == 0)
{
/* The reason that --allow-root is not a command option
-  is mainly the comment in server() about how argc,argv
-  might be from .cvsrc.  I'm not sure about that, and
-  I'm not sure it is only true of command options, but
-  it seems easier to make it a global option.  */
+  is mainly that it seems easier to make it a global option.  */
 
/* Gets username and password from client, authenticates, then
   switches to run as that user and sends an ACK back to the
Index: src/parseinfo.c
===
RCS file: /cvs/ccvs/src/parseinfo.c,v
retrieving revision 1.37.4.8
diff -u -p -r1.37.4.8 parseinfo.c
--- src/parseinfo.c 16 Mar 2005 22:00:44 -  1.37.4.8
+++ src/parseinfo.c 17 May 2005 16:06:53 -
@@ -17,6 +17,9 @@
 #include history.h
 
 extern char *logHistory;
+#ifdef ALLOW_CONFIG_OVERRIDE
+char *ConfigPath;
+#endif
 
 /*
  * Parse the INFOFILE file for the specified REPOSITORY.  Invoke CALLPROC for
@@ -252,22 +255,24 @@ parse_config (cvsroot)
return 0;
 parsed = 1;
 
-infopath = xmalloc (strlen (cvsroot)
-   + sizeof (CVSROOTADM_CONFIG)
-   + sizeof (CVSROOTADM)
-   + 10);
-if (infopath == NULL)
+#ifdef ALLOW_CONFIG_OVERRIDE
+if (ConfigPath)
+   infopath = ConfigPath

Re: history and val-tags locks.

2005-05-17 Thread Derek Price
Derek Price wrote:

Derek Price wrote:

  

I see your point.  What about `cvs server'?  I can see both setups being
useful...  an admin who allowed users access to the CVS repository would
probably prefer not to allow the config file to be specified whereas an
admin who restriced the command that SSH users could run to a particular
shell script that provided the -c option wouldn't mind...  perhaps it
should be a compile time option, with the default to disallow it.




On further consideration, if we are going to consider a configurable
config path with other CVS modes a security risk, then using it with
pserver has to be considered a security risk too.  There is nothing
stopping a creative user with shell access to a machine from using
pserver mode to access their repository.

I might argue that any administrator worried that much about security
should be disabling shell access to the machine anyhow, which would deal
with any insecurity resulting from a configurable config path, but I
don't feel so strongly about it that I wouldn't happily install it as a
compile-time option that defaults to off.
  



I've implemented this as an option to server  pserver.  Installing as a
global option would have create problems in multiroot mode anyhow.

Preliminary patch against 1.11.x attached.  The final version will go
into feature - I'm not advocating putting this in stable, but this is
what I have now and I thought I would request a review.  This patch also
finally disables the sourcing of the ~/.cvsrc file for the server
commands as an added protection against a user setting the path to the
config file.

2005-05-17  Derek Price  [EMAIL PROTECTED]

* configure.in: Add --enable-config-override.
* main.c (main): Don't source .cvsrc in server mode.  Remove
obsolete comment.
* parseinfo.c (ConfigPath): New global.
(parse_config): Open ConfigPath when provided.
* server.c (server): Parse -c option.
* sanity.sh (server_usage): New static global.
(sever): Add tests of ConfigPath and .cvsrc.
  

I've been thinking about this more, and I'm starting to feel that as an
option to server/pserver/etc, this really isn't so insecure.  In
general, an admin will be able to and probably does restrict the
arguments to the server  pserver commands, and a user with shell access
to the server could run a hacked CVS against a repo or even alter a repo
directly anyhow, so the argument about security is mostly moot.

The only exception would be where the admin only used a setuid CVS
executable to restrict repo access to a specific CVS executable.  I'm
not sure how common this is however, as it also disables the ability to
use UNIX uids  gids for finer control over read  write access.

Regards,

Derek



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [bug-gnulib] New GNULIB glob module?

2005-05-17 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Paul Eggert wrote:

First, already we have something bogus: that __BEGIN_DECLS. It must
be protected by #ifdef _LIBC, since random C environments don't have
it. Similarly for __END_DECLS.


Done.

The simplest fix would be to do something like this:

#if defined _LIBC || HAVE_SYS_CDEFS_H
# include sys/cdefs.h
#endif

with the appropriate change to glob.m4.


Actually, this change doesn't appear to be necessary once I protect the
__BEGIN_DECLS and __END_DECLS stuff.

I've removed the #include of sys/types.h.

But let's step back a second. Why are we worried about building
gnulib glob.c under glibc? It will never happen, right? So perhaps
we needn't worry about this problem at all.


Won't it?  I thought the idea was that when you and I settled on
something that looked good I would attempt to send it back to the libc
folks so that the files wouldn't need to be maintained separately.  So
far, our work contains at the least some cleanup, a bug fix, and an
efficiency improvement that should be useful in libc.

With that in mind, how about if we simply remove those #undef's? If
the problem recurs we can put them back in again.


Done.

Patch still delayed until I'm done with my email.

Regards,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCijnMLD1OTBfyMaQRAklUAKDo25YXS7Hk5kqlYe1AzXICeBBLfwCfahXg
oD3soIvk5Shqw50Mfm4dgRY=
=/2W5
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: Feature Branch Windows Build Broken - New GNULIB glob module

2005-05-17 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Conrad T. Pino wrote:

I saw you're involved with Paul Eggert on a New GNULIB module topic
and assumed we had done another GNULib import which has often broken
the Windows build.


Well, basically.  I created the glob module myself and added it to CVS
and Paul has been reviewing it and I've been correcting it in ways to
make it compatible with GNULIB  GLIBC.

I have my nose buried in another project. My patch is a blind guess
since I didn't look at the UNIX build to see what is going on there.
Your comments lead me to believe I made a lucky guess using glob_.h
and compiling glob.c in the libcvs build.


I can't comment on how lucky you were, but you did arrive at the correct
solution.  :)

I'm willing to commit the Windows build and windows-NT/pwd.? files.
What's your preference on who sends glob_.h patch to GNULib team?


I'll do it.  It should slide into my ongoing discussion with Paul about
this new module easily enough.

+#ifndef __restrict
+# define __restrict
+#endif


This is not correct.  It should be

#ifndef __restrict
# define __restrict restrict
#endif

If the restrict keyword is not supported by MSVC, then in
windows-NT/config.h.in.in, restrict should be defined to some
variation of __restrict, __restrict__, _Restrict, or empty.

The rest of your patch looks fine.

Regards,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCijCdLD1OTBfyMaQRAiT0AJ9Ddc7GePXgTuDhFl4WwVBRLebLfQCfViZR
Z5bC5MkdHep6RyAa8dR9dxE=
=c50w
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: NEWS file needs update?

2005-05-12 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jim Hyslop wrote:

 According to this message,
http://lists.gnu.org/archive/html/info-cvs/2004-10/msg00252.html, the
Protocol error: uncounted data discarded error was scheduled to be
fixed in 1.11.18, but there is no mention of that error in the NEWS file.

 Is this simply an oversight in the NEWS file?


I believe so.  Usually, obscure, minor, and non-user visible changes get
lumped into the Misc bug and documentation fixes.

Cheers,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCg8M9LD1OTBfyMaQRAg2uAJsFTiICQ4BFtWK17DP7KSA2JQjTtwCglLvo
Hf3ATi4gxI6TG1dSdrxvdyQ=
=mNFx
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [bug-gnulib] New GNULIB glob module?

2005-05-11 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Karl Berry wrote:

 Subject: [bug-gnulib] New GNULIB glob module?

Would it be possible to simply use the libc code as-is? I guess I mean,
with whatever changes are needed sent back to libc.

So much stuff in gnulib is 95% the same as libc. It doesn't seem good.


Well, like I said, a bunch of the cruft I cut out could be removed
because it was much simpler to depend on other GNULIB modules.  The
alternative would have been to add a bunch of tests to detect the things
that were being switched on, and I expect would have been much more
complicated since those problems have already been solved in the GNULIB
modules the file now references and I would have had to test the new
tests...

To have libc use the same code, it would be best if they imported the
GNULIB modules my new glob depends on and then reimported my glob
files.  We might have to find a slightly better compromise on the header
file since I'm not sure that all the assumptions I made there that are
valid with GNULIB would be valid at run time for other programs
expecting only glibc.

(Glancing back at the header file now, it looks like I did a few things
that should be undone/fixed anyhow.  I reviewed my changes to glob.c
more thoroughly, but I disabled a few things in glob.h like the 64 bit
file offsets, intending to revisit the issue later.  I don't know all
the issues involved there...  what's __REDIRECT_NTH and why does it
break in my compiler?  I was hoping someone else might be able to deal
with that more quickly than I, but most of the rest of my changes should
be valid and useful as/in the port to GNULIB...)

Regards,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCgoiULD1OTBfyMaQRApY+AJ9VsOAvoa3endmyHCxT1ai/+Nch4ACfWAye
yXShaWGtcwczl045kRTY7G4=
=Wf8s
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [bug-gnulib] New GNULIB glob module?

2005-05-11 Thread Derek Price
Most of this looks good, but one quick question as I get to this:  I
assume from the following that I can expect _LIBC to be defined iff the
file is being compiled as part of glibc?  I wasn't sure...

Cheers,

Derek


Paul Eggert wrote:

-#ifdef _LIBC
-# include alloca.h
-# undef strdup
-# define strdup(str) __strdup (str)
-# define sysconf(id) __sysconf (id)
-# define closedir(dir) __closedir (dir)
-# define opendir(name) __opendir (name)
-# define readdir(str) __readdir64 (str)
-# define getpwnam_r(name, bufp, buf, len, res) \
-   __getpwnam_r (name, bufp, buf, len, res)
-# ifndef __stat64
-#  define __stat64(fname, buf) __xstat64 (_STAT_VER, fname, buf)
-# endif
-# define HAVE_STAT64 1
-#endif



Please leave this sort of code in, so that the source code can be
identical in libc.

  

+#include mempcpy.h
+#include stat-macros.h
+#include strdup.h



These includes need to be protected by #ifndef _LIBC.
  




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [bug-gnulib] Re: getopt and Solaris 10

2005-05-10 Thread Derek Price
Paul Eggert wrote:

Derek Price [EMAIL PROTECTED] writes:


  

+ myargv[[0]] = conftest;
+ myargv[[1]] = -+;



This doesn't null-terminate myargv.

But I still don't get why the change is needed.  It sounds like you're
assuming Solaris 11 getopt might get fixed?  


Yes, I suppose so, or a later patch release of Solaris 10.  Or some
other system that decides to ship a getopt.h with a getopt_long(),
getopt_clip(), and a GNU compatible getopt(), however unlikely that may
sound now.

But even in that case,
the current code will work, right, since it will use GNU getopt?  So
this is just an optimization for the hypothetical case if Solaris 11
getopt gets fixed?  


Basically.  I was feeling guilty about not detecting the bug, but
detecting a feature of the system and assuming the bug.  This goes
against the whole Autoconf test design philosophy, I thought.  It's
almost as bad as using `uname -a |sed' to detect the version number and
using that to decide against the system getopt(), really.

The new test detects the actual bug.

In that case perhaps we should wait for Solaris 11
and test it before installing this patch, as it's more likely to cause
a bug than to fix one.
  


What sort of bug are you worried about?

Regards,

Derek



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [bug-gnulib] Re: getopt and Solaris 10

2005-05-10 Thread Derek Price
Paul Eggert wrote:

Derek Price [EMAIL PROTECTED] writes:


  

+ myargv[[0]] = conftest;
+ myargv[[1]] = -+;



This doesn't null-terminate myargv.
  


Okay, looking at that in C89 now, but just out of curiosity, if argv
needs to be NULL terminated, what's the point of argc?

Revised patch attached.  I restored a comment I probably shouldn't have
cut as well.

2005-05-10  Derek Price  [EMAIL PROTECTED]

* m4/getopt.m4: Check for Solaris 10 bug, not decl, when possible.


Regards,

Derek
Index: m4/getopt.m4
===
RCS file: /cvsroot/gnulib/gnulib/m4/getopt.m4,v
retrieving revision 1.9
diff -u -p -r1.9 getopt.m4
--- m4/getopt.m46 May 2005 01:04:20 -   1.9
+++ m4/getopt.m410 May 2005 13:56:05 -
@@ -39,8 +39,26 @@ AC_DEFUN([gl_GETOPT],
 dnl Solaris 10 getopt doesn't handle `+' as a leading character in an
 dnl option string (as of 2005-05-05).
 if test -z $GETOPT_H; then
-  AC_CHECK_DECL([getopt_clip], [GETOPT_H=getopt.h], [],
-   [#include getopt.h])
+  AC_CACHE_CHECK([for working GNU getopt function], gl_cv_func_gnu_getopt,
+  [AC_RUN_IFELSE(
+[AC_LANG_PROGRAM([#include getopt.h],[
+ char *myargv[[3]];
+ myargv[[0]] = conftest;
+ myargv[[1]] = -+;
+ myargv[[2]] = NULL;
+ return '?' != getopt (2, myargv, +a);
+])],
+gl_cv_func_gnu_getopt=yes,
+gl_cv_func_gnu_getopt=no,
+[dnl cross compiling - pessimistically guess based on decls
+ dnl Solaris 10 getopt doesn't handle `+' as a leading character in an
+ dnl option string (as of 2005-05-05).
+ AC_CHECK_DECL([getopt_clip],
+ [gl_cv_func_gnu_getopt=no], [gl_cv_func_gnu_getopt=yes],
+[#include getopt.h])])])
+  if test $gl_cv_func_gnu_getopt = no; then
+   GETOPT_H=getopt.h
+  fi
 fi
 
 if test -n $GETOPT_H; then
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: [bug-gnulib] Re: getopt and Solaris 10

2005-05-10 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matthias Kurz wrote:

I'm running out of time. I have to quit. Thanks very much for your effords.
When there is something to test, i'll still try to help.


No problem.  Thanks for your help, Matthias.

Regards,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCgL7qLD1OTBfyMaQRAgNTAJ4yFV0txiOeuKI9/459BArLy7iVSACfYZhj
oP6Fu8IWbqICpJRFhSP376o=
=LDtS
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: lockinfo

2005-05-10 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Mark D. Baushke wrote:

 I honestly don't know if it is a good idea to
 introduce this patch to feature in this way at
 this time.

 What do the other maintainers think of this kind
 of extension?


I don't have a strong opinion either way.  Some users might find it
useful to have read ACLs made available this way.  Me, I prefer to
offload any ACL decisions on the file system since it is almost
certainly more secure.

As long as I don't have to do the work, though, and without thinking
deeply about your discussion about whether soft or hard failures are
better, I have no objections to this patch.

Cheers,

Derek

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCgMRDLD1OTBfyMaQRAs1XAJ9Pu3LSUAoKAPaF67L8oiKlIfBuugCfXay/
t2xW87sMgKYXgcbk4bW4PdI=
=D8vS
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [bug-gnulib] Re: getopt and Solaris 10

2005-05-10 Thread Derek Price
Paul Eggert wrote:

Derek Price [EMAIL PROTECTED] writes:

  

Revised patch attached.



Thanks; I installed the following slightly-different patch.
  



Works for me.  Thanks Paul.

Derek



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [bug-gnulib] Re: getopt and Solaris 10

2005-05-10 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Karl Berry wrote:

 GNU getopt tries to do too much when it reorders the commandline and
 therefor needs the + as a workaround.

I don't suppose it matters at this point, but I fail to see the
connection here. You can tell GNU getopt to REQUIRE_ORDER instead of
PERMUTE without using +, either directly or setting POSIXLY_CORRECT in
various ways.


I'd rather not control a function I'm calling by messing with
environment variables, especially those that may have other side effects.

 See the __ordering enum in getopt_int.h, for example.
(Seems like you probably already know this, so maybe it's unsuitable
somehow, if so, sorry for the noise.)


It doesn't look to me like there is an easy way to set this from a
caller of getopt().

Also, I don't agree that it is doing too much to have PERMUTE be the
default for GNU. It is very useful for most programs. cvs has
exceptional command-line parsing needs.


True.

Cheers,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCgV4aLD1OTBfyMaQRAtYPAJ9q5KLtCt4T7JwYHNWSLqgPMKe2sgCg4D9I
OIkpN56K4vKZXgSvo0tFmJM=
=iNeT
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [bug-gnulib] Re: getopt and Solaris 10

2005-05-09 Thread Derek Price
Matthias Kurz wrote:

On Thu, May 05, 2005, Paul Eggert wrote:

  

Derek Price [EMAIL PROTECTED] writes:



I prefer door #2.  Trivial patch attached:
  

Thanks, but I'd rather use AC_CHECK_DECL, so I installed this instead,
into both coreutils and gnulib.  Does it work?

2005-05-05  Paul Eggert  [EMAIL PROTECTED]

  * lib/getopt.m4 (gl_GETOPT): Check for Solaris 10 getopt, and
  avoid needless checks.



Yes, this also works for me.
  


Okay, one more revision, to actually check if the -+ registers as an
option or not.  This fits the autoconf paradigm of testing for the bug,
even if it is using AC_TRY_RUN.  This way, if Sun fixes the problem in a
later Solaris release, we shouldn't need to change anything.

When cross-compiling, I fall back on looking for the odd Solaris decl to
decide whether to use the GNULIB version of getopt or not.  If we wanted
to be really pessimistic, we could always use the GNULIB getopt when
cross-compiling, but I thought this could wait at least until we get a
report of similar behavior from some system other than Solaris 10.

Matthias, would you mind testing this version out?  If you could send me
your config.log when you are done building, that would be helpful as well.

2005-05-09  Derek Price  [EMAIL PROTECTED]

* m4/getopt.m4: Check for Solaris 10 bug, not decl, when possible.

Cheers,

Derek
Index: m4/getopt.m4
===
RCS file: /cvs/ccvs/m4/getopt.m4,v
retrieving revision 1.7
diff -u -p -r1.7 getopt.m4
--- m4/getopt.m46 May 2005 15:50:05 -   1.7
+++ m4/getopt.m49 May 2005 14:47:15 -
@@ -36,11 +36,26 @@ AC_DEFUN([gl_GETOPT],
   AC_CHECK_DECL([optreset], [GETOPT_H=getopt.h], [], [#include getopt.h])
 fi
 
-dnl Solaris 10 getopt doesn't handle `+' as a leading character in an
-dnl option string (as of 2005-05-05).
 if test -z $GETOPT_H; then
-  AC_CHECK_DECL([getopt_clip], [GETOPT_H=getopt.h], [],
-   [#include getopt.h])
+  AC_CACHE_CHECK([for working GNU getopt function], gl_cv_func_gnu_getopt,
+  [AC_RUN_IFELSE(
+[AC_LANG_PROGRAM([#include getopt.h],[
+ char *myargv[[2]];
+ myargv[[0]] = conftest;
+ myargv[[1]] = -+;
+ return '?' != getopt (2, myargv, +a);
+])],
+gl_cv_func_gnu_getopt=yes,
+gl_cv_func_gnu_getopt=no,
+[dnl cross compiling - pessimistically guess based on decls
+ dnl Solaris 10 getopt doesn't handle `+' as a leading character in an
+ dnl option string (as of 2005-05-05).
+ AC_CHECK_DECL([getopt_clip],
+ [gl_cv_func_gnu_getopt=no], [gl_cv_func_gnu_getopt=yes],
+[#include getopt.h])])])
+  if test gl_cv_func_gnu_getopt = no; then
+   GETOPT_H=getopt.h
+  fi
 fi
 
 if test -n $GETOPT_H; then
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: [bug-gnulib] Re: getopt and Solaris 10

2005-05-09 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matthias Kurz wrote:

I do not think that this is a Solaris _bug_.


- From the point of view of the GNULIB getopt.m4 tests, if it doesn't
behave like GNU getopt, that is a bug.  :)

I'd bet that every system that does not use GNU getopt will suffer from
this problem. I don't know how many of them have a getopt.h, which
triggers the problem.


Well, yes, in a sense, but the tests in m4/getopt.m4 had already
eliminated all systems which don't declare a getopt_long() in favor of
the included getopt.c file from GNULIB, assuming that if getopt_long()
was declared then we could expect GNU getopt() semantics as well. 
getopt_long() is a GNU extension and not part of any standard that I
know of.

Unfortunately, in the sense that it broke the existing GNULIB getopt.m4
tests, the Solaris folks decided they liked the getopt_long() function
and imported it, without updating their getopt() to match, thereby
breaking the assumption getopt.m4 had been making thus far.

Matthias, would you mind testing this version out? If you could send me
your config.log when you are done building, that would be helpful as well.


Yes, i'm going to test this asap.


Thanks.

Cheers,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCf49SLD1OTBfyMaQRAucQAKCZ1j8EtPQaa+1KqZSx3VGKGYvy2wCfeu4t
fgBXhyz5M7ewzUcAydnxtv0=
=oNlX
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [bug-gnulib] Re: getopt and Solaris 10

2005-05-09 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Matthias Kurz wrote:

Hi.

One more clarification. Maybe one or the other missed my last comments
on https://ccvs.cvshome.org/issues/show_bug.cgi?id=248. It was me,
who introduced the '+' myth.


Well, it is not a myth.  I studied the test program and output you sent
me, and Solaris does, indeed, treat the initial + as an option rather
than a request for getopt() semantics.

I analysed the problem wrong in the
beginning. It is not exactly the + that makes the problem, but the
fact, that the Solaris getopt refuses to accept a zero value on optind.
When optind==0, the Solaris getopt returns -1 immediately, leaving
optind==0. W


I did read this correctly in your report.  If anyone else sees a need
for an actual test for correct optind=0 behavior, then they are welcome
to write one, but I decided the point was moot at the moment since
detecting the + bug, just as valid as a means of selecting the GNU
getopt() over the system one, was sufficient to avoid encountering any
other bugs in the Solaris getopt().

Cheers,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCf5lsLD1OTBfyMaQRAiT1AJ9SOugiUFKjruvZOCi23ko9wLqGLwCg2S/R
DTImJNqzmHIonAUGmka+CNg=
=OKfo
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [bug-gnulib] Re: getopt and Solaris 10

2005-05-09 Thread Derek Price
Regardless, since using an optind = 0 is not specified as supported by
POSIX, whereas optind = 1 is, and since using optind = 1 in place of
optind = 0 in CVS would avoid this problem on all platforms and with all
versions of getopt (supporting optind = 0 provides no additional
functionality that I know of), I don't think this is properly considered
a Solaris bug, but a CVS bug.

At least, it would be a CVS bug if we didn't have to use the GNU getopt
on Solaris due to the + problem anyhow.

Cheers,

Derek


Derek Price wrote:

 Matthias Kurz wrote:

 Hi.

 One more clarification. Maybe one or the other missed my last comments
 on https://ccvs.cvshome.org/issues/show_bug.cgi?id=248. It was me,
 who introduced the '+' myth.



 Well, it is not a myth.  I studied the test program and output you sent
 me, and Solaris does, indeed, treat the initial + as an option rather
 than a request for getopt() semantics.

 I analysed the problem wrong in the
 beginning. It is not exactly the + that makes the problem, but the
 fact, that the Solaris getopt refuses to accept a zero value on optind.
 When optind==0, the Solaris getopt returns -1 immediately, leaving
 optind==0. W



 I did read this correctly in your report.  If anyone else sees a need
 for an actual test for correct optind=0 behavior, then they are welcome
 to write one, but I decided the point was moot at the moment since
 detecting the + bug, just as valid as a means of selecting the GNU
 getopt() over the system one, was sufficient to avoid encountering any
 other bugs in the Solaris getopt().

 Cheers,

 Derek


___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs





___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [bug-gnulib] Re: getopt and Solaris 10

2005-05-09 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

...I know you already agreed...  ...I just thought this was interesting...

In fact, Solaris 10 is the one actually sticking to the letter of the
POSIX spec here, not that I think that assuming argv[0] should not be
processed is going to hurt the GNU version:

The variable /optind/ is the index of the next element of the
/argv/[] vector to be processed. It is initialised to 1 by the system,

...

If, when /getopt()/ is called:

|
 /argv/[optind]is a null pointer
*/argv/[optind]is not the character -
 /argv/[optind]points to the string -
|

 /getopt/() returns -1 without changing /optind./


Cheers,

Derek


Derek Price wrote:

Regardless, since using an optind = 0 is not specified as supported by
POSIX, whereas optind = 1 is, and since using optind = 1 in place of
optind = 0 in CVS would avoid this problem on all platforms and with all
versions of getopt (supporting optind = 0 provides no additional
functionality that I know of), I don't think this is properly considered
a Solaris bug, but a CVS bug.

At least, it would be a CVS bug if we didn't have to use the GNU getopt
on Solaris due to the + problem anyhow.

Cheers,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCf55NLD1OTBfyMaQRApD/AKDG91RXkmD1GjNyqLJmzFjQq9vCBwCfbjTw
HHeRY0WAPlT67fsFFn0PNuE=
=oFUI
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [bug-gnulib] Re: getopt and Solaris 10

2005-05-09 Thread Derek Price
Derek Price wrote:

2005-05-05  Paul Eggert  [EMAIL PROTECTED]

 * lib/getopt.m4 (gl_GETOPT): Check for Solaris 10 getopt, and
 avoid needless checks.   
  

Yes, this also works for me.



Okay, one more revision, to actually check if the -+ registers as an
option or not.  This fits the autoconf paradigm of testing for the bug,
even if it is using AC_TRY_RUN.  This way, if Sun fixes the problem in a
later Solaris release, we shouldn't need to change anything.

When cross-compiling, I fall back on looking for the odd Solaris decl to
decide whether to use the GNULIB version of getopt or not.  If we wanted
to be really pessimistic, we could always use the GNULIB getopt when
cross-compiling, but I thought this could wait at least until we get a
report of similar behavior from some system other than Solaris 10.

Matthias, would you mind testing this version out?  If you could send me
your config.log when you are done building, that would be helpful as well.

2005-05-09  Derek Price  [EMAIL PROTECTED]

* m4/getopt.m4: Check for Solaris 10 bug, not decl, when possible.
  


I've attached almost the same patch as before, except that I remembered
to put `$' in front of all my variables this time.  Matthias confirmed
that ithis new patch does the right thing on Solaris 10.

This patch is against Paul's last commit.

Cheers,

Derek
Index: m4/getopt.m4
===
RCS file: /cvs/ccvs/m4/getopt.m4,v
retrieving revision 1.7
diff -u -p -r1.7 getopt.m4
--- m4/getopt.m46 May 2005 15:50:05 -   1.7
+++ m4/getopt.m49 May 2005 20:20:00 -
@@ -36,11 +36,26 @@ AC_DEFUN([gl_GETOPT],
   AC_CHECK_DECL([optreset], [GETOPT_H=getopt.h], [], [#include getopt.h])
 fi
 
-dnl Solaris 10 getopt doesn't handle `+' as a leading character in an
-dnl option string (as of 2005-05-05).
 if test -z $GETOPT_H; then
-  AC_CHECK_DECL([getopt_clip], [GETOPT_H=getopt.h], [],
-   [#include getopt.h])
+  AC_CACHE_CHECK([for working GNU getopt function], gl_cv_func_gnu_getopt,
+  [AC_RUN_IFELSE(
+[AC_LANG_PROGRAM([#include getopt.h],[
+ char *myargv[[2]];
+ myargv[[0]] = conftest;
+ myargv[[1]] = -+;
+ return '?' != getopt (2, myargv, +a);
+])],
+gl_cv_func_gnu_getopt=yes,
+gl_cv_func_gnu_getopt=no,
+[dnl cross compiling - pessimistically guess based on decls
+ dnl Solaris 10 getopt doesn't handle `+' as a leading character in an
+ dnl option string (as of 2005-05-05).
+ AC_CHECK_DECL([getopt_clip],
+ [gl_cv_func_gnu_getopt=no], [gl_cv_func_gnu_getopt=yes],
+[#include getopt.h])])])
+  if test $gl_cv_func_gnu_getopt = no; then
+   GETOPT_H=getopt.h
+  fi
 fi
 
 if test -n $GETOPT_H; then
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: history and val-tags locks.

2005-05-06 Thread Derek Price
Mark D. Baushke wrote:

 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.


Okay, it's still short documentation, but I've attached a patch against
stable which implements the HistoryLogPath and HistorySearchPath config
options.  I don't think I want to try and import glob() on stable, so
HistorySearchPath currently only handles fnmatch() metacharacters in the
final element of the path name.

Any consenses on whether importing this to stable is justified to deal
with the log rotation issue?

Cheers,

Derek


Index: src/client.c
===
RCS file: /cvs/ccvs/src/client.c,v
retrieving revision 1.318.4.27
diff -u -p -r1.318.4.27 client.c
--- src/client.c17 Mar 2005 15:39:09 -  1.318.4.27
+++ src/client.c6 May 2005 18:26:21 -
@@ -4903,7 +4903,7 @@ start_rsh_server (root, to_server, from_
 /* Send an argument STRING.  */
 void
 send_arg (string)
-char *string;
+const char *string;
 {
 char buf[1];
 char *p = string;
@@ -5953,8 +5953,8 @@ client_notify (repository, update_dir, f
  */
 void
 option_with_arg (option, arg)
-char *option;
-char *arg;
+const char *option;
+const char *arg;
 {
 if (arg == NULL)
return;
Index: src/client.h
===
RCS file: /cvs/ccvs/src/client.h,v
retrieving revision 1.39.6.2
diff -u -p -r1.39.6.2 client.h
--- src/client.h20 Mar 2004 18:14:56 -  1.39.6.2
+++ src/client.h6 May 2005 18:26:21 -
@@ -83,7 +83,7 @@ void read_from_server PROTO((char *buf, 
 
 /* Internal functions that handle client communication to server, etc.  */
 int supported_request PROTO ((char *));
-void option_with_arg PROTO((char *option, char *arg));
+void option_with_arg PROTO((const char *option, const char *arg));
 
 /* Get the responses and then close the connection.  */
 extern int get_responses_and_close PROTO((void));
@@ -119,7 +119,7 @@ send_files PROTO((int argc, char **argv,
 
 /* Send an argument to the remote server.  */
 void
-send_arg PROTO((char *string));
+send_arg PROTO((const char *string));
 
 /* Send a string of single-char options to the remote server, one by one.  */
 void
Index: src/cvs.h
===
RCS file: /cvs/ccvs/src/cvs.h,v
retrieving revision 1.235.4.31
diff -u -p -r1.235.4.31 cvs.h
--- src/cvs.h   2 May 2005 17:06:56 -   1.235.4.31
+++ src/cvs.h   6 May 2005 18:26:21 -
@@ -931,3 +931,6 @@ extern void cvs_outerr PROTO ((const cha
 extern void cvs_flusherr PROTO ((void));
 extern void cvs_flushout PROTO ((void));
 extern void cvs_output_tagged PROTO ((const char *, const char *));
+
+/* From find_names.c.  */
+List *find_files PROTO ((const char *dir, const char *pat));
Index: src/find_names.c
===
RCS file: /cvs/ccvs/src/find_names.c,v
retrieving revision 1.30.6.2
diff -u -p -r1.30.6.2 find_names.c
--- src/find_names.c31 Jan 2005 22:15:11 -  1.30.6.2
+++ src/find_names.c6 May 2005 18:26:21 -
@@ -22,10 +22,11 @@
  */
 
 #include cvs.h
+#include assert.h
 
 static int find_dirs PROTO((char *dir, List * list, int checkadm,
List *entries));
-static int find_rcs PROTO((char *dir, List * list));
+static int find_rcs PROTO((const char *dir, List * list));
 static int add_subdir_proc PROTO((Node *, void *));
 static int register_subdir_proc PROTO((Node *, void *));
 
@@ -249,55 +250,134 @@ Find_Directories (repository, which, ent
 return (dirlist);
 }
 
-/*
- * Finds all the ,v files in the argument directory, and adds them to the
- * files list.  Returns 0 for success and non-zero if the argument directory
- * cannot be opened, in which case errno is set to indicate the error.
- * In the error case LIST is left in some reasonable state (unchanged, or
- * containing the files which were found before the error occurred).
+
+
+/* Finds all the files matching PAT in the directory DIR, and adds them to a
+ * new List.  Returns the new List for success and NULL if the argument
+ * directory cannot be opened, in which case errno is set to indicate the
+ * error.
+ *
+ * NOTES
+ *   If GNULIB ever gets a glob module, this function could be replaced with
+ *   the glob function and a few tweaks to callers.
+ *
+ *   Currently, users may come to rely on the way history uses the unsorted
+ *   list this function returns since I believe that the default inode ordering
+ *   should be roughly the order of file creation.  It might be a good idea to
+ *   discourage this in favor of a specific sort order since we may otherwise
+ *   get complaints like, I copied my repository to 

Re: history and val-tags locks.

2005-05-05 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

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)?  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.

Regards,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCek0qLD1OTBfyMaQRAqLcAKDJv4b9hnU8xk8I4OhXmJplvW/ieQCg69KW
EfAvZGNU13K1FtFM6n4kb0I=
=xyNy
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


getopt and Solaris 10

2005-05-05 Thread Derek Price
Apparently Solaris 10 includes a getopt.h and appears to be GNU getopt
by all the tests in getopt.m4.  Unfortunately, it doesn't support + as
the first character of the option string.  The original report is here:
https://ccvs.cvshome.org/issues/show_bug.cgi?id=248.

I'm assuming that GNULIB is still avoiding AC_TRY_RUN since it doesn't
work when cross-compiling?  I've asked Matthias (the bug reporter, CC'd)
if he could find some difference between Solaris 10's getopt and GNU
getopt that could be detected at compile time.  The alternative would be
always using the GNULIB getopt when installed.

Regards,

Derek



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [bug-gnulib] getopt and Solaris 10

2005-05-05 Thread Derek Price
James Youngman wrote:

On Thu, May 05, 2005 at 01:34:24PM -0400, Derek Price wrote:

  

Apparently Solaris 10 includes a getopt.h and appears to be GNU getopt
by all the tests in getopt.m4.  Unfortunately, it doesn't support + as
the first character of the option string.  



But surely we would now regard that usage as obsolete now?  It's been
replaced by -- hasn't it?
  


CVS still makes use of it bacause we can parse a line like:

   cvs -fq -d /cvsroot checkout -P -d newname module

and getopt with a + as the first character of the option string kindly
stops when it reaches the CVS command checkout.  We can then dump
everything up to optind:

argc -= optind;
argv += optind;
if (argc  1)
usage (usg);

and reuse getopt, with a new option string, to parse the arguments to
checkout.  I don't think users would appreciate having to preceded all
CVS commands with a -- argument.

   cvs -fq -d /cvsroot -- checkout -P -d newname module
   cvs -fq -d /cvsroot -- update

It's a bit redundant.

Regards,

Derek




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: getopt and Solaris 10

2005-05-05 Thread Derek Price
Derek Price wrote:

Apparently Solaris 10 includes a getopt.h and appears to be GNU getopt
by all the tests in getopt.m4.  Unfortunately, it doesn't support + as
the first character of the option string.  The original report is here:
https://ccvs.cvshome.org/issues/show_bug.cgi?id=248.
  


Matthias pointed me at the man page for Solaris 10's getopt_long:
http://docs.sun.com/app/docs/doc/816-5168/6mbb3hr99?l=ena=view#indexterm-493.

Based on that man page, I see two alternatives:

1. Always use getopt_long() in CVS since the Solaris 10 version supports
+ as the start of the option string even though its getopt() does not.
2. Check for the getopt_clip() function, which should be unique to
Solaris, and use the GNULIB getopt.c when it is found.

I prefer door #2.  Trivial patch attached:

2005-05-05  Derek Price  [EMAIL PROTECTED]

* m4/getopt.m4 (gl_GETOPT): Use GNULIB getopt on Solaris 10.

Matthias, would you mind verifying that this patch fixes CVS on your
Solaris 10?

Regards,

Derek
Index: m4/getopt.m4
===
RCS file: /cvsroot/gnulib/gnulib/m4/getopt.m4,v
retrieving revision 1.8
diff -u -p -r1.8 getopt.m4
--- m4/getopt.m423 Jan 2005 08:06:57 -  1.8
+++ m4/getopt.m45 May 2005 18:51:09 -
@@ -32,6 +32,10 @@ AC_DEFUN([gl_GETOPT],
 dnl and (as of 2004-10-15) mishandles optional option-arguments.
 AC_CHECK_DECL([optreset], [GETOPT_H=getopt.h], [], [#include getopt.h])
 
+dnl Solaris 10 getopt doesn't handle `+' as a leading character in an
+dnl option string (as of 2005-05-05).
+AC_CHECK_FUNCS([getopt_clip], [GETOPT_H=getopt.h])
+
 if test -n $GETOPT_H; then
   gl_GETOPT_SUBSTITUTE
 fi
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: [bug-gnulib] Re: getopt and Solaris 10

2005-05-05 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Derek Price wrote:

2005-05-05 Derek Price [EMAIL PROTECTED]

 * m4/getopt.m4 (gl_GETOPT): Use GNULIB getopt on Solaris 10.


Matthias reports that this patch does The Right Thing (tm) on Solaris
10: https://ccvs.cvshome.org/issues/show_bug.cgi?id=248.

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCeoCwLD1OTBfyMaQRAhMHAJ0R2a//oSHXiFaNMjMHTbBP2nGq4gCghqjB
plPDozD5LBe5LAyjHA46zQ8=
=ChvA
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: PAM session support documentation

2005-05-04 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Brian Murphy wrote:

 Hi Guys,
 I would like to commit the attached patch. It documents in
 the example files the necessary session lines in the PAM
 configuration file.

 I/we seem to have missed this when the session support was
 added. The manual has the necessary additions.

 OK with you?


Yeah, sure.  You're mostly in charge where the PAM support is concerned,
I think, as long as it remains possible to disable it and doesn't break
backwards compatibility anywhere, in the protocol, API, or otherwise.

Regards,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCd5WyLD1OTBfyMaQRAkAwAJsHEU9IcFOl2rcZuawE/L1GdX7KvACg2iYR
j2vDG6yUzw/6aFC+/LquZrI=
=lO7j
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: MacOS X 10.3.7 Build Problem After CVS CheckOut

2005-05-04 Thread Derek Price
This is a well-known problem.  The workaround is to use a build 
directory.  i.e.:

   cvs co ccvs
   cd ccvs
   mkdir build
   cd build
   ../configure
   make
I never thought it was worth coming up with a more automated solution, 
but you're welcome to try.  I would argue against changing the name of 
the executable though, and I'm not sure what else is workable.

Cheers,
Derek
Conrad T. Pino wrote:
I'm seeing the same build problem on both stable  feature:
Titanium:~/projects/cvs-1.12.12 conradtpino$ make
make  all-recursive
Making all in lib
make  all-am
make[3]: Nothing to be done for `all-am'.
Making all in zlib
make[2]: Nothing to be done for `all'.
Making all in diff
make[2]: Nothing to be done for `all'.
Making all in src
rm: cvs: is a directory
make[2]: *** [cvs] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
Titanium:~/projects/cvs-1.12.12 conradtpino$
The problem occurs because the MacOS file system appears to
be case insensitive with respect to file names i.e. both of
the following do the same thing:
ls CVS
ls cvs
I'm seeing the error for the first time because I checked
out with a revision tag instead of downloading a tar ball.
I can work around the problem by using export instead of
checkout command.
The question becomes:  Is it worthwhile fixing the build
to deal with case insensitive UNIX file systems?
Conrad

___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs
 


___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: MacOS X 10.3.7 Build Problem After CVS CheckOut

2005-05-04 Thread Derek Price
Incidentally, I thought this was documented somewhere other than the 
email list, but I don't see it.  I've added a note to INSTALL on stable 
and INSTALL-CVSon feature.

Cheers,
Derek
Derek Price wrote:
This is a well-known problem.  The workaround is to use a build 
directory.  i.e.:

   cvs co ccvs
   cd ccvs
   mkdir build
   cd build
   ../configure
   make
I never thought it was worth coming up with a more automated solution, 
but you're welcome to try.  I would argue against changing the name of 
the executable though, and I'm not sure what else is workable.

Cheers,
Derek
Conrad T. Pino wrote:
I'm seeing the same build problem on both stable  feature:
Titanium:~/projects/cvs-1.12.12 conradtpino$ make
make  all-recursive
Making all in lib
make  all-am
make[3]: Nothing to be done for `all-am'.
Making all in zlib
make[2]: Nothing to be done for `all'.
Making all in diff
make[2]: Nothing to be done for `all'.
Making all in src
rm: cvs: is a directory
make[2]: *** [cvs] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
Titanium:~/projects/cvs-1.12.12 conradtpino$
The problem occurs because the MacOS file system appears to
be case insensitive with respect to file names i.e. both of
the following do the same thing:
ls CVS
ls cvs
I'm seeing the error for the first time because I checked
out with a revision tag instead of downloading a tar ball.
I can work around the problem by using export instead of
checkout command.
The question becomes:  Is it worthwhile fixing the build
to deal with case insensitive UNIX file systems?
Conrad

___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs
 



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: MacOS X 10.3.7 Build Problem After CVS CheckOut

2005-05-04 Thread Derek Price
Conrad T. Pino wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Derek,
 

From: Derek Price [mailto:[EMAIL PROTECTED]
I never thought it was worth coming up with a more automated solution, 
but you're welcome to try.  I would argue against changing the name of 
the executable though, and I'm not sure what else is workable.
   

The configure script could test for the existence of a directory named
src/cvs and if true then execute a mkdir build command if build is
not already created.
That being said, how many shell variations need to be tested before we
commit such a fix assuming there are no objections?
 

What good would it be to make the build directory if the user didn't 
know to cd there before building?  Also, once the src dir is configured, 
the build dir will refuse to be configured.  The user would have to 
`make distclean; cd build; ../configure' afterwards anyhow.  There might 
be a way to bootstrap that, but why not try something simpler, like just 
printing a nice, easy-to-spot-and-read warning message?

The test would be something like
$srcdir = $builddir  $fs_case_insensitive  test -z $exe_ext
I'm sure those var names are not correct, but you would have to make 
sure the latter test ran after all the tests that set the correct flags.

Cheers,
Derek
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [PATCH] pagealign_alloc: don't loop endlessly

2005-05-04 Thread Derek Price
Does the attached, more general, patch do the trick for you?

I think the problem is deeper - error() really needs a way to bypass the
memory allocation of the buffer routines, but this should work around
the problem for now.

Cheers,

Derek


Thorsten Glaser wrote:

Hello!

Please apply the following patch. It prevents GNU CVS 1.12.12
from looping endlessly and dumping core due to lack of stack
(recursion depth) when /dev/zero cannot be found, for example
in a chroot(2) environment.

I have copyright assignments for CVS filed with the FSF.

//mirabile



Index: src/error.c
===
RCS file: /cvs/ccvs/src/error.c,v
retrieving revision 1.42
diff -u -p -r1.42 error.c
--- src/error.c 18 Mar 2005 16:41:24 -  1.42
+++ src/error.c 4 May 2005 14:14:29 -
@@ -119,6 +119,10 @@ error (int status, int errnum, const cha
 char statcmdbuf[32];
 char *cmdbuf;
 char *emptybuf = ;
+static bool in_error = false;
+
+if (in_error) goto recursion_error;
+in_error = true;

 /* Initialize these to avoid a lot of special case error handling.  */
 buf = statbuf;
@@ -173,6 +177,9 @@ error (int status, int errnum, const cha
 /* Restore errno per our charter.  */
 errno = save_errno;

+/* Reset our recursion lock.  */
+in_error = false;
+
 /* Done.  */
 return;

@@ -195,6 +202,21 @@ memerror:
 #endif /* HAVE_SYSLOG_H */

 exit (EXIT_FAILURE);
+
+recursion_error:
+#if HAVE_SYSLOG_H
+syslog (LOG_DAEMON | LOG_EMERG,
+   error (%d, %d) called recursively.  Message was:,
+   status, errnum);
+
+va_start (args, message);
+vsyslog (LOG_DAEMON | LOG_EMERG, message, args);
+va_end (args);
+
+syslog (LOG_DAEMON | LOG_EMERG, Aborting.);
+#endif /* HAVE_SYSLOG_H */
+
+exit (EXIT_FAILURE);
 }




signature.asc
Description: OpenPGP digital signature
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: [PATCH] pagealign_alloc: don't loop endlessly

2005-05-04 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thorsten Glaser wrote:

Derek Price dixit:

Yes, that's why I was suggesting to print the error message to stderr
so at least the client gets an idea about what happened and can slap
the server administrator. CVS does this for quite some occasions, for
example no space available in the server's temporary directory.

Could you point me at the code that does this?


Not out of the blue, I had to check. But it happens frequently
when e.g. the OpenBSD anoncvs servers are overloaded.


And where is the code that does this?

How much good would sending the message to stderr really do? This
problem can only occur on the server, where sending to stderr, at best,
can only be reported to the client as an unrecognized protocol response,
if reported at all, once the network buffers are disabled (the network
buffer code is what is calling pagealign_alloc() here).


No, it's actually displayed by the client (with my first diff).


I'm fairly certain it shouldn't be consistently displayed this way.  It
might ocassionally appear in the context of Unrecognized response from
server: `some message on stderr'.

Can you provide me with a test case that reproduces this behavior?

Cheers,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCeQxpLD1OTBfyMaQRAgrVAJ9ZeNqHtuhH3dTjgZjAMLLpvr53qQCdFOWC
2Ccd7RA08CDF3ceEpfpmFtc=
=bics
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [PATCH] pagealign_alloc: don't loop endlessly

2005-05-04 Thread Derek Price
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Thorsten Glaser wrote:

Derek Price dixit:

Does the attached, more general, patch do the trick for you?


It does, but I do not get a diagnostic, neither on stderr
(CVS output) nor in syslog on server or client. This is
probably because the CVS server is running in a chroot.

I suggest a diagnostics on stderr, plus - in this case - the
actual solution is to add a device node into the chroot, and
from a recursion error nobody would get the idea.


My patch logs the actual error message to the syslog too (via the
vsyslog() call), but if your chroot is preventing access to the syslog,
that wouldn't help anyhow.

Cheers,

Derek
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCeN8FLD1OTBfyMaQRAiHfAKDcLW4aGk+Ek9JHVeTSVbUqERJiqQCguXyo
Xcovfa0jOnzz+159lb0oJNw=
=RGRl
-END PGP SIGNATURE-




___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


Re: [PATCH] pagealign_alloc: don't loop endlessly

2005-05-04 Thread Derek Price
I've attached a revised version of my earlier patch that preserves more
information and avoids problems when the exit handlers call error()
after error() calls exit().

Regards,

Derek
Index: src/ChangeLog
===
RCS file: /cvs/ccvs/src/ChangeLog,v
retrieving revision 1.3186
diff -u -p -r1.3186 ChangeLog
--- src/ChangeLog   4 May 2005 02:48:16 -   1.3186
+++ src/ChangeLog   4 May 2005 20:14:40 -
@@ -1,3 +1,7 @@
+2005-05-04  Derek Price  [EMAIL PROTECTED]
+
+   * error.c (error): Avoid recursion and syslog the problem.
+
 2005-05-03  Derek Price  [EMAIL PROTECTED]

* tag.c (is_in_val_tags): Remove unnecessary existance checking for the
Index: src/error.c
===
RCS file: /cvs/ccvs/src/error.c,v
retrieving revision 1.42
diff -u -p -r1.42 error.c
--- src/error.c 18 Mar 2005 16:41:24 -  1.42
+++ src/error.c 4 May 2005 20:14:40 -
@@ -120,16 +120,26 @@ error (int status, int errnum, const cha
 char *cmdbuf;
 char *emptybuf = ;

+static const char *last_message = NULL;
+static va_list last_args;
+static int last_status;
+static int last_errnum;
+
+if (last_message) goto recursion_error;
+last_message = message;
+va_start (args, message);
+last_args = args;
+last_status = status;
+last_errnum = errnum;
+
 /* Initialize these to avoid a lot of special case error handling.  */
 buf = statbuf;
 buf2 = statbuf2;
 cmdbuf = emptybuf;

 /* Expand the message the user passed us.  */
-va_start (args, message);
 length = sizeof (statbuf);
 buf = vasnprintf (statbuf, length, message, args);
-va_end (args);
 if (!buf) goto memerror;

 /* Expand the cvs commmand name to cmd or [cmd aborted].
@@ -161,6 +171,12 @@ error (int status, int errnum, const cha
 /* Send the final message to the client or log it.  */
 cvs_outerr (buf2, length);

+/* Reset our recursion lock.  This needs to be done before the call to
+ * exit() to allow the exit handlers to make calls to error().
+ */
+last_message = NULL;
+va_end (args);
+
 /* Done, if we're exiting.  */
 if (status)
exit (EXIT_FAILURE);
@@ -194,6 +210,37 @@ memerror:
 syslog (LOG_DAEMON | LOG_EMERG, Memory exhausted.  Aborting.);
 #endif /* HAVE_SYSLOG_H */

+goto sidestep_done;
+
+recursion_error:
+#if HAVE_SYSLOG_H
+/* Syslog the problem since recursion probably means that we encountered an
+ * error while attempting to send the last error message to the client.
+ */
+
+syslog (LOG_DAEMON | LOG_EMERG,
+   error (%d, %d) called recursively.  Original message was:,
+   last_status, last_errnum);
+vsyslog (LOG_DAEMON | LOG_EMERG, last_message, last_args);
+
+
+syslog (LOG_DAEMON | LOG_EMERG,
+error (%d, %d) called recursively.  Second message was:,
+   status, errnum);
+va_start (args, message);
+vsyslog (LOG_DAEMON | LOG_EMERG, message, args);
+va_end (args);
+
+syslog (LOG_DAEMON | LOG_EMERG, Aborting.);
+#endif /* HAVE_SYSLOG_H */
+
+sidestep_done:
+/* Reset our recursion lock.  This needs to be done before the call to
+ * exit() to allow the exit handlers to make calls to error().
+ */
+last_message = NULL;
+va_end (last_args);
+
 exit (EXIT_FAILURE);
 }



signature.asc
Description: OpenPGP digital signature
___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs

Re: history and val-tags locks.

2005-05-02 Thread Derek Price
Derek Price wrote:

HistoryFile=$CVSROOT/CVSROOT/logs/history/%Y%m%d



So, if the history file path were configurable and run through
strftime(), I can either (1) cache the history file name the first time
it is determined and gaurantee that all the operations from the same
server execution are logged to the same history file, or (2),
re-strftime() each time history_write() is called, and guarantee that
given two consecutive lines of any single history file, there was no CVS
operation that occurred in the span of time between the lines.

I'm leaning towards (1) since it is a little easier to code, only
requires one set of system calls per CVS server run, and CVS always
sorts history lines before displaying them anyhow.  Anyone have any
different opinions?

Regards,

Derek



___
Bug-cvs mailing list
Bug-cvs@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-cvs


  1   2   3   >