[alsa-devel] Why is the bufs argument for snd_pcm_writen not const?
Trent Reed
treed0803 at gmail.com
Mon May 16 09:19:29 CEST 2016
Absolutely!
Sorry about that, I'm used to requesting changes and not being able to make
them myself. I'll ping the thread with the patch later this week. :)
Thanks,
- Trent Reed
On May 16, 2016 12:12 AM, "Takashi Iwai" <tiwai at suse.de> wrote:
On Mon, 16 May 2016 09:06:06 +0200,
Trent Reed wrote:
>
> Thanks Takashi,
>
> I wasn't able to find anything about this in the documentation. Perhaps if
> it isn't changed in the API, it could be added as a @note for Doxygen in
> the functions?
A patch is always welcome :)
Takashi
>
> - Trent Reed
> On May 15, 2016 11:58 PM, "Takashi Iwai" <tiwai at suse.de> wrote:
>
> > On Sun, 15 May 2016 05:05:49 +0200,
> > Trent Reed wrote:
> > >
> > > Hey All,
> > >
> > > Just wondering what the reasoning is behind snd_pcm_writen not having
> > > a constant variable for bufs. To me, this doesn't make sense. Does
> > > snd_pcm_writen make any alterations to bufs? I would expect one of the
> > > following declaration:
> > >
> > > // Better, but doesn't promise that the API won't change the channel
> > pointers.
> > > snd_pcm_sframes_t snd_pcm_writen(snd_pcm_t* pcm, const void** bufs,
> > > snd_pcm_uframes_t size);
> > > // Best, promises ALSA won't change channel pointers, wont change
> > > underlying data.
> > > snd_pcm_sframes_t snd_pcm_writen(snd_pcm_t* pcm, const void*const*
> > > bufs, snd_pcm_uframes_t size);
> > >
> > > For now, is it safe to assume that snd_pcm_writen() doesn't alter any
> > > of the data in bufs passed into it? Any chance on seeing this patched
> > > or is there some reason for this?
> >
> > We never thought of modifying the data inside the writen API
> > function. The lack of const is merely the laziness.
> >
> >
> > Takashi
> >
> [2 <text/html; UTF-8 (quoted-printable)>]
>
More information about the Alsa-devel
mailing list