[Bug classpath/26971] javax.naming.directory.BasicAttribute$BasicAttributeEnumeration is broken
--- Comment #3 from cvs-commit at developer dot classpath dot org 2006-04-03 21:20 --- Subject: Bug 26971 CVSROOT:/cvsroot/classpath Module name:classpath Branch: Changes by: Tom Tromey <[EMAIL PROTECTED]>06/04/03 21:03:49 Modified files: . : ChangeLog javax/naming/directory: BasicAttribute.java Log message: PR classpath/26971: * javax/naming/directory/BasicAttribute.java: Added missing @since. (BasicAttributeEnumeration.where): Initialize to 0. (BasicAttributeEnumeration.nextElement): Post-increment 'where'. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/ChangeLog.diff?tr1=1.7001&tr2=1.7002&r1=text&r2=text http://cvs.savannah.gnu.org/viewcvs/classpath/classpath/javax/naming/directory/BasicAttribute.java.diff?tr1=1.4&tr2=1.5&r1=text&r2=text -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26971 ___ Bug-classpath mailing list Bug-classpath@gnu.org http://lists.gnu.org/mailman/listinfo/bug-classpath
Re: RFC: Changing Class.newInstance() to add VM specific feature
Hi Jeroen, On Thu, 2006-03-30 at 13:09 +0200, Jeroen Frijters wrote: > I've added a new access modifier to IKVM. By applying the > @ikvm.lang.Internal annotation to a type or member, you can mark it as > internal to the library it resides in. Hopefully Java will provide > something similar with JSR 277, but I've decided not to wait on that. > > To support this access level with reflection, I've modified > Method/Constructor/Field (of which I include my own versions with IKVM, > so that was easy), but I also need to modify Class.newInstance(). > > Would anybody object to adding a hook for this? This looks OK and not too invasive. But I would like to see as little extensions added as possible so let me propose a hack that might prevent having to add the hook. Couldn't you override setAccessible() so that it throws an exception when you try to set it to true on an "internal" Constructor? That seems to have the same effect. Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: running pscan, rats. flawfinder and splint on classpath
Dalibor Topic wrote: functions. Some of those are a little odd, for example it is not clear to me what to do if JNI function call ThrowNew fails. rats and Good question.. I think the only reasonable answer is "proceed with the knowledge that an exception was posted, but perhaps not the one you asked for (e.g., OutOfMemoryError or somesuch)". -Archie __ Archie Cobbs *CTO, Awarix* http://www.awarix.com
Re: running pscan, rats. flawfinder and splint on classpath
On Mon, 2006-04-03 at 15:14 -0500, Archie Cobbs wrote: > Dalibor Topic wrote: > > functions. Some of those are a little odd, for example it is not clear > > to me what to do if JNI function call ThrowNew fails. rats and > > Good question.. I think the only reasonable answer is "proceed with > the knowledge that an exception was posted, but perhaps not the one > you asked for (e.g., OutOfMemoryError or somesuch)". Yeah. I was just wondering if "if throw fails, check if an exception was thrown, and dump the exception to stderr before continuing/exiting" was maybe the intent of the API author, but found nothing like that in the literature. I have some trouble figuring out why one would make throw* not return void otherwise. cheers, dalibor topic
running pscan, rats. flawfinder and splint on classpath
Hi all, I've played around a bit with C vulnerability checkers today, and ran a few on them on the classpath code base, so I figured I'd tell you how to it, too. The first one I tried was pscan [1], which checks for format string vulnerabilities. I've fixed all the pscan warnings today. Running pscan is easy: In the classpath directory, run find . -name "*.[ch]" | xargs pscan there should be no output now. ;) The next one I looked at was flawfinder [2], which checks for general potential security issues. It quantifies them in classes, according to potential for mischief. 5 is the highest category, 0 the lowest. In the classpath source directory, running flawfinder . results in a lot of output about potential security problems. Next I fired up rats[3], which checks for similar problems that flawfinder covers as well. It returned similar results, too, though ordered by potentially vulnerable C function, which would make it easier to fix all the issues at once. To run rats, in the classpath source directory run rats . Finally, I ran splint[4]. Split is a static C checker. It produces massive loads of output, and has some trouble parsing gcc-specific code, which is why it breaks trying to analyze headers included from gtk, java-net, etc. It also has trouble with C++ code, so I left the qt peers out. I've ended up invoking it like this: find native/jni/classpath/ native/jni/java-io/ native/jni/java-nio/ native/jni/java-util/ native/jni/xmlj/ -name "*.[ch]" | xargs splint +posixlib -fileextensions -badflag -I include/ -I ../build-classpath/include/ -I native/jni/classpath/ -I native/fdlibm/ -I /usr/include/gtk-2.0/ -I /usr/include/pango-1.0/ -I /usr/include/glib-2.0/ -I /usr/include/cairo/ -I native/jni/gtk-peer/ -I /usr/include/freetype2/ -I native/target/Linux/ -I native/target/generic/ -D__i386__ -I /usr/include/libxml2/ -I /usr/include/ -weak I'd say that pscan is fun to use to find format issues, flawfinder & rats are both nice for finding places to audit, and splint is gcc -WAnalyzeDeeply. All the tools are pretty fast, and can analyze the code in less than a minute. A quick scan of the results shows that splint detects some type mismatch issues, and cases where we ignore the return values of functions. Some of those are a little odd, for example it is not clear to me what to do if JNI function call ThrowNew fails. rats and flawfinder mostly ruffle their noses over the use *printf class of functions without approriate protection, string manipulation functions, and similar potential issues. I'll be back at fixing the normal gcc warnings on Kaffe's code base, but if someone wants to go ahead from here with a full scale security audit of the C code, I hope this e-mail helps them get started. cheers, dalibor topic [1] http://www.striker.ottawa.on.ca/~aland/pscan/ [2] http://www.dwheeler.com/flawfinder/ [3] http://www.securesw.com/rats [4] http://splint.org
Re: File.canWrite() actually writes stuff
Hi Gary, On Thu, 2006-03-30 at 10:24 +0100, Gary Benson wrote: > I just noticed that File.canWrite() actually writes things in order to > check whether they are writable. This seems really wrong to me: just > checking something should not modify the filesystem! Does anyone mind > if I replace this? Yes please! It would be nice if we had a real test instead of the canWriteDirectory(File) hack that is in place now. Cheers, Mark signature.asc Description: This is a digitally signed message part
Re: Some GdkGraphics2D problems disappear with G_SLICE=always-malloc
Hi Stuart, Am Sonntag, den 02.04.2006, 18:08 -0400 schrieb Stuart Ballard: > Just to summarize / save anyone else from digging through all those > links, it seems the issue is that objects allocated with one API were > being freed by another (I didn't see what the allocation API was, but > the "free"s in question were g_free (incorrect) and g_object_unref > (correct). > > g_free() is a wrapper around free() which means that it happens to > work if the allocation API ends up being a wrapper around malloc() > (which is why always-malloc works around the problem). When the new, > more efficient allocator is used instead (which AIUI grabs some large > chunks of memory and manages them itself so there are lots of objects > per single malloc()ed chunk), free() fails, and so g_free() does too. > > If classpath is hitting this in the same way everyone else is, it's > not a glib bug, it's definitely a Classpath bug. Thanks for summarizing this. This helped me alot finding the problem. In my case (GdkFontPeer.c) I had to replace g_free() with pango_item_free() to make it work. Thanks! Roman -- “Improvement makes straight roads, but the crooked roads, without Improvement, are roads of Genius.” - William Blake signature.asc Description: Dies ist ein digital signierter Nachrichtenteil
