On 05.12.2017 15:57, Takashi Iwai wrote:
> On Tue, 05 Dec 2017 15:37:09 +0100,
> Takashi Sakamoto wrote:
>>
>> Hi,
>>
(..)
>> In my opinion, addition of constraint of PCM hardware parameters to
>> these PCM plugins is preferable to insertion of the assertions,
>> because abort inner library is bad idea itself. Proper errors should
>> be returned
>> to applications in protocol via alsa-lib PCM APIs. It's more friendly to
>> usual developers and users.
>
> Well, it's basically moot to discuss about it, as
> snd_pcm_lib_linear_get_index() is an internal function, i.e. it's not
> supposed to be called from applications.
>
> In that sense, assert() wouldn't be too bad. However, the primary
> question is -- would it really catch anything in practice? What drove
> you to put that assert() at all?
>
> If a check of the valid formats, then calling snd_pcm_format_linear()
> is the safest.
The reason I added these asserts is that snd_pcm_linear_{get,put}_index()
use result from snd_pcm_format_width() directly to calculate an array
index.
If, for any reason, this function returns an unexpected width a subtle
bug will emerge.
Three reasons that I could think of why an unexpected width would be
returned is a bug in a plugin that uses these functions (currently 9
plugins use them) that fail to properly restrict source / destination
format space to linear formats only, a bug in general format refining
code or somebody adding a format to linear formats mask without
adapting conversion arrays, too.
I know that these may sound like rare occurrences but since this
check is close to zero-cost (it only happens on plugin stack
initialization time and not, for example, at every sample) I think it
is worth the extra time (and one can always compile the library with
NDEBUG to skip it).
> thanks,
>
> Takashi
>
Thanks,
Maciej
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
