<div dir="ltr">Understood! Thank you.<div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div><br></div><div><br></div><div><span style="font-size:13px"><div><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse"><b>José Valim</b></span></div><div><span style="font-family:arial,sans-serif;font-size:13px;border-collapse:collapse"><div><span style="font-family:verdana,sans-serif;font-size:x-small"><a href="http://www.plataformatec.com.br/" style="color:rgb(42,93,176)" target="_blank">www.plataformatec.com.br</a></span></div><div><span style="font-family:verdana,sans-serif;font-size:x-small">Skype: jv.ptec</span></div><div><span style="font-family:verdana,sans-serif;font-size:x-small">Founder and Director of R&D</span></div></span></div></span></div></div></div></div></div>
<br><div class="gmail_quote">On Mon, Feb 1, 2016 at 12:59 PM, Björn Gustavsson <span dir="ltr"><<a href="mailto:bjorn@erlang.org" target="_blank">bjorn@erlang.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, Feb 1, 2016 at 9:44 AM, José Valim<br>
<<a href="mailto:jose.valim@plataformatec.com.br">jose.valim@plataformatec.com.br</a>> wrote:<br>
> So I would say list_to_binary is behaving as expected and that it should not<br>
> change as those "limitations" are there today. Same for port_command, as it<br>
> expects iodata. Or am I missing something?<br>
<br>
</span>My point is that we must look for code in<br>
OTP that will break when the change to<br>
the atoms are made.<br>
<br>
As an hypothetical example, say that we<br>
find the following code in some application:<br>
<br>
  Str = atom_to_list(Atom),<br>
  .<br>
  .<br>
  .<br>
  port_command(Port, Cmd, Str)<br>
<br>
We must look at the context to determine<br>
what we should do. There could be one<br>
of several solutions, for example:<br>
<br>
1. If the atoms that can be passed to this<br>
code have been internally generated we<br>
could know that the resulting list is always<br>
safe to send to the port. In that case we<br>
don't need to update the code.<br>
<br>
2. If the origin of the atom is unknown,<br>
and the driver cannot handle UTF-8,<br>
the solution could be to return an error<br>
to the caller if the atom contains<br>
non-latin1 characters.<br>
<br>
3. If the driver can handle UTF-8 or can<br>
be modified to handle UTF-8, the solution<br>
could be to use atom_to_binary(Atom, utf8)<br>
instead of atom_to_list/1.<br>
<br>
Basically, we must look at every atom_to_list/1<br>
in the OTP code base and determine whether<br>
it is safe or if it must be modified in some way.<br>
<div class="HOEnZb"><div class="h5"><br>
/Björn<br>
<br>
--<br>
Björn Gustavsson, Erlang/OTP, Ericsson AB<br>
</div></div></blockquote></div><br></div>