[ANNOUNCE] D-Bus 1.0 RC 1 (0.93) released

[Havoc Pennington]

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.

Havoc