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
