Re: [cp-patches] ensure LOCALHOST is used when localhost name is unsuable
Hi Raif,
On Tue, 2005-12-27 at 10:19 +1100, Raif S. Naffah wrote:
pls. find attached a patch to do the above. sometimes, the parameter
localhost (to the InetAddress.getAllByName(String) method) is an empty
string which causes an UnknownHostException to be thrown. the patch
ensures that if this is the case LOCALHOST is used instead.
This looks sane. I committed it as follows (removed the commented out
code, moved the trim() up so we don't do it twice and added a comment
about trim in the ChangeLog entry).
2006-01-01 Raif S. Naffah [EMAIL PROTECTED]
* java/net/InetAddress.java (getAllByName): use LOCALHOST if
localhost is null or is an empty string. Trim hostname before
lookup.
Could you add a Mauve test for this?
Cheers,
Mark
Index: java/net/InetAddress.java
===
RCS file: /cvsroot/classpath/classpath/java/net/InetAddress.java,v
retrieving revision 1.42
diff -u -r1.42 InetAddress.java
--- java/net/InetAddress.java 2 Jul 2005 20:32:39 - 1.42
+++ java/net/InetAddress.java 1 Jan 2006 13:50:15 -
@@ -649,8 +649,11 @@
InetAddress[] addresses;
+if (hostname != null)
+ hostname = hostname.trim();
+
// Default to current host if necessary
-if (hostname == null)
+if (hostname == null || hostname.equals())
{
addresses = new InetAddress[1];
addresses[0] = LOCALHOST;
signature.asc
Description: This is a digitally signed message part
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] RFC: java.net.InetAddress.toString() returns wrong address
Hi Christian, On Thu, 2005-12-29 at 19:37 +0100, Christian Thalinger wrote: While checking some FAILs in tgolem i stumbled across this common fail: FAIL: gnu.testlet.java.net.InetSocketAddress.InetSocketAddressTest: Error : test_Constructors failed - 1 No wildcard address returned (number 1) I searched a bit and i think toString() returns the wrong value. Is this correct? 2005-12-29 Christian Thalinger [EMAIL PROTECTED] * java/net/InetAddress.java (toString): Return 0.0.0.0 for null hostname. I don't think this is correct. null as hostname just means the hostname has not yet been looked up, and toString() is explicitly lazy and doesn't do lookups itself. I actually think the Mauve test is incorrect since it assumes 0.0.0.0 is always the INADDR_ANY used and that the hostName for such an address is automagically resolved. I would propose to either change the Mauve test to be less strict in checking. Or if you feel IF_ANY should always have a resolved hostname to eagerly resolve it by adding something like this to InetAddress.getInaddrAny: inaddr_any.hostName = naddr_any.getHostName(); Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] [patch] bump Qt version check to 4.1
Hi Andreas, On Sun, 2005-12-25 at 23:02 +0100, Andreas Tobler wrote: this patch lets us build classpath with Qt-4.1.0 again, released a few days ago. The problem is the reorganization of the Qt include directory which changed from include to include/module, means in our case, include/QtGui and include/QtCore. 2005-12-25 Andreas Tobler [EMAIL PROTECTED] * configure.ac (QT_CFLAGS): Check for 4.1.0 version and for QtCore to have the right include flags. ok? Yes, if the consensus is that we want only the latest 4.1 version (there were some strange drawing bugs in 4.0.x, but Sven would know better if going for 4.1 is the solution for those). P.s, merry Christmas to all! And a happy new year! Cheers, mark signature.asc Description: This is a digitally signed message part ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] [patch] fix Qt-4.1 build
Hi Andreas, On Sun, 2005-12-25 at 23:05 +0100, Andreas Tobler wrote: this patch lets us run qt based peers again. The problem is that the function we used to disable double buffering has gone in qt-4.1. It is still documented in the qt manual but marked as to be fixed for qt-4.1.1. As I understand, the doc will be fixed and not the call itself. 2005-12-25 Andreas Tobler [EMAIL PROTECTED] * native/jni/qt-peer/mainqtthread.cpp: Remove call to disable double buffering. Ability has gone in Qt-4.1.x. Ok? Looks fine to me. I am a bit surprized there is no replacement for this function. Sven, it would be good if you could approve any changes in the qt-peers. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] KerberosPrincipal - Try number two
Hi Jeff, On Mon, 2005-12-26 at 19:24 -0500, Jeff Bailey wrote: There are still several FIXMEs in the code, but I don't think any of them are barriers to adding the class to CVS. Most of them are details that will be sorted out as the rest of the implementation is done and it's possible to actually test the code. Thanks. Tom had two change requests. The only thing I would like to add is that it is better to explicitly use getName() in both hashCode() and equals(). equals() now uses toString(), which directly call getName(), but that could get changed (as the FIXME suggests) in the future. BTW. In general the toString() method should only be used for quick human readable output (for debugging purposes) so the exact String returned doesn't matter that much. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] Patch: remove bogus ServerSocket security check
Mark == Mark Wielaard [EMAIL PROTECTED] writes: Mark It is clear the current check is wrong since we check on the SocketImpl Mark of the ServerSocket and not the Socket that accept would return. But Mark wouldn't the correct security check just be to move this check just Mark after implAccept(socket) and then do the exact same check on the just Mark created socket? Yeah, I think that would be correct. Mark Gary, do we have Mauve tests for this case already? AFAIK we don't. We do have a PR for this bug though. Tom ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
[cp-patches] RFC: checking for socklen_t
Hi!
I tried to compile classpath on a quite old system:
$ uname -a
OSF1 mips.complang.tuwien.ac.at V4.0 878 alpha
And on this system socklen_t isn't defined. This macro taken from
http://ac-archive.sourceforge.net/Miscellaneous/type_socklen_t.html
checks for socklen_t and define it to `int' if not found (Andrew Pinski
will surely complain here ;-)
TWISTI
2006-01-01 Christian Thalinger [EMAIL PROTECTED]
* configure.ac: Added TYPE_SOCKLEN_T call.
* m4/type_socklen_t: Added.
Index: configure.ac
===
RCS file: /cvsroot/classpath/classpath/configure.ac,v
retrieving revision 1.122
diff -u -3 -p -r1.122 configure.ac
--- configure.ac1 Jan 2006 20:57:30 - 1.122
+++ configure.ac1 Jan 2006 22:17:27 -
@@ -276,6 +276,8 @@ if test x${COMPILE_JNI} = xyes; then
AC_STRUCT_TM
AC_STRUCT_TIMEZONE
+ TYPE_SOCKLEN_T
+
AC_MSG_CHECKING([for tm_gmtoff in struct tm])
AC_COMPILE_IFELSE([AC_LANG_PROGRAM([[#include time.h]],[[struct tm tim;
tim.tm_gmtoff = 0;]])],
[AC_DEFINE(STRUCT_TM_HAS_GMTOFF, 1, [Define if struct tm has tm_gmtoff
field.])
Index: m4/type_socklen_t.m4
===
RCS file: m4/type_socklen_t.m4
diff -N m4/type_socklen_t.m4
--- /dev/null 1 Jan 1970 00:00:00 -
+++ m4/type_socklen_t.m41 Jan 2006 22:17:27 -
@@ -0,0 +1,14 @@
+AC_DEFUN([TYPE_SOCKLEN_T],
+[AC_CACHE_CHECK([for socklen_t], ac_cv_type_socklen_t,
+[
+ AC_TRY_COMPILE(
+ [#include sys/types.h
+ #include sys/socket.h],
+ [socklen_t len = 42; return 0;],
+ ac_cv_type_socklen_t=yes,
+ ac_cv_type_socklen_t=no)
+])
+ if test $ac_cv_type_socklen_t != yes; then
+AC_DEFINE(socklen_t, int, [Substitute for socklen_t])
+ fi
+])
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] RFC: checking for socklen_t
Twisti == Christian Thalinger [EMAIL PROTECTED] writes: Twisti And on this system socklen_t isn't defined. This macro taken from Twisti http://ac-archive.sourceforge.net/Miscellaneous/type_socklen_t.html I assume we can use macros from here in Classpath. Twisti 2006-01-01 Christian Thalinger [EMAIL PROTECTED] Twisti * configure.ac: Added TYPE_SOCKLEN_T call. Twisti * m4/type_socklen_t: Added. This is ok. Twisti + if test $ac_cv_type_socklen_t != yes; then Twisti +AC_DEFINE(socklen_t, int, [Substitute for socklen_t]) Twisti + fi Kind of a bogus approach (better to use a real typedef), but whatever. Tom ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] RFC: checking for socklen_t
On Sun, 2006-01-01 at 15:24 -0700, Tom Tromey wrote: Twisti == Christian Thalinger [EMAIL PROTECTED] writes: Twisti And on this system socklen_t isn't defined. This macro taken from Twisti http://ac-archive.sourceforge.net/Miscellaneous/type_socklen_t.html I assume we can use macros from here in Classpath. Yes, the ac-archive is distributed under GPLWithACException. But please add a pointer to this inside the m4/type_socklen_t file itself (make the first line of this file a comment with the above URL) Thanks, Mark signature.asc Description: This is a digitally signed message part ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] RFC: checking for socklen_t
On Sun, 2006-01-01 at 15:24 -0700, Tom Tromey wrote: Twisti + if test $ac_cv_type_socklen_t != yes; then Twisti +AC_DEFINE(socklen_t, int, [Substitute for socklen_t]) Twisti + fi Kind of a bogus approach (better to use a real typedef), but whatever. That's true, yes. I'll commit it like this and we can change that. But i think it will not happen for many users, except me :-) TWISTI ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] RFC: checking for socklen_t
Christian Thalinger wrote: Hi! I tried to compile classpath on a quite old system: $ uname -a OSF1 mips.complang.tuwien.ac.at V4.0 878 alpha And on this system socklen_t isn't defined. This macro taken from http://ac-archive.sourceforge.net/Miscellaneous/type_socklen_t.html checks for socklen_t and define it to `int' if not found (Andrew Pinski will surely complain here ;-) Well, he hasn't yet, but I'll add my comment here. I'd like to see it as an unsigned int and not an int. Most systems I know use unsigned int for socklen_t. Posix.1g also recommends to use uint32_t for socklen_t. Andreas ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] ensure LOCALHOST is used when localhost name is unsuable
hello Mark,
On Monday 02 January 2006 00:50, Mark Wielaard wrote:
Hi Raif,
On Tue, 2005-12-27 at 10:19 +1100, Raif S. Naffah wrote:
pls. find attached a patch to do the above. sometimes, the
parameter localhost (to the InetAddress.getAllByName(String)
method) is an empty string which causes an UnknownHostException to
be thrown. the patch ensures that if this is the case LOCALHOST is
used instead.
This looks sane. I committed it as follows (removed the commented out
code, moved the trim() up...
but now the test for null is done twice ;-) if we're sticklers for
performance, we probably should do:
if (xxx == null)
doDefaultOrThrowException();
else
{
xxx = xxx.trim();
if (xxx.length() == 0)
doDefaultOrThrowException();
}
so we don't do it twice and added a comment
about trim in the ChangeLog entry).
2006-01-01 Raif S. Naffah [EMAIL PROTECTED]
* java/net/InetAddress.java (getAllByName): use LOCALHOST if
localhost is null or is an empty string. Trim hostname before
lookup.
thanks.
Could you add a Mauve test for this?
done.
cheers;
rsn
pgpSh2T3GHpk8.pgp
Description: PGP signature
___
Classpath-patches mailing list
Classpath-patches@gnu.org
http://lists.gnu.org/mailman/listinfo/classpath-patches
Re: [cp-patches] ensure names are trimmed
hello Mark, On Monday 02 January 2006 01:02, Mark Wielaard wrote: Hi Raif, On Tue, 2005-12-27 at 11:31 +1100, Raif S. Naffah wrote: pls. find attached a patch for security related classes. the patch ensures that names of provider, service and (message digest) algorithm are trimmed before being used as keys for search. Committed with a similar change as with the previous patch (I am probable anal about this, trim() isn't expensive) as follows: 2006-01-01 Raif S. Naffah [EMAIL PROTECTED] * java/security/MessageDigest.java (getInstance(String,String)): Use trimmed copy of provider name. * gnu/java/security/Engine.java (getInstance(String,String,Provider,Object[])): Use trimmed copy of service and algorithm names. Also updated the copyright year (happy new year!). thanks. happy new year to you too :-) Could you also add a mauve test for this one? done. cheers; rsn pgpEMhqlrjMPg.pgp Description: PGP signature ___ Classpath-patches mailing list Classpath-patches@gnu.org http://lists.gnu.org/mailman/listinfo/classpath-patches
