erl_interface

[Serge Aleynikov]

Serge Aleynikov <serge@REDACTED> writes:

 > I wonder if you could share some of your erl_interface examples with
 > me. I've been trying to write some code that passes either a
 > tuple/list, or an integer from C to Erlang, and I am having a problem
 > that in case of integers (see iterate() and finalize() below) Erlangs
 > gets a response correctly, but in case of tuple/list (see
 > initialize()), looks like Erlang is waiting for something in addition
 > to what the port replies.  I can see in debugger that the Port sends
 > everything normally, and than blocks on the read() function as
 > expected.

After spending a couple of days in trying to figure out why the C port 
failed to pass complex (tuple/list) structures back to Erlang under 
Windows, I found the cause of the problem, which I wanted to share with 
the rest of the Erlang community.

By default the stdout is open in the O_TEXT mode.  What this implies is 
that in text mode, carriage-return/linefeed (CR/LF) combinations are 
translated to a single linefeed character (LF) on input. On output, the 
reverse is true: LF characters are translated to CR/LF combinations 
(under Windows OS).  In binary mode, no such translation occurs.

So, initially I couldn't figure out why after sending from C to Erlang a 
tuple of size 10 bytes, Erlang waited for more data.  After dumping the 
stdout to a binary file, I noticed that Windows substituted the value of 
10 (LF) with 13,10 (CR/LF) (just as the document said :-)).  So Erlang 
was waiting for 13 bytes instead of 10, and my C port was blocking in 
the read() function forever.

So, for those of you developing C ports under Windows, plese do remember 
to set the stdout mode to O_BINARY in the beginning of the program:

           setmode(fileno(stdout), O_BINARY);

this will save you from sleepless nights bewildered by the cause of the 
trouble.  ;-)

Regards,

Serge