On Thu, 10.12.09 21:20, Mads Kiilerich (mads at kiilerich.com) wrote: > With reference to http://0pointer.de/lennart/projects/pulseaudio/doxygen/stream_8h.html#aa2e5ff19aa36b90471c34badbdfdf345 > and using pulseaudio-0.9.15-17.fc11.i586: > > My experiments shows that pa_stream_readable_size() sometimes > returns 4294967295 = 0xffffffff. That possibility is not described > in the documentation, AFAICS. If _reasable_size() returns (size_t) -1 this is an indication of an error. Almost all functions in the PA API return an error indication by some special return code, such as NULL (in case where a pointer is returned), or (size_t) -1 (where a size in bytes is returned) or similar. This is not really documented though I think (patches welcome), though should be pretty obvious from most function signatures... > However, I have only seen that happen when not PA_STREAM_READY. Is > the ready state a precondition for calling this function? How should > race conditions be avoided? We verify the state of the stream when you call a function on it. If it is not OK to call the function you are calling in the specific state you will get some kind of error indication and can read the error code via pa_context_errno(). It should be in PA_ERR_BADSTATE for cases like yours specifically. > It would have matched my expectations better if the type was ssize_t > and the value thus -1. Are there any other special values? Generally I try to use the types in a way that they make clear the range of the variables/parameters when *valid*. But that's just a matter of taste, and the libc handles this differently, as one example. > Have I misunderstood something? Or is it a bug in pa? Or some > unfortunate artificats for which documentation patches would be > appreciated? The latter. > Do the same apply to pa_stream_writable_size? Yes. We try our best to make things behave similarly for the various functions. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4
