You don't say what you think is wrong with c-client, so I have to guess.
I assumed that the authors would do a much better job of checking such
things than I could; the main purpose of my message was to call
attention to the problem.
I assume that you're complaining that c-client has no knowledge of local
newlines.
No, I all I saw was that it had no newline conversions. As you say, this
does not mean something is wrong here, only that the conversions have
to be done outside of c-client. It is definitely something to watch out
for when using c-client, then!
Now, you may argue that the strcrlfcpy() function in the osdep file is
knowledge of a local newline, but that function has only one purpose; to
assist the local file drivers in transmogrifying file data into Internet
standard. If people make an issue out of it, I'll delete the function and
wire in that method directly into the Unix file drivers. I had some hope,
someday, of perhaps making the Unix file drivers run on other operating
systems -- but not at the cost of getting bogged down in this issue.
Don't worry, that was not my point. Nothing in this routine suggests
that it will be used for encoding, unless explicitly called for that
purpose by the main program (which cannot be the fault of c-client).
Or, you may drag in the issue of hard vs. soft newline. The answer to this is
that on most platforms the distinction is useless.
Sorry, I don't understand what you mean by this. The encoding/decoding
rules for both types of newline seem pretty clear to me.
What I intended to say is that QP has a problem with non-text data
if applied carelessly, *unless* you pay attention to the problem
(which you have delegated to the application with c-client).
Apparently my comments weren't relevant for c-client. Sorry for any
confusion caused.
By the way, I think it is very fortunate that so much popular machines
(eg unix) have a newline representation *different* from the Internet
one: it means that the conversion problems *will get fixed*, which would
not be the case otherwise.
--
Luc Rooijakkers Internet:
lwj(_at_)cs(_dot_)kun(_dot_)nl
Faculty of Mathematics and Computer Science UUCP: uunet!cs.kun.nl!lwj
University of Nijmegen, the Netherlands tel. +3180652271