[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: |
Jan Djärv |
Subject: |
bug#15570: 24.3.50; Null pointer crash in (ns-convert-utf8-nfd-to-nfc "\377") |
Date: |
Wed, 9 Oct 2013 20:50:58 +0200 |
Hello.
We now throw an error.
Jan D.
9 okt 2013 kl. 20:33 skrev Carsten Bormann <cabo@tzi.org>:
> 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