As I attempt to complete my native gprolog FastCGI project I am digging into the source code to answer some questions and I have one so far.
I wanted to know what the sock_accept/4 predicate got up to behind the scenes. Traditionally in C you have used the new socket for send() and recv(). Anyway, this is what I saw:
#ifdef _WIN32
int r;
Os_Test_Error((fd = _open_osfhandle(sock, _O_BINARY | _O_RDWR | _O_BINARY)));
Os_Test_Error((r = dup(fd)));
Os_Test_Error_Null((f_out = fdopen(fd, "w")));
Os_Test_Error_Null((f_in = fdopen(r, "r")));
#else
Os_Test_Error((fd = dup(sock)));
Os_Test_Error_Null((f_in = fdopen(sock, "rt")));
Os_Test_Error_Null((f_out = fdopen(fd, "wt")));
#endif
I have bolded the code running on OSX... my question is a simple one. what does the "t" stand for. I have checked lots of documentation and nowhere is the "t" mentioned.
I am guessing it might be "text mode" but (a) the GNU docs say that streams created like this are always binary...
and (b) I am dealing with binary packets and I really really don't want any CRLF translations happening without my knowledge.
So, is the "t" redundant and could be removed, can I relax, it all *seems* to work OK but I am just curious to know if the "t" may be an artefact from a really old release back in the day.
Thanks.
Sean Charles.