[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#15570: 24.3.50; Null pointer crash in (ns-convert-utf8-nfd-to-nfc "\

From: Carsten Bormann
Subject: bug#15570: 24.3.50; Null pointer crash in (ns-convert-utf8-nfd-to-nfc "\377")
Date: Wed, 9 Oct 2013 20:33:06 +0200

On Oct 9, 2013, at 18:31, Jan Djärv <address@hidden> wrote:

> The function clearly expects valid UTF-8 as input.  Why is tramp feeding it 
> invalid UTF-8?    What is tramp trying to accomplish?  What would be the 
> expected return value on invalid UTF-8?

I haven't looked at the details yet (that will be easier once the null pointer 
reference is fixed).

That needn't stop me from hypothesizing...

ns-convert-utf8-nfd-to-nfc is used in places where system output might contain 
Apple's slightly crazy not-quite-NFD file names, so that you can usefully cut 
and paste them etc. to places that expect the usual not-quite-NFC.  So one 
should expect a lot of not-really-UTF-8-after-all input to be fed into this 
I'm presuming tramp just feeds whatever it got from the remote system through 
this to get more useful output e.g. for a directory listing.

It probably would be useful to have a robust version of this that just chokes 
on nothing.
Raising an error on non-UTF-8 input may be a desirable behavior in other places.
(Crashing Emacs never is.)

I'm a bit surprised that this bug apparently was around for a number of years 

Grüße, Carsten

reply via email to

[Prev in Thread] Current Thread [Next in Thread]