[ANNOUNCE] D-Bus 1.0 RC 1 (0.93) released
kimmo.hamalainen at nokia.com
Tue Sep 19 08:13:27 PDT 2006
On Tue, 2006-09-19 at 17:49, ext Havoc Pennington wrote:
> Kimmo Hämäläinen wrote:
> > You can never be entirely sure that the arguments are valid, because you
> > don't necessarily have the same information as the library has.
> Give me an example where this is true.
I'm talking about a general case: validness can be time-dependent, and
the library can only detect this at the time the function is called.
> > In some
> > cases it could even happen that the arguments become invalid after you
> > have validated them but before you had the chance to call the function.
> How can this happen? With threads?
It's probably dependant of the D-Bus implementation (for example, some
implementation could check the validation of a match using information
about existing services). If the API should be as stable as possible, we
should not ask for trouble by specifying the API thinking only about the
> >> Having every function validate everything is both
> >> incredibly high-maintenance and cpu-intensive.
> > I'm not proposing more validation to be done by the library.
> If the app can't validate, and the library shouldn't have more
> validation, who is going to validate?
I meant that I'm not proposing additional validation to the existing
functions, because you were saying that it would slow down.
> > It's an issue to detect OOM, as I have said above. I think D-Bus API
> > should allow unconditional detection of OOM, as any sensible API does.
> Again, if there is a function where detection of OOM is impossible, we
> will fix it. In all cases I know of, the return_if_fail checks are
> avoidable by the app developer, and other than those checks the return
> value unconditionally means OOM.
I'm not saying that detecting OOM is impossible, I'm saying that the API
does not make it 100% reliable in the general case (especially if the
library implementation is changed). The library already knows when OOM
happens, we just would need to tell the user about it.
> If you like, we can make the return_if_fail checks return TRUE for
> functions where FALSE means OOM.
The return code should only have one meaning. As I said it could mean
'error happened' and then the get_error() (or something) could be used
to ask for the type of the error.
> Keep in mind, I fully agree that we should add the name validation
> routines so people can use untrusted interface/object-path names.
I think I cannot convince you about the other issue, so I'm giving up. I
had to try... :)
More information about the dbus