GIO {In,Out}putStream {read,write} overriding may be unsafe?
Submitted by Paul Jakma
Link to original bug (#664735)
Description
I wonder if there's an issue in overriding the GIO {Out,In}putStream classes, in that the GLib C classes have a non-virtual read/write method in order to do book-keeping of the pending flag, with the {read,write}_fn intended as the overrideable hooks; while the Vala VAPI would be directing read/write method calls to different places depending on which type is invoked (the VAPI annotates "write" in OutputStream with "[CCode (vfunc_name = "write_fn")]", similarly for InputStream):
a) If 'read' is invoked on InputStream type, then the call goes to the C read method, which does the book-keeping and calls the read_fn as required.
b) If 'read' is invoked on the type of extending class of InputStream which is overriding 'read', then on the face of it it would be the read_fn virtual method which gets called, bypassing the read of the base class.
So, unless Vala is doing something special internally for the InputStream class, it seems to me that it is never ever safe to call read/write methods on children of {In,Out}putStream? To fix this, if Vala isn't special-casing this somehow, would require aligning the Vala VAPIs for these classes with the underlying C implementation I think.
Version: 0.14.x