On Tue, Jun 08, 2021 at 09:52:51PM +0200, Mattias Engdegård wrote: > 8 juni 2021 kl. 21.10 skrev Alan Third : > > > I think the attached should solve this. > > Thank you, that would work and I don't mind you pushing that right > away. We probably should clear up the encodedness of `file` in > allocInitFromFile: -- as Eli said, the convention is keeping strings > unencoded until needed by low-level operations and it really makes > the most sense. It's not just allocInitFromFile, I'm looking at the other callers of image_find_image_file and they all call ENCODE_FILE after it too. The only direct caller of image_find_image_fd that actually uses the contents of the returned string (svg_load) also encodes the file name. So I think we could restrict the use of the encoded filename within image_find_image_fd to *only* when it actually opens the file. Patch attached. I've tested it here but I only have a couple of images to try it with. I've been looking at the other changes I made in 747a923b9a35533f98573ad5b01fccf096195079 and I'm not sure they're correct. They clearly work now, but most of the time it's probably simple ASCII which should pass easily. Before they *all* seem to have assumed the data was UTF8 encoded, which is surely wrong since most of the time it's coming from Emacs. It's things like menu item titles. These are the use cases stringWithLispString was designed for, right? The only odd one is image filenames because they're explicitly encoded? -- Alan Third