Am 09.02.2015 um 20:31 schrieb Rainer Jung:
src/sslinfo.c: In function
'Java_org_apache_tomcat_jni_SSLSocket_getInfoB':
src/sslinfo.c:221:51: error: dereferencing pointer to incomplete type
array = tcn_new_arrayb(e, &session->session_id[0],
^
src/sslinfo.c:222:47: error: dereferencing pointer to incomplete type
session->session_id_length);
^
src/sslinfo.c: In function
'Java_org_apache_tomcat_jni_SSLSocket_getInfoS':
src/sslinfo.c:301:51: error: dereferencing pointer to incomplete type
char *hs = convert_to_hex(&session->session_id[0],
^
src/sslinfo.c:302:50: error: dereferencing pointer to incomplete type
session->session_id_length);
^
Hmm, that's weird. That code's been like that for ... ever.
Does anybody know what the build environment looks like for this?
SSL_SESSION.session_id is an unsigned char[]
It would be odd to do "&session->session_id[0]" instead of simply
"session->session_id" unless one wanted to obfuscate the loss of type
information.
SSL_SESSION.session_id_length is an unsigned int and .. it should be
fine.
I think the OpenSSL being used here might be borked.
I followed a couple of links from the above ones and landed at a gump
page looking like it would use the master branch of OpenSSL at github.
If that is true, it can well be, that direct access to internal OpenSSL
structures is no longer possible. The general tendency is making
structures opaque and allowing access only via accessor functions.
I haven't checked, whether this is the case here.
OK, this should probably be (from ssl/ssl.h):
const unsigned char *SSL_SESSION_get_id(const SSL_SESSION *s,
unsigned int *len);
The function exists at least since 0.9.8 (checked with 0.9.8za).
I tried to fix it in r1658557.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
