[Openmcl-devel] *default-external-format* and encoding and decoding strings.

[Ron Garret]

On Mar 7, 2016, at 7:16 PM, Gary Byers <gb at clozure.com> wrote:

> 
> 
> On 03/07/2016 04:34 PM, Ron Garret wrote:
>> On Mar 7, 2016, at 3:23 PM, Gary Byers <gb at clozure.com> wrote:
>> 
>>> 
>>> On 03/07/2016 03:36 PM, Ron Garret wrote:
>>>> On Mar 7, 2016, at 1:30 PM, R. Matthew Emerson <rme at clozure.com> wrote:
>>>> 
>>>>>> On Mar 5, 2016, at 12:03 PM, Ron Garret <ron at flownet.com> wrote:
>>>>>> 
>>>>>> 
>>>>>> On Mar 5, 2016, at 8:39 AM, Dmitry Igrishin <dfigrish at gmail.com> wrote:
>>>>>> 
>>>>>>> 2016-03-05 16:25 GMT+03:00 Dmitry Igrishin <dfigrish at gmail.com>:
>>>>>>> Hello,
>>>>>>> 
>>>>>>> The *default-external-parameter* doesn't considered by
>>>>>>> count-characters-in-octet-vector, decode-string-from-octets,
>>>>>>> encode-string-to-octets, string-size-in-octets functions which
>>>>>>> has the :external-format parameter. I believe that
>>>>>>> *default-external-parameter* should affect the behaviour of
>>>>>>> all functions with :external-format parameter, right?
>>>>>>> Sorry, I meant the *default-external-format* special variable...
>>>>>> This is a bug in ccl::lookup-character-encoding.  Here’s a patch:
>>>>>> 
>>>>>> (in-package :ccl)
>>>>>> 
>>>>>> (let ((ccl::*warn-if-redefine-kernel* nil))
>>>>>>  (defun lookup-character-encoding (name)
>>>>>>    (gethash (or name *default-external-format*) *character-encodings*)))
>>>>> I don't think I can apply this.
>>>>> 
>>>>> The issue is that nil is a valid character encoding name: it's a documented synonym for :iso-8859-1.
>>>> That’s a bug in the documentation.  NIL should be a synonym for *default-character-encoding*.  (I’m not joking.  That part of the docs was written before the introduction of *default-character-encoding*.)
>>> when that part (what part is it, by the way?) was written, :iso-8859-1 was the default character encoding.
>> Yes, I know.  That’s why I thought it was wrong, because the introduction of *default-external-format* had rendered it obsolete.  But then I read it more closely and remembered my history...
>> 
>>> Changing the functions in question to use (e.g.)
>>> 
>>> (defun encode-string-to-octets (string &key (external-format :default) ....) ...
>>> 
>>> seems to be another approach
>> Yes, just more work.
> Unless I'm missing something, we are talking about 4 functions here - ENCODE-STRING-TO-OCTETS, DECODE-STRING-FROM-OCTETS,
> COUNT-OCTETS-IN-STRING, and COUNT-CHARACTERS-IN-OCTET-VECTOR.

That sounds right, though to be sure you’d have to go through a lot more of the code base to make sure you had gotten every function with an external-format argument.

> Someone who reads the documentation and says (DECODE-STRING-FROM-OCTETS  ... :EXTERNAL-FORMAT NIL) seems
> to be asking for a string produced from octets that are encoded in iso-8859-1, whether or not NIL should be an alias
> for that encoding. Given the documented treatment of NIL as an alias here, it is not clear why these 4 functions
> should treat an unsupplied :external-format argument differently than LOAD or OPEN do.

Yes, changing the default value of external-format to :default everywhere it appears would solve this problem.  That seems to me like a high price to pay to support some legacy special case, but it’s not my opinion that matters in this regard.

rg