cp-tools-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Cp-tools-discuss] bug + possible fix (patch) in texidoclet: TreeNode.ja


From: Alex Lancaster
Subject: [Cp-tools-discuss] bug + possible fix (patch) in texidoclet: TreeNode.java
Date: 21 Feb 2002 01:14:26 -0800
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.1

Julian,

I found another apparent bug in texidoclet when attempting to test
texidoclet with gjdoc.  This is a strange one because using the same
doclet (texidoclet) with both Sun's javadoc and gjdoc gives different
errors, but the bug itself seems to be in texidoclet, not gjdoc.

In any case, if I run the following:

jdb -Dgnu.classpath.tools.gjdoc.LogLevel=1 -classpath 
"tmp:../tmp:/usr/lib/jdk1.3.1/lib/tools.jar:../cp-tools/texidoclet.jar" 
gnu.classpath.tools.gjdoc.Main -doclet 
gnu.classpath.tools.doclets.texinfo.Driver gnu.classpath.tools.gjdoc 
-sourcepath ../../classpath:. -d doc

[... verbose output skipped...]

Generating .texid files
TexiDoclet creates texinfo source...
Generating TexInfo index
writing file docs/packages
writing file docs/packages.etags
java.lang.reflect.InvocationTargetException: java.lang.NullPointerException
        at 
gnu.classpath.tools.doclets.texinfo.TreeNode.addTreeEntry(TreeNode.java:184)
        at 
gnu.classpath.tools.doclets.texinfo.TexiIndex.createIndex(TexiIndex.java:95)
        at 
gnu.classpath.tools.doclets.texinfo.TexiIndex.main(TexiIndex.java:184)       at 
gnu.classpath.tools.doclets.texinfo.Driver.start(Driver.java:102)
        at java.lang.reflect.Method.invoke(Native Method)
        at gnu.classpath.tools.gjdoc.Main.startDoclet(Main.java:607)
        at gnu.classpath.tools.gjdoc.Main.start(Main.java:778)
        at gnu.classpath.tools.gjdoc.Main.main(Main.java:676)

This can easily be traced to a logic problem in TreeNode.java, in
which it appears that following a test for null on a variable, the
subsequent statement is an operation on that variable.

This is the offending piece of code:

 ClassEntry ifaceEntry = 
(ClassEntry)interfaceEntries.get(implementedInterfaces[i]);
 if (ifaceEntry==null) {
     String ifaceName = implementedInterfaces[i];
     int lastPoint=ifaceName.lastIndexOf('.');
     if (lastPoint>=0) {
         String ifaceNode = Toolkit.classNameToNodeName(ifaceName); 
//"("+ifaceName.substring(0,lastPoint)+") "+ifaceName.substring(lastPoint+1);

         ifaceEntry = new ClassEntry(ifaceName, ifaceNode); // FIXME! invalid 
target node
         interfaceEntries.put(ifaceName,ifaceEntry);
     }
 }
 ifaceEntry.add(classEntry);

It looks like it's possibly intended to be inside an "else" statement,
or otherwise trapped (i.e. is it supposed to be something that is
"set" after the null check, or is it supposed to be an "alternative"
to the null check?).  If you look at the context can see why
"ifaceEntry" won't necessarily be non-null, because the (lastPoint>=0)
test may not be true...

I'm not sure what the intended behaviour should be, which is why I
didn't fix in CVS.  If it is, here's a patch that implements the
"else".  If it's correct, let me know and I'll apply it:

cvs diff -u TreeNode.java
Index: TreeNode.java
===================================================================
RCS file: 
/cvsroot/cp-tools/cp-tools/gnu/classpath/tools/doclets/texinfo/TreeNode.java,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 TreeNode.java
--- TreeNode.java       21 Oct 2001 14:06:46 -0000      1.1.1.1
+++ TreeNode.java       21 Feb 2002 08:59:35 -0000
@@ -181,7 +181,10 @@
                    interfaceEntries.put(ifaceName,ifaceEntry);
                }
            }
-           ifaceEntry.add(classEntry);
+           else { 
+               ifaceEntry.add(classEntry);
+           }
+           
        }
     }
 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]