Re: Stable glibmm and gtkmm releases soon

From: José Alburquerque <jaalburquerque gmail com>
To: Kjell Ahlstedt <kjell ahlstedt bredband net>
Cc: Murray Cumming <murrayc murrayc com>, gtkmm-list <gtkmm-list gnome org>
Subject: Re: Stable glibmm and gtkmm releases soon
Date: Wed, 27 Mar 2013 02:11:43 -0400

On Tue, 2013-03-26 at 17:02 +0100, Kjell Ahlstedt wrote:

2013-03-26 03:16, José Alburquerque skrev:

On Tue, 2013-03-19 at 10:23 +0100, Murray Cumming wrote:

I will do the .0 releases of the current glibmm and gtkmm series in the
next few days, to try to be in sync with GNOME, who have their .0
release on March 27th:
https://live.gnome.org/ThreePointSeven

So, if you have added new API, please take an extra moment to make sure
that you don't need to fix it quickly, because you probably can't break
it later.

The not so extensive newly added Tls* API is pretty much complete.  I
just thought that I would point out a couple of things that struck me as
unusual which I think would be good to be aware of before the stable
release goes out.  Also I have one final question.

May I contribute to the confusion? I think only part of the class
structure is in glib. The rest is in a TLS backend (whatever that is).
Like so, if I mix C++ syntax with C class and interface names.

In glib

class GIOStream : public GObject
class GTlsConnection : public GIOStream
class GTlsClientConnection : public GInterface
class GTlsServerConnection : public GInterface

class GTlsDatabase : public GObject
class GTlsFileDatabase : public GInterface

In a TLS backend, e.g. glib-networking

class GTlsConnectionGnutls : public GTlsConnection, public GInitable
class GTlsClientConnectionGnutls : public GTlsConnectionGnutls, public
GTlsClientConnection
class GTlsServerConnectionGnutls : public GTlsConnectionGnutls, public
GInitable, public GTlsServerConnection

class GTlsDatabaseGnutls : public GTlsDatabase
class GTlsFileDatabaseGnutls : public GTlsDatabaseGnutls, public
GTlsFileDatabase, public GInitable


g_tls_client_connection_new() returns an instance of a class that
derives both from GTlsConnection and from the interface
GTlsClientConnection.
g_tls_server_connection_new() returns an instance of a class that
derives both from GTlsConnection and from the interface
GTlsServerConnection.
g_tls_file_database_new() returns an instance of a class that derives
both from GTlsDatabase and from the interface GTlsFileDatabase.


Thanks.  That's mostly how things are presently.

The exception I was getting (in the partial example I provided) was due
to TLS support not being available.  When I installed the
glib-networking package (which was not installed in the jhbuild
environment), the exception disappeared.  However, now I'm getting
warnings about invalid setting of properties when the
Gio::TlsClientConnection is created:

(process:20604): GLib-GIO-WARNING **: gtlsconnection.c:329: invalid
property id 1 for "base-io-stream" of type `GParamObject' in
`gtkmm__GTlsConnection'

(process:20604): GLib-GIO-WARNING **: gtlsconnection.c:329: invalid
property id 4 for "use-system-certdb" of type `GParamBoolean' in
`gtkmm__GTlsConnection'

(process:20604): GLib-GIO-WARNING **: gtlsconnection.c:329: invalid
property id 2 for "require-close-notify" of type `GParamBoolean' in
`gtkmm__GTlsConnection'

(process:20604): GLib-GIO-WARNING **: gtlsconnection.c:329: invalid
property id 3 for "rehandshake-mode" of type `GParamEnum' in
`gtkmm__GTlsConnection'

This is the backtrace.

