[erlang-questions] Fwd: Change in behaviour in 5.9

[Fred Hebert]

I wouldn't use lists:flatten/1 for iolists because by definition, iolists
can also contain binaries. The only safe way, I figure, would be to use
iolist_to_binary/1 as the list is a sequence of bytes and binaries.

If you want to convert it back to a list, you can use binary_to_list/1 for
the example used rightn ow, but you have to be careful in general cases: if
you have encoded Unicode (utf-8/16/32) in there, the format will be lost on
the final string. This is because Unicode strings as lists directly use
codepoint numbers and not a specific encoding to represent various
codepoints. In these cases what you want to do is in fact convert the
iolist using unicode:characters_to_list/1, which will take care of changing
the bytes from a given encoding into the right representation. There is
also unicode:characters_to_binary/1 if you need it going that way.

I've got a few more details and examples at
http://ferd.ca/will-the-real-unicode-wrangler-please-stand-up.html. When
you want to handle unicode or one of its encodings, you have to be careful
in how you handle things; I'd recommend against using lists:flatten to
handle io lists (especially when the unicode module itself accepts iolists).

On Sat, Jan 14, 2012 at 4:22 AM, Michael Uvarov <freeakk@REDACTED> wrote:

> Don't use internal structure of iolist. It can be changed anytime. It is
> useful for collecting data together, not for splitting it again. You only
> can transform the iolist to a list or to a binary.
>
>
>> Eshell V5.9  (abort with ^G)
>> 1> io_lib:format("~10.6.0f", [7.0]).
>> [["00",55,46,48,48,48,48,48,48]]
>> 2> lists:flatten(io_lib:format("~10.6.0f", [7.0])).
>> "007.000000"
>>
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20120114/bc3e6c40/attachment.htm>