Re: Kaffe 1.0.5 install problem on Windows 98

1999-11-24 Thread Frohwalt Egerer


"Rakic Sasa & Snezana" <[EMAIL PROTECTED]> writes:

> Hi there,
> 
> I have try to compile Kaffe 1.0.5   (from kaffe-1.0.5.zip) with
> Cygwin b20 on the Windows 98 but the folowing problems are found:
> 
> In the ./configure I have to change all occurs of:
> 
> CONFIG_SHELL-/bin/sh
> 
> with
> 
> CONFIG_SHELL-sh
> 
> After 15 minutes of running 'sh ./configure' it has finished with attached
> file errors. 

Hmm just a wild guess - I'm not an cygwin expert: Have you used
cygwin's mount command to mount cygwin's .../bin directory to /bin?
Just adding the bin directory to the path might not be enough. 

Froh

-- 
Frohwalt Egerer  ICONSULT Tandogan Egerer Gbr
Memelstraße 38   91052 Erlangen
Mobil: 0179/4993965  Tel: 09131/90470  
Fax: 09131/904777Email: [EMAIL PROTECTED]



[PATCH] JDK 1.2 style native functions for java.io.File

1999-11-12 Thread Frohwalt Egerer



First things first: Before I start annonying people here, is there
some place to send patches to besides the mailing list?



 native functions for java.io.File implemented.

I've implemented most of the missing functions for java.io.File,
leaving deleteOnExit() untouched since I've got no idea where to look
for a 'on exit' hook in Kaffe. The patch is small, so I'll append it
below.

Having implemented createNewFile I could fix a race condition in
createTempFile which created a new random name but not a File as
documented by Sun.

I had a look at Mauve to check for results, but I couldn't find a
testlet for java.io.File in the snapshot of Mauve (1999-11-06).



 a lot of unix functions get called directly

kaffe/libraries/clib/io/File.c calls a lot of unix functions directly
without going through the jsyscall interface. These syscalls are
access, opendir, readdir and closedir. Implementing the missing
functions I've gone the same way not using jsyscall for utime and
chmod.  I should have added these to jsyscall but I don't dare to
touch threading related things, yet. (And I don't want to touch the
Win32 and BeOs versions.)



 What the heck ?!?

Implementing java.io.File.setReadOnly() it occured to me it is a one
way function. In Java there doesn't seem to be a way to remove
ReadOnly status again. Strange stuff, such things make you wonder what
they smoked before designing that API ...


Froh



It's ridiculous for such a small patch, but let there be legalese:
The following stuff may be included in all versions (commercial and
open souce) of Kaffe.  I don't mind any copyright on this. No warranty
attached, if it breaks you keep the pieces.

diff -b -x *CVS* -u -r original/kaffe/libraries/clib/io/File.c 
kaffe/libraries/clib/io/File.c
--- original/kaffe/libraries/clib/io/File.c Tue Sep 14 01:01:29 1999
+++ kaffe/libraries/clib/io/File.c  Fri Nov 12 00:35:25 1999
@@ -17,6 +17,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "defs.h"
 #include "files.h"
 #include "../../../include/system.h"
@@ -326,3 +327,74 @@
return (0);
}
 }