#0  g_log(log_domain = 0x7ffff6226d33 "GLib-GIO", log_level =
G_LOG_LEVEL_WARNING, format = 0x7ffff6226d00 "%s: invalid %s id %u for \
\"%s\\" of type `%s' in `%s'") at gmessages.c:1009
#1  g_tls_connection_set_property(object = 0x7ffff00059c0, prop_id = 1,
value = 0x7fffffffd260, pspec = 0x62d400) at gtlsconnection.c:329
#2  object_set_property(object = 0x7ffff00059c0, pspec = 0x62d400, value
= 0x64d578, nqueue = 0x648a40) at gobject.c:1358
#3  g_object_constructor(type = 6455760, n_construct_properties = 3,
construct_params = 0x64d4f0) at gobject.c:1869
#4  g_object_newv(object_type = 6455760, n_parameters = 0, parameters =
0x0) at gobject.c:1719
#5  Glib::Object::Object(this = 0x64c998, __vtt_parm = 0x7ffff7b10f88
<VTT for Gio::TlsClientConnection+40>, construct_params = ) at
object.cc:231
#6  Gio::IOStream::IOStream(this = 0x64c998, __vtt_parm = 0x7ffff7b10f80
<VTT for Gio::TlsClientConnection+32>, construct_params = ) at
iostream.cc:168
#7  Gio::TlsConnection::TlsConnection(this = 0x64c998, __vtt_parm =
0x7ffff7b10f78 <VTT for Gio::TlsClientConnection+24>) at
tlsconnection.cc:404
#8  Gio::TlsClientConnection::TlsClientConnection(this = 0x64c990,
castitem = 0x64a090) at tlsclientconnection.cc:95
#9  Glib::wrap_auto_interface<Gio::TlsClientConnection>(object =
0x64a090, take_copy = false) at ../../glib/glibmm/wrap.h:89
#10  Glib::wrap(object = 0x64a090, take_copy = false) at
tlsclientconnection.cc:40
#11  Gio::TlsClientConnection::create(base_io_stream = , server_identity
= ) at tlsclientconnection.cc:129
#12  main() at giomm_tls_client/main.cc:44

However, the following bug has a patch to Glib::Interface, the
_CLASS_INTERFACE m4 macro and Gio::TlsClientConnection which if used
would make the warnings disappear:

https://bugzilla.gnome.org/show_bug.cgi?id=696671

The bug also has an updated test that shows that the
Gio::TlsClientConnection class (along with the other classes, including
TlsDatabase) works fine.  Under the circumstances, and if the patch is
accepted, I would opt for inclusion of the Gio::Tls*Connection classes
because the Gio::TlsServerConnection class is wrapped just like
Gio::TlsClientConnection and would  work in a similar fashion.

From the information you've provided and what Murray has done already,

it might also be possible to include the Gio::TlsFileDatabase class
although I still don't object to it not being included.

There are a few things I want to point out that I think are small
problems which should still be considered:

1) Because classes like TlsCertificate and TlsDatabase have methods with
optional parameters and I used gmmproc's optional parameter
functionality (using '{?}') to wrap those, I ran into some compiler
ambiguity problems.  For example, the following line using the
Gio::TlsDatabase::verify_chain() method (where 'certificate' is a
TlsCertificate and 'address' is a SocketConnectable):

database->verify_chain(certificate,
G_TLS_DATABASE_PURPOSE_AUTHENTICATE_SERVER, address);

Generates the following compile error:

giomm_tls_client/main.cc: In function ‘int main(int, char**)’:
giomm_tls_client/main.cc:119:92: error: call of overloaded
‘verify_chain(Glib::RefPtr<Gio::TlsCertificate>&, const char [18],
Glib::RefPtr<Gio::InetSocketAddress>&)’ is ambiguous
giomm_tls_client/main.cc:119:92: note: candidates are:
In file included from ../gio/giomm.h:133:0,
                 from giomm_tls_client/main.cc:1:
../gio/giomm/tlsdatabase.h:317:23: note: Gio::TlsCertificateFlags
Gio::TlsDatabase::verify_chain(const Glib::RefPtr<Gio::TlsCertificate>&,
const Glib::ustring&, const Glib::RefPtr<const Gio::SocketConnectable>&,
Gio::TlsDatabaseVerifyFlags) const
../gio/giomm/tlsdatabase.h:323:23: note: Gio::TlsCertificateFlags
Gio::TlsDatabase::verify_chain(const Glib::RefPtr<Gio::TlsCertificate>&,
const Glib::ustring&, const Glib::RefPtr<Gio::TlsInteraction>&,
Gio::TlsDatabaseVerifyFlags) const
../gio/giomm/tlsdatabase.h:326:23: note: Gio::TlsCertificateFlags
Gio::TlsDatabase::verify_chain(const Glib::RefPtr<Gio::TlsCertificate>&,
const Glib::ustring&, const Glib::RefPtr<Gio::Cancellable>&,
Gio::TlsDatabaseVerifyFlags) const
make[2]: *** [giomm_tls_client/main.o] Error 1
make[2]: Leaving directory `/usr/src/jhbuild-sources/glibmm/tests'
make[1]: *** [check-am] Error 2
make[1]: Leaving directory `/usr/src/jhbuild-sources/glibmm/tests'
make: *** [check-recursive] Error 1

