GNOME Bugzilla – Bug 730968
gst_pad_get_range nullability
Last modified: 2014-06-03 04:40:51 UTC
The documentation for gst_pad_get_range makes it sound like NULL is a perfectly reasonable value for the buffer argument, but the code uses g_return_val_if_fail. The g_return_val_if_fail documentation says If expr evaluates to FALSE, the current function should be considered to have undefined behaviour (a programmer error). The only correct solution to such an error is to change the module that is calling the current function, so that it avoids this incorrect call. Either the documentation should be changed, or the check shouldn't use g_return_val_if_fail.
Same issue for gst_pad_pull_range.
What sentences make it sound like NULL is a perfectly reasonable value for the buffer argument? I think there might be a misunderstanding. Passing NULL as buffer argument is not allowed here, one must always pass an address to a GstBuffer * variable. But that variable may contain a buffer or be NULL. If it's NULL a buffer will be allocated and returned, if the variable is already set to a buffer, the buffer will be filled with data. For bindings the latter case should probably be ignored, but bindings will have to init any such variable to NULL then, which I hope they all do anyway, but I don't know if it can be expressed in form of annotations. These functions will only be used by plugins and only very special kind of plugins, so not so important really.
It seems like I misread something--not sure what, but re-reading it now it all makes sense to me. I do seem to remember seeing some other functions which described the value returned by a g_return_val_if_fail (or at least *thinking* I saw such functions), I'll file a new bug if I come across another one. Sorry for the noise.