Re: Addresses not importing vcards files

[Richard Frith-Macdonald]

On 10 Sep 2013, at 10:22, Sebastian Reitenbach <sebastia@l00-bugdead-prods.de> 
wrote:

> 
> On Sunday, September 8, 2013 14:42 CEST, Philippe Roussel 
> <p.o.roussel@free.fr> wrote: 
> 
>> Hi Sebastian,
>> 
>> On Sun, Sep 08, 2013 at 02:27:56PM +0200, Sebastian Reitenbach wrote:
>>> Hi,
>>> 
>>> while testing Addresses for a new release, I figured there are a couple of 
>>> problems.
>>> Riccardo suggested to forward them here, I'll separate them in different 
>>> threads.
>>> 
>>> First problem is that Addresses is unable for me to import vcards, even 
>>> vcards 
>>> it successfully exported.
>>> 
>>> I found that in Addresses/Frameworks/Addresses/ADConverter.m in 
>>> - (id<ADInputConverting>) inputConverterWithFile: (NSString*) filename
>>> 
>>> http://cvs.savannah.gnu.org/viewvc/gap/system-apps/Addresses/Frameworks/Addresses/ADConverter.m?revision=1.4&root=gap&view=markup
>>> 
>>> 
>>> its detecting the type of encoding of the file wrongly. With the patch 
>>> attached,
>>> it works for me. That moves the detection of ASCII encoding before UTF8 
>>> encoding.
>>> 
>>> Without the patch it would detect UTF-8 all the time, and then fail parsing 
>>> the vcard.
>>> On the other hand, I could just move the UTF-8 detection to the end.
>> 
>> I'm probably missing something here but shouldn't utf-8 works for
>> plain ascii files ?
> 
> I would have expected that too, but that didn't seemed to be the case.
> When it was parsing the vcard, addresses was telling me that it didn't found 
> a vcard 
> in the file. I set a breakpoint into the function where its doing the parsing,
> and its looking for the colon in: BEGIN:VCARD
> 
> But it cannot find the :, printing out the string examining it, I see only 
> some garbage,
> but no readable string.
> With the patch I had attached, I moved the detection of ASCII before UTF8,
> then it happily detected the colon, and imported the vcard.
> 
> Sebastian

The patch can't possibly be correct because, as Philippe pointed out, if a 
vcard is valid ascii then it *must* also be valid utf-8.

The only ways I can think of that the patch could 'fix' things for a particular 
vcard would be:
a. there's a memory or unintialised variable bug somewhere and changing the 
code layout stops the bug manifesting ion this case or
b. there's a bug in the ascii string checking such that it is creating a string 
successfully even though the data is not valid ascii
c. some other bug the patch somehow hides

Could you possibly post the actual vcard so I could try looking at it under gdb.


PS. I think the existing code to try latin2 and ascii after all else should be 
removed since it's redundant and should never be reached as it's preceded by an 
attempt to use latin1 which should always succeed.