list_to_atom use in kernel/error_logger.erl

[Gunilla Arendt]

Clarification: I should have added that I think list_to_atom/1 is in 
error_logger for *historical reasons*, i.e. my guess is that it's a 
remnant from a time when erlang:display/1 displayed strings as list of 
ascii codes. Nowadays, erlang:display/1 can handle strings as well as 
atoms and the call to list_to_atom/1 is indeed superfluous.

That said, I would like to point out that messages to error_logger could 
be sent from any process, so it is (was) not an application_controller 
issue. It is true that application_controller sends lists to 
error_logger, but so could any other process. Also, the code snippet you 
refer to actually has to do with the exit reason of the 
application_controller process, not an error report.

/ Gunilla

Serge Aleynikov wrote:
> I believe what you are referring to is actually a small issue with the 
> application_controller rather than error_logger.  If the following patch 
> is applied to the application_controller then the logging problem at 
> system startup that you indicated will be more readable and you could 
> remove the list_to_atom(L) in the error_logger.erl.
> 
> --- kernel-2.10.12/src/application_controller.erl Fri Jan 27 17:17:31 2006
> +++ lib/kernel/src/application_controller.erl Thu Feb  2 10:12:01 2006
> @@ -1932,6 +1932,6 @@
>               true ->
>                   Term;
>               false ->
> -                 lists:flatten(io_lib:write(Term))
> +                 lists:flatten(io_lib:format("~p", [Term]))
>           end,
>      lists:sublist(Str, 199).
> 
> Regards,
> 
> Serge
> 
> Gunilla Arendt wrote:
> 
>> Serge Aleynikov wrote:
>>
>>>
>>> Thank you for clarification.  The reason I looked into the 
>>> error_logger's code was indeed related to the ugly format of the 
>>> displayed message upon an unsuccessful startup with a -boot option.
>>>
>>> Though I still don't understand the need for list_to_atom(L) there.  
>>> Why not just return the list L?  It does work either way.
>>>
>>
>> I haven't tried to verify this, but my guess would be that someone tried
>> to make the output from error_logger more readable in the case where
>> the Erlang run-time system fails to start.
>>
>> For example, if an application in the boot script fails to start, you
>> will see something like this:
>>
>> $ erl
>> {error_logger,{{2006,2,2},{14,11,52}},'Protocol: ~p: register error: 
>> ~p~n',[inet_tcp,{{badmatch,{error,duplicate_name}},[{inet_tcp_dist,listen,1},{ne 
>>
>> t_kernel,start_protos,4},{net_kernel,start_protos,3},{net_kernel,init_node,2},{n 
>>
>> et_kernel,init,1},{gen_server,init_it,6},{proc_lib,init_p,5}]}]}
>> ...
>>
>> which is of course somewhat more readable than
>>
>> {error_logger,{{2006,2,2},{14,11,52}},[80,114,111,116,111,99,111,108,58,32,126,1 
>>
>> 12,58,32,114,101,103,105,115,116,101,114,32,101,114,114,111,114,58,32,126,112,12 
>>
>> 6,110],[inet_tcp,{{badmatch,{error,duplicate_name}},[{inet_tcp_dist,listen,1},{ne 
>>
>> t_kernel,start_protos,4},{net_kernel,start_protos,3},{net_kernel,init_node,2},{n 
>>
>> et_kernel,init,1},{gen_server,init_it,6},{proc_lib,init_p,5}]}]}
>> ...
>>
>> / Gunilla
>>
>>
>>
>