I don't know how to avoid it (except by specifying empty
Glib::RefPtr<>() with appropriate types for the RefPtr's in such an
order so that the ambiguities disappear).  For example, the error would
disappear if the line were changed like so:

 database->verify_chain(certificate,
G_TLS_DATABASE_PURPOSE_AUTHENTICATE_SERVER, address,
Glib::RefPtr<Gio::TlsInteraction>());

It leads me to think that the methods with optional parameters might be
wrapped another way or maybe just wrapped without making the parameters
optional for the time being.  I don't find it highly inconvenient, but
others might.

The other thing is that the Gio::TlsCertificate Glib::ByteArray type
properties are don't seem to be accessible.  For example, a call to the
Gio::TlsDatabase::lookup_certificates_issued_by() passing a
certificate's "certificate" property using an expression such as
"certifiate->property_certificate()" would trigger a compile error such
as:

In file included from ../glib/glibmm/propertyproxy_base.h:25:0,
                 from ../glib/glibmm/propertyproxy.h:25,
                 from ../glib/glibmm/objectbase.h:24,
                 from ../glib/glibmm/wrap.h:26,
                 from ../glib/glibmm/containerhandle_shared.h:26,
                 from ../glib/glibmm/arrayhandle.h:23,
                 from ../glib/glibmm.h:91,
                 from ../gio/giomm.h:23,
                 from giomm_tls_client/main.cc:1:
../glib/glibmm/value.h: In instantiation of ‘static GType
Glib::Value<Glib::RefPtr<T_CppObject> >::value_type() [with T =
Glib::ByteArray; GType = long unsigned int]’:
../glib/glibmm/propertyproxy.h:172:3:   required from ‘T
Glib::PropertyProxy_ReadOnly<T>::get_value() const [with T =
Glib::RefPtr<Glib::ByteArray>]’
../glib/glibmm/propertyproxy.h:124:30:   required from
‘Glib::PropertyProxy_ReadOnly<T>::operator
Glib::PropertyProxy_ReadOnly<T>::PropertyType() const [with T =
Glib::RefPtr<Glib::ByteArray>;
Glib::PropertyProxy_ReadOnly<T>::PropertyType =
Glib::RefPtr<Glib::ByteArray>]’
giomm_tls_client/main.cc:123:78:   required from here
../glib/glibmm/value.h:232:55: error: ‘get_base_type’ is not a member of
‘Glib::ByteArray’
../glib/glibmm/value.h: In static member function ‘static GType
Glib::Value<Glib::RefPtr<T_CppObject> >::value_type() [with T =
Glib::ByteArray; GType = long unsigned int]’:
../glib/glibmm/value.h:232:58: error: control reaches end of non-void
function [-Werror=return-type]
cc1plus: all warnings being treated as errors
make[2]: *** [giomm_tls_client/main.o] Error 1
make[2]: Leaving directory `/usr/src/jhbuild-sources/glibmm/tests'
make[1]: *** [check-am] Error 2
make[1]: Leaving directory `/usr/src/jhbuild-sources/glibmm/tests'
make: *** [check-recursive] Error 1

For now, the optional parameters can be easily fixed.  I'd have to look
a little further into the above error.

-- 
José

Follow-Ups:
- Re: Stable glibmm and gtkmm releases soon
  - From: Murray Cumming

References:
- Stable glibmm and gtkmm releases soon
  - From: Murray Cumming
- Re: Stable glibmm and gtkmm releases soon
  - From: José Alburquerque
- Re: Stable glibmm and gtkmm releases soon
  - From: Kjell Ahlstedt

[Date Prev][Date Next] [Thread Prev][Thread Next] [Thread Index] [Date Index] [Author Index]