an existing DBus connection.
This is needed by the python bindings, was done the same way
in edbus1, so it should fit here also
NOTE: I did not test this yet, and I'm not into the edbus code,
so I please who know the code to give a look. thanks
NOTE2: I don't think this need Changelog and stuff as we are probably
the only users of this function, let me know if i'm wrong
Are dbus function calls with more than 1000 arguments possible?
If so -> prevent buffer overflow
Signed-off-by: Daniel Willmann <d.willmann@samsung.com>
type is an enum which can be 0. Make sure that it isn't before accessing
shared_connections[type - 1]
Found with klocwork
Signed-off-by: Daniel Willmann <d.willmann@samsung.com>
The prototypes for those functions are defined in edbus_proxy.h, however
there's no implementation at all.
By Raphael Kubo <raphael.kubo.da.costa@intel.com>
SVN revision: 83299
If we pass the last argument as TRUE, that means user want to know the actual
bus id of the bus name and if the bus name is not registered it never notify
the user.
This bug was insert when fixing another one, because of that there more code
here to fix the previous bug too.
Patch by: José Roberto de Souza <zezsouza@gmail.com>
SVN revision: 83082
If we add and remove the interfaces in the same mainloop iteration,
there's no point in sending the signals at all. Let's just omit them
since it's likely because the rest of the intialization for having them
failed.
SVN revision: 82907
If ther interface was just added on this mainloop iteration we shouldn't
put it in the reply to GetManagedObjects because we still didn't send
the InterfacesAdded signal for that interface.
SVN revision: 82906
Give the object that originated the signal to use in the idler for
changes in ther interfaces. This greatly simplifies the code,
particularly while removing.
Fix some issues in the previous implementations. There are some races
and corner cases that need to be taken into account in ObjectManager:
- Adding and removing an interface in the same mainloop iteration. We
were previously sending only the signal InterfacesRemoved
- When we dettach an object manager we need to flush its signals
- Since now we store the iface_{added,removed} in the object in which
they happen we also need to flush out signals when attaching an
ObjectManager, but let the previous ObjectManager send the signals
- When we free an Object also flush the changes. Previously we were
omitting the signal.
There are still some places to fix and some improvements to be made. I
let some TODOs and FIXMEs there.
SVN revision: 82903
There's no reason to keep a msg after it was sent. Before this patch we
had edbus_service_signal_send() unref'ing its msg and all the others
not. Also, several users (particularly the edbus_proxy_send() ones) were
forgetting to unref the msg.
This patch makes all these methods unref the message after it has been
succesfully sent:
- edbus_connection_send()
- edbus_object_send()
- edbus_proxy_send()
- edbus_service_signal_send()
SVN revision: 82807
When an extra argument didn't match, instead of going to the next signal
handler we were skiping to next extra match argument because we were
calling "continue" inside EINA_INLIST_FOREACH.
Patch by: José Roberto de Souza <zehortigoza@profusion.mobi>
SVN revision: 82351
Hack to fix the connection name leak. The problem is that each signal
handler has a reference to the FDO_BUS connection name and when the
penultimate connection name is released (and therefore its signal
handler), FDO_BUS is released, too.
Check if cn is still in the hash before trying to free it.
Patch by: Ulisses Furquim <ulisses@profusion.mobi>
SVN revision: 82077
va_list may be typedef'ed not only to array and pointer but also to a
plain struct. It could be made to work this way, but it's a lot simpler
a safer to not depend on it. To deal with the array corner case we copy
the va_list from the function arguments to the stack and call the "real"
function passing it.
SVN revision: 82017
Make sure the next signal handler for the connection is always known and
not vanish under us.
Patch by: Ulisses Furquim <ulisses@profusion.mobi>
SVN revision: 81847