When compiling coda 5.3.19 using GCC 3.1 under i686 Gentoo Linux, I
ran into a couple of problems with redefined default arguments to
functions in fso_cachefile.cc.  Below is a simple patch that removes
the second default argument declaration:

--- coda-5.3.19/coda-src/venus/fso_cachefile.cc Thu May 17 14:26:53 2001 
+++ coda-5.3.19-rac/coda-src/venus/fso_cachefile.cc     Mon Jun  3 00:38:07 2002 
@@ -132,7 +132,7 @@ 
 /* Must be called from within a transaction!  Assume caller has done 
    RVMLIB_REC_OBJECT() */ 
  
-void CacheFile::Create(int newlength = 0) 
+void CacheFile::Create(int newlength) 
 { 
     LOG(10, ("CacheFile::Create: %s, %d\n", name, newlength)); 
  
@@ -183,7 +183,7 @@ 
     return 0; 
 } 
  
-int CacheFile::Copy(char *destname, ino_t *ino, int recovering = 0) 
+int CacheFile::Copy(char *destname, ino_t *ino, int recovering) 
 { 
     LOG(10, ("CacheFile::Copy: from %s, %d, %d/%d, to %s\n", 
             name, inode, validdata, length, destname)); 

In addition, I also noticed a slew of warnings (mostly in
coda-src/vol) about the tactic used in struct.h to backtrack to the
base address of a structure given a pointer to a structure member.
GCC 3.1 seems to suggest the use of a pointer-to-member in this
situation.  I haven't done a whole lot of C++ in several years, and I
couldn't immediately think of a simple way to rewrite the strbase
macro in struct.h to use a pointer-to-member in a simple expression
(ie. without introducing a presumably unwanted temporary variable).
Is this compiler warning truly benign or is it something that needs
attention?  

It did not appear to me that either of these issues has been addressed
in the latest CVS sources, either.

-- 
Robert Coie <rac_at_intrigue.com>
Implementor, Apropos Ltd.