[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 <jan.h.d@swipnet.se> 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
thing.
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
already...
Grüße, Carsten