+
+
+jboolean
+java_io_File_createNewFile0(struct Hjava_io_File* this)
+{
+   int fd;
+   int rc;
+   char str[MAXPATHLEN];
+
+   stringJava2CBuf(unhand(this)->path, str, sizeof(str));
+
+   rc = KOPEN(str, O_EXCL|O_WRONLY|O_CREAT, 0666, &fd);
+   if (rc != 0)
+   return 0;
+
+   
+   rc = KCLOSE(fd);
+   if (rc != 0)
+   SignalError("java.io.IOException", SYS_ERROR(rc));
+
+   return 1;
+}
+
+jboolean
+java_io_File_setLastModified0(struct Hjava_io_File* this, jlong thetime)
+{
+   char path[MAXPATHLEN];
+   int r;
+   struct utimbuf ub;
+
+   stringJava2CBuf(unhand(this)->path, path, sizeof(path));
+
+
+   ub.actime = (time_t)(thetime / 1000);
+   ub.modtime = ub.actime;
+
+   /* XXX make part of jsyscall interface !? */
+   r = utime(path, &ub);
+   return (r < 0 ? 0 : 1);
+}
+
+jboolean
+java_io_File_setReadOnly0(struct Hjava_io_File* this)
+{
+   struct stat buf;
+   char str[MAXPATHLEN];
+   int r;
+
+   stringJava2CBuf(unhand(this)->path, str, sizeof(str));
+
+   r = KSTAT(str, &buf);
+
+   if (r<0)
+   return 0;
+
+   /* XXX make part of jsyscall interface !? */
+   r = chmod(str, buf.st_mode & ~(S_IWOTH|S_IWGRP|S_IWUSR));
+   return (r < 0 ? 0 : 1);
+}
+
+
+/***
+
+Missing in jsyscall:
+access, opendir, readdir, closedir, utime, chmod
+
+
+Missing in configure:
+Check for utimes/utime/utime.h
+
+***/
Binary files original/kaffe/libraries/javalib/Klasses.jar and 
kaffe/libraries/javalib/Klasses.jar differ
diff -b -x *CVS* -u -r original/kaffe/libraries/javalib/java/io/File.java 
kaffe/libraries/javalib/java/io/File.java
--- original/kaffe/libraries/javalib/java/io/File.java  Tue Oct 12 21:05:45 1999
+++ kaffe/libraries/javalib/java/io/File.java   Fri Nov 12 00:38:51 1999
@@ -106,14 +106,14 @@
dir = new File(System.getProperties().getProperty(
"java.io.tmpdir"));
}
+
while (true) {
File f = new File(dir, prefix
+ Integer.toHexString(
random.nextInt(0x10)).toUpperCase() + suffix);
-   if (!f.exists()) {
+   if (f.createNewFile())
return f;
}
-   }
 }
 
 public boolean delete() {
@@ -168,7 +168,10 @@
 for (int i = 0; i < len; i++) {
 String str = tok.nextToken();
 if (str.equals("..")) {
+if (j>0)
 j--;
+} else if (str.equals(".")) {
+// do nothing.
 }
 else {
 array[j] = str;
@@ -339,4 +342,77 @@
 public String toString() {
return path;
 }
+
+
+//JDK1.2 updates ...
+
+public java.net.URL toURL()
+ 

"pre"-patch for JDK 1.2 compatible java.io.File, lots of notes on Kaffe

1999-11-11 Thread Frohwalt Egerer





These are some observations I made while trying to kick kaffe until
it runs with my company's software which uses a lot of JDK1.2 stuff.

Current state: I'm implementing as much of JDK1.2's java.io.* as I
need for kaffe, I can't promise a full implementation. The next step
will be JDBC 2.


 paintBorder collision with Swing 1.1.1fcs

com/iconsult/tools/engine/Controller.java:17:20:17:29: Warning: Method "void 
paintBorder(java.awt.Graphics $1);" in class "javax/swing/JComponent" does not 
override the corresponding method with default access in class "java/awt/Container".

Swing's paintBorder collides with paintBorder from Kaffe's AWT
implementation and jikes complains about it. This can be taken care of
by:

~~/src/kaffe/libraries/javalib$ perl -p -i.bak -e 's|paintBorder|kaffePaintBorder|g' 
**/*.java

(**/*.java is zsh's notion for all .java files in all subdirectories)



 java.io.File.getCanonicalPath()

Should getCanonicalPath be native and use some kind of getpwd? If we got
a soft link in our getAbsolutePath() a native implementation would return
a drastically different path than this Java implementation.

Later note: kaffe's getCanonicalPath() does not remove '.' from the path:

import java.io.*;

public class file4
{
public static void main(String[] args)
throws Exception
{
System.err.println(new File("././././.").getCanonicalPath());
}
}

[froh] ~/src/kcrash$ /usr/local/pkg/jdk1.2pre-v2/jre/bin/java -cp . file4
/home/froh/src/kcrash
[froh] ~/src/kcrash$ kaffe file4 
/home/froh/src/kcrash/././././.
***fixed in my version of kaffe's File.java, patch below***

Access to ../..//../../../boom fails with an index out
of bounds exception.
***fixed in my version of kaffe's File.java, patch below***


= java.io.File (and probably all other files)

This file contains tab characters, but seems to have a convetion of a tab
every 4 spaces. Wouldn't it be better to have these expanded to spaces?



 kaffe.net.DefaultURLStreamHandlerFactory.java

The JDK 1.2 doc states:

3.If the previous step fails to find a protocol handler, then the
constructor tries to load the class named:

sun.net.www.protocol..Handler

If this class does not exist, or if the class exists but it is not a
subclass of URLStreamHandler, then a MalformedURLException is thrown.


Should the DefaultURLStreamHandlerFactory try
sun.net... besides com.transvirtual.net... and
kaffe.net...? This probably is a borderline case, but I'm
just reading Sun's API docs. Doing so might slow things down
a little little bit. 



 another buffer overflow ...

FileOutputStream has the same buffer overflow that I recently reported
for FileInputStream, a range change for the parameters is missing.
Interestingly this doesn't really crash kaffe. When a too large
size is given and write marches out of mapped memory the write
returns with an java.io.IOException("Bad address").
By the way, writing to /dev/zero behaves differently, no wonder
since /dev/zero's write should be a no-op ...

import java.io.*;

public class crash3
{
public static void main(String[] args)
throws Exception
{
FileOutputStream fos = new FileOutputStream("veryfunny");
fos.write(new byte[0], 0, 10*1024*1024);
System.err.println("You won't see this.");
}
}


 File URLs are FTP URLs !?!?!

While kaffe's File URLs behave as *I'd* expect (just accessing local
files) this seems to be wrong: Have a look at
http://www.ncsa.uiuc.edu/demoweb/url-primer.html, that's where Sun's
JDK1.2 API doc sends you for information on URLs. Try yourself
what the document states, use Netscape to open
file://ftp.cdrom.com/

Writing a little test program I verified that Sun's implementation 
tries to do the same.

import java.io.*;
import java.net.*;

public class file
{
public static void main(String[] args)
throws Exception
{
InputStream is = new BufferedInputStream(new 
URL("file://ftp.cdrom.com/README").openStream());
int i;
while ((i = is.read())>=0)
System.out.print((char)i);
}
}

It tries to activate a ftp client, but never really succeeds on my
box. That might be due to my strange internet connection, though.

At least now I know how to implement java.io.File.toURL() ;-)


 At last - a little patch so my stuff doesn't complain when it gets compiled.

Note, I forgot to add a XXX FIXME comment to listRoots, there are platforms with
more than one "/" as root ... and now it's too late, but I should have put the
array in a private static variable, so listRoots doesn't create an object every
time.

THIS STUFF IS NOT TESTED. I'll do that (and implement the native
methods) this weekend, if nobody objects in me building this stuff and
send a _real_ patch afterwards.

Ah, and of course it would be ridiculous if I'd mind any copyright
things on these puny patches, so do with them whatever you want. (That
i

Bug database broken / Generating interfaces / ChangeLog suggestion

1999-11-11 Thread Frohwalt Egerer



Hello everybody,

  today I've got three things on my mind:

1. The bug database on www.kaffe.org still seems to be broken,
   browsing to www.kaffe.org and clicking on the Bug Database link in
   the navigational frame just opens another navigational bar and
   kaffe homepage in my browser.

2. Since I'm needing JDBC 2.0 I'll probably enhance Kaffe's JDBC
   support. Are there any objections in generating the needed
   interfaces by using reflection on Sun's classes? Or is that "too
   close to Sun's source" to be cleanroom. If I'm just supposed to
   read the docs only, how am I supposed to find out the values for
   static constants?

   By the way, last week I've thrown together a perl script that reads
   JavaDoc and creates interfaces/class skeletons from what it
   finds. I'll append it below in case anybody finds it useful.

3. The ChangeLog for Kaffe seems to be maintained manually. Do you
   know there's a nice Perl script which generates ChangeLog files
   from CVS' commit messages?  Have a look at it at
   http://www.red-bean.com/~kfogel/cvs2cl.shtml

Froh





And here's the skeleton generator, have fun with it.


#!/usr/bin/perl -w

#
# Parseapidoc
#
# A simple, fast hack to parse openly available Java documentation and generate
# interfaces from it. There's no warranty attached to this, if it breaks you
# keep the pieces. Use, copy and modify this as much as you like.
#
# In case Sun changes javadoc's output this script has to be changed ;-)
#

foreach $file (@ARGV)
{
undef $@;

if ($file !~ m/package-/)  # filter out package-tree etc.
{
eval
{
open(IN, "<$file") || die("Cannot open $file: $!\n");
$in =  \*IN;

$outfile = $file;
$outfile =~ s|/|.|g;
$outfile =~ s|\.html|.java|;

open (OUT, ">$outfile") || die("Cannot open $outfile for writing: $!\n");
$out = \*OUT;
#   $out = \*STDOUT;

print $out ("/* Automatically generated from $file by parseapidoc.pl 
*/\n\n");


classdecl();
fields();

print $out "}\n\n";
};
}

warn ("$@\t... propagated for $file\n") if ($@);

close(IN);
close(OUT);
}


sub classdecl()
{
while (<$in>)
{
chomp;
last if m/ START OF CLASS DATA /;
}

<$in>  || die "premature EOF";# Eat the 
<$in>  || die "premature EOF";# Eat the 

$pkg=<$in> || die "premature EOF";# Contains pack.age.foo
chomp $pkg;
$pkg = removetags($pkg);
print $out "package $pkg;\n\n";

while (<$in>)
{
last if m//;
}

<$in>|| die "premature EOF";   # Eat the 

$cls = <$in> || die "premature EOF";   # contains the declaration.
chomp $cls;
$cls = removetags($cls);
$cls =~ s/abstract interface/interface/g;
$cls =~ s/ *extends/\nextends/g;
$cls =~ s/ *implements/\nimplements/g;
print $out "$cls\n{\n";

}

# Also handles constructors and methods ...
sub fields()
{
while (<$in>)
{
chomp;
last if m/FIELD DETAIL/;
}

while (1)
{

while (<$in>)
{
last   if m//i;
return if m/END OF CLASS DATA/;
}

my $done = 0;
my $val = "";

while (!$done)
{
chomp;

$done = 1 if m||i;
$_ = removetags($_);
$val .= $_;
$_ = <$in> || die "premature EOF";
}

$val =~ s| *, *|, |g;
$val =~ s| *\( *|(|g;
$val =~ s| *throws| throws|g;

print $out "$val;\n";
}
}

sub removetags
{
my ($s) = @_;

$s =~ s/<.*?>/ /g;
$s =~ s/ / /g;
$s =~ s/ +/ /g;
$s =~ s/^ *//;
$s =~ s/ *$//;

return $s;
}



JavaCC breakage under Kaffe 1.0.5 / kaffe.org down?

1999-11-08 Thread Frohwalt Egerer



[I'm just guessing the correct mail adress for the list, since the
 welcome message says it is [EMAIL PROTECTED] - which bounces]


Hello everybody,

  trying to port some application to Kaffe I found at least two bugs
in Kaffe. The first bug are missing sanity checks in File*Stream
read/write, a Java application can pass bogus parameters to the
File*Stream and thus create a buffer overflow in the native code. I've
added an example program below to show this problem.

The other bug is the ByteToCharConverter and CharToByteConverter
holding internal state and thus not being thread safe. When two
strings are .getByteArray()'ed simultaneously, String.getBytes() uses
a CharToByteConverter which can mix up both strings. You can see this
effect when running JavaCC - or the second sample program I've added
below.

I'm currently considering to fix these bugs myself, provided nobody
else is working in these areas. What do people - and especially
Transvirtual, who market a non-GPL'ed version of Kaffe - think about
adding code from Classpath. I've downloaded Classpath yesterday night
and judging from only my first glimpse it has got a better
implementation of these converters.

By the way, I've added the bugs I mentioned to the Kaffe Bug Database
yesterday, but since that single moment the kaffe.org website seems to
be broken, links leading nowhere.

Froh




// crash1.java gets a core dump from Kaffe 1.0.5

import java.io.*;

public class crash1
{
public static void main(String[] args)
throws Exception
{
FileInputStream fis = new FileInputStream("/dev/zero");
fis.read(new byte[0], 0, 10*1024*1024);
System.err.println("We are dead by now.");
}
}



// crash2.java simulates two threads calling String.getBytes() concurrently.

import java.io.*;
import kaffe.io.*;

public class crash2
{
public static void main(String[] args)
throws Exception
{
// We do not use threads in this example, but we imagine we did.
//
//
// This is kaffe String's getBytes() routine:
//
// ByteArrayOutputStream out = new ByteArrayOutputStream( value.length);
// 
// byte[] buf = new byte[512];
// int buflen = encoding.convert( value, offset, count, buf, 0, buf.length);
// while (buflen > 0) {
// out.write(buf, 0, buflen);
// buflen = encoding.flush(buf, 0, buf.length);
// }
// 
// return (out.toByteArray());
//
//
// We now play a scenario that might happen with two threads:

char[] a = new char[700];
char[] b = new char[700];
for (int i=0; i<700; i++)
{
a[i]='a';
b[i]='b';
}

// a and b represent two String Objects A and B each 700 characters long.

// We create two threads each wanting to getBytes() on one of these Strings.

// Thread one starts and operates on a.
CharToByteConverter encoding_a = CharToByteConverter.getDefault();
byte[] buf_a = new byte[512];
ByteArrayOutputStream out_a = new ByteArrayOutputStream(a.length);
int buflen_a = encoding_a.convert(a, 0, 700, buf_a, 0, buf_a.length);

// But behold! We got some preemption, Thread two is running now ...

CharToByteConverter encoding_b = CharToByteConverter.getDefault();
byte[] buf_b = new byte[512];
ByteArrayOutputStream out_b = new ByteArrayOutputStream(b.length);
int buflen_b = encoding_b.convert(b, 0, 700, buf_b, 0, buf_b.length);

while (buflen_b > 0) {
 out_b.write(buf_b, 0, buflen_b);
 buflen_b = encoding_b.flush(buf_b, 0, buf_b.length);
}

System.err.println("B's output:");
System.err.write(out_b.toByteArray());
System.err.println("\n\n");

// B is done, Thread A resumes ...

while (buflen_a > 0) {
 out_a.write(buf_a, 0, buflen_a);
 buflen_a = encoding_a.flush(buf_a, 0, buf_a.length);
}

System.err.println("A's output:");
System.err.write(out_a.toByteArray());
System.err.println("\n\n");
}

}