From: Alessio S. <ale...@gm...> - 2009-01-26 22:40:45
|
Hello, I stumbled upon a nasty bug: loadCompiledFunction fails on line 1020 with a ZipException when loading ABCL from a jar file with spaces in its path (on Linux). That's because the path is converted to a URL and spaces are replaced by %20's. There's code to fix that but only when the platform is Windows. Apparently executing such code (from int i = zipFileName.indexOf("%20"); onwards) outside of the if (Utilities.isPlatformWindows) { ... } block does the trick. Before committing my fix, I'd like to know if anyone is aware of other places where the same bug could occur. Bye, Ale |
From: Erik H. <eh...@gm...> - 2009-01-27 10:31:03
|
Hi! On Mon, Jan 26, 2009 at 11:40 PM, Alessio Stalla <ale...@gm...> wrote: > Hello, > > I stumbled upon a nasty bug: loadCompiledFunction fails on line 1020 > with a ZipException when loading ABCL from a jar file with spaces in > its path (on Linux). > That's because the path is converted to a URL and spaces are replaced > by %20's. There's code to fix that but only when the platform is > Windows. Apparently executing such code > (from int i = zipFileName.indexOf("%20"); onwards) outside of the if > (Utilities.isPlatformWindows) { ... } block does the trick. Before > committing my fix, I'd like to know if anyone is aware of other places > where the same bug could occur. I ran into this issue (on Windows) with an application of my own, which does basically the same trick with the JAR path. However, I think the issue should be a little bit differently: Since a URL is returned, *any* character can be encoded using the %xx syntax, not only spaces. Possibly, characters with diacritical marks even are (never tested it). So, instead of replacing %20, I propose eliminating the code which does that and introduce, around line 984 (http://trac.common-lisp.net/armedbear/browser/trunk/abcl/src/org/armedbear/lisp/Lisp.java#L984) the use of URLDecoder like this: String s = URLDecoder.decode(url.toString(), "UTF-8"); which - I think - should resolve *all* encoding issues; I *know* it does for the %20 case. This would invalidate the entire block lines 997 - 1019. What's your opinion on that resolution? Bye, Erik. |
From: Ville V. <vil...@gm...> - 2009-01-27 10:58:20
|
> So, instead of replacing %20, I propose eliminating the code which > does that and introduce, around line 984 > (http://trac.common-lisp.net/armedbear/browser/trunk/abcl/src/org/armedbear/lisp/Lisp.java#L984) > the use of URLDecoder like this: > String s = URLDecoder.decode(url.toString(), "UTF-8"); Absolutely. It's a much better solution to use URLDecoder instead of some handcrafted solution. |
From: Alessio S. <ale...@gm...> - 2009-01-27 11:25:24
|
On Tue, Jan 27, 2009 at 11:58 AM, Ville Voutilainen <vil...@gm...> wrote: >> So, instead of replacing %20, I propose eliminating the code which >> does that and introduce, around line 984 >> (http://trac.common-lisp.net/armedbear/browser/trunk/abcl/src/org/armedbear/lisp/Lisp.java#L984) >> the use of URLDecoder like this: >> String s = URLDecoder.decode(url.toString(), "UTF-8"); > > Absolutely. It's a much better solution to use URLDecoder instead of > some handcrafted solution. I agree. I didn't know URLDecoder... |
From: Erik H. <eh...@gm...> - 2009-01-27 13:14:36
|
On Tue, Jan 27, 2009 at 12:25 PM, Alessio Stalla <ale...@gm...> wrote: > On Tue, Jan 27, 2009 at 11:58 AM, Ville Voutilainen > <vil...@gm...> wrote: >>> So, instead of replacing %20, I propose eliminating the code which >>> does that and introduce, around line 984 >>> (http://trac.common-lisp.net/armedbear/browser/trunk/abcl/src/org/armedbear/lisp/Lisp.java#L984) >>> the use of URLDecoder like this: >>> String s = URLDecoder.decode(url.toString(), "UTF-8"); >> >> Absolutely. It's a much better solution to use URLDecoder instead of >> some handcrafted solution. > > I agree. I didn't know URLDecoder... Ok. Then we're all in agreement :-) If you are in a position to commit this change: be my guest. [Being at work now (and busy tonight) I won't be able to commit this today.] Bye, Erik. |
From: Alessio S. <ale...@gm...> - 2009-01-27 13:38:03
|
> Ok. Then we're all in agreement :-) > > If you are in a position to commit this change: be my guest. [Being at > work now (and busy tonight) I won't be able to commit this today.] I'm at work too, but this evening I should be able to commit it. Bye, Alessio |
From: Alessio S. <ale...@gm...> - 2009-01-27 20:25:35
|
Fixed! I tried placing abcl.jar in a directory named "è&?@ ò[]". Old abcl choked, the new ran smoothly. I guess it is a comprehensive enough test :) A. PS is there an established way to log messages (e.g. warnings, notices etc.) from ABCL? On Tue, Jan 27, 2009 at 2:37 PM, Alessio Stalla <ale...@gm...> wrote: >> Ok. Then we're all in agreement :-) >> >> If you are in a position to commit this change: be my guest. [Being at >> work now (and busy tonight) I won't be able to commit this today.] > > I'm at work too, but this evening I should be able to commit it. > > Bye, > Alessio > |