[ANNOUNCE] D-Bus 1.0 RC 1 (0.93) released
hp at redhat.com
Tue Sep 19 07:49:26 PDT 2006
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.
> 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?
>> 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?
> 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.
If you like, we can make the return_if_fail checks return TRUE for
functions where FALSE means OOM.
Keep in mind, I fully agree that we should add the name validation
routines so people can use untrusted interface/object-path names.
More information about the dbus