> On 27. May 2019, at 01:49, Mike Gran <spk...@yahoo.com> wrote: > > On Sun, May 26, 2019 at 11:17:48PM +0200, Massimiliano Gubinelli wrote: >> Hi all, >> >> I???m porting GNU TeXmacs (www.texmacs.org) to Guile 2.2.4 (and >> hopefully to Guile 3.0). The current status is the... > > Hello, > > Back in Guile 1.8, it was easy to use strings as ways to read and write > binary data because Guile 1.8 always used 8-bit characters. It had no > real understanding of UTF-8. So for 1.8, the concept of strings and > bytevectors could be used more or less interchangeably. > > Guile 2.2's string procedures now check that the data the receive > makes sense according to the locale. You are probably reading in a > file that isn't valid UTF-8 in a context where UTF-8 is expected, if > you locale were something like fr_FR.utf8. Or maybe you are reading > in a file that isn't pure ASCII when pure ASCII is expected, if your > locale were 'C' or 'POSIX.' > > So you have two choices. You can temporarily set the locale to a > Latin-1 locale, something like 'en_US.iso88591' before you read in the > file, because, Latin-1 is an 8-bit clean locale. Or, the better idea > is to use a binary port or bytevector to read in your data. > > Sorry I don't have time to be more specific.
Thanks Mike, I’m looking right now into the problem taking into account your remarks. While trying some alternative solutions I noticed the following: the function scm_to_latin1_stringn calls out to scm_to_stringn with an argument NULL for the encoding: result = scm_to_stringn (str, lenp, NULL, SCM_FAILED_CONVERSION_ERROR); this causes an error in scm_to_stringn since it contains the check: (c_strcasecmp (encoding, "UTF-8") == 0) and c_strcasecmp does not check for null pointers. Is this a bug? Best Max > > Regards, > Mike