[pulseaudio-discuss] [PATCH v2] module-coreaudio-device: get channel name as CFString and convert to plain C string.

[Arun Raghavan]

On Mon, 2015-04-20 at 19:06 +0200, Mihai Moldovan wrote:
> On 20.04.2015 06:39 PM, Mihai Moldovan wrote:
> > I am using git format-patch. I'm also using --attach. My mail client has
> > a habit of breaking long lines at a 80 character limit, so this could
> > potentially destroy the patch/make it unable to apply cleanly, which is
> > putting an even greater burden on the person who has to apply it in the end.
> >
> > It probably has to do with Enigmail and and I could work around it by
> > not signing my mails or hoping that PGP/MIME (which I use anyway) does
> > not show this weird behavior, but I prefer to sign my mails still.
> 
> On that account, see how my last answer has rewrapped and broken the
> quoted patch...
> 
> 
> >> On 2015-04-19 08:57, Mihai Moldovan wrote:
> >>> [...]
> >>>
> >>> +/* Caveat: this function frees the CFString if conversion succeeded. */
> >> I'm not actually following the reasoning. Is the CFString leaked if
> >> the conversion fails, that can't be a good thing?
> > It means the caller is responsible for freeing it in case conversion
> > failed. Maybe the caller want to do something to rectify the situation
> > or use it in some way or another after a failing conversion -- we don't
> > know and it wouldn't be a good idea to just free it so it'll be unavailable.
> >
> > If however conversion succeeds, there's no need keeping it around.
> 
> One rationale I forgot to mention: for a valid CFString, conversion
> shouldn't ever fail. If it did, the reference may be faulty or something
> else fishy going on. In any case, we shouldn't try to call CFRelease()
> on random, maybe even corrupt data...

I don't think that's a valid rationale. It can fail for other reasons
too (the buffer you provided was too small). I thing we need to always
CFRelease() it. If it's bad/corrupted memory, things will probably break
more catastrophically, and this condition is not going to help.

-- Arun