[Top][All Lists]

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

[Octave-bug-tracker] [bug #55452] fopen() does not support encoding argu

From: Andrew Janke
Subject: [Octave-bug-tracker] [bug #55452] fopen() does not support encoding argument
Date: Sat, 9 Mar 2019 13:29:18 -0500 (EST)
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 Safari/537.36

Follow-up Comment #16, bug #55452 (project octave):

> I was wondering about format strings like "äöü %s %.3f", i.e. format
strings that don't consist exclusively of format specifiers. We probably would
have to somehow detect which parts of the format string are specifiers and
convert only the remaining parts before we pass the string to the C functions.

I think this depends on what encoding Octave is storing its strings in
internally. If it's UTF-8, you're in the clear, because the multi-byte
sequences never use bytes that are valid ASCII characters.

If Octave is internally using the system default encoding, I think you
technically have to transcode it to UTF-8 or whatever the C/C++ string
processing functions are using for the placeholder-substitution logic.

Then in either case you need to transcode it again to your final output

BUT - every single-byte encoding I'm aware of is ASCII-compatible, and since
Octave's internal strings are built on chars and are not currently doing
transcoding, I think you're stuck with "single-byte-compatible" encodings, and
that concern doesn't apply.

And at the C level, `sprintf()` and friends are not encoding-aware, so I think
you're stuck using an ASCII-compatible encoding with them anyway.


Reply to this item at:


  Message sent via Savannah

reply via email to

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