[Qt-interest] Why Bus error clientSocket->waitForConnected()?

[Gabriele Kahlout]

just to add to the agony, what confused me the most is not the documentation
but that I was accustomed in Java to have readLine() blocking, as this code
shows:

http://code.google.com/p/javatcpchat/source/browse/trunk/src/client/TCPClient.java


2010/5/2 Thiago Macieira <thiago at kde.org>

> Em Domingo 2. Maio 2010, às 17.56.35, Kustaa Nyholm escreveu:
> > >That's why canReadLine() exists. You shouldn't call readLine() unless
> you
> > >can read a line.
> >
> > I know, I know, my point was that this is not a good API design, two
> calls
> > when one would do. And different from say C standard getline() or Java
> > readline, thus likely to trap many people.
> >
> > >It does read a line.
> >
> > Only if a line is available when I make the call.
> >
> > >What it doesn't do is *block* until more bytes are
> > >available. Only functions called "waitFor" block.
> >
> > My point was that it was bad design decision to make this non blocking,
>
> No, that was a good design. All of the API is non-blocking and that's a
> good
> design.
>
> > or a bad decision to call it readline when many other APIs/libraries and
> > common user expectation is that readline will block.
>
> Maybe the bad decision was to return anything if full a line can't be read
> but
> the device isn't at the end yet.
>
> Unfortunately, by the time we made QIODevice properly understand "can't
> read
> because it's EOF" and "can't read because there is no more data but the
> socket/process can still receive more", the readLine behaviour was set.
>
> Maybe we can still fix the behaviour.
>
> > Further, why would anyone want to have it that way?
> >
> > What purpose does it server?
>
> Sometimes devices and files end without a newline. So readLine() returns an
> unfinished line if EOF is found first.
>
> > And the API is even worse in the details, the obvious solution to block
> > until line is available or the connection is closed:
> >
> >         while( !socket->canReadLine() ) ;
> >         line=socket->readLine();
>
> As I said before, if you want to block, you have to call a "waitFor"
> function.
> There's none above, so it doesn't block. it simply busy-loops forever.
>
> > Is wrong, as the API documentation points out:
> >
> > "Note that if the peer closes the connection unexpectedly, this function
> > returns FALSE. This means that loops such as this won't work:"
> >
> > So I think Qt has got this small detail wrong.
>
> Or you did.
>
> canReadLine() will return true for as long as there's a line to be read. If
> the device, process or socket is closed without a newline at the end,
> canReadLine() will return false for that last chunk of data. But readLine()
> will return it.
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
>  Senior Product Manager - Nokia, Qt Development Frameworks
>      PGP/GPG: 0x6EF45358; fingerprint:
>      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
>
> _______________________________________________
> Qt-interest mailing list
> Qt-interest at trolltech.com
> http://lists.trolltech.com/mailman/listinfo/qt-interest
>
>


-- 
Regards,
K. Gabriele

--- unchanged since 25/1/10 ---
P.S. Unless a notification (LON), please reply either with an answer OR with
" ACK" appended to this subject within 48 hours. Otherwise, I might resend.
In(LON, this) ∨ In(48h, TimeNow) ∨ ∃x. In(x, MyInbox) ∧ IsAnswerTo(x, this)
∨ (In(subject(this), subject(x)) ∧ In(ACK, subject(x)) ∧
¬IsAnswerTo(x,this)) ⇒ ¬IResend(this).

Also note that correspondence may be received only from specified a priori
senders, or if the subject of this email ends with a code, eg. -LICHT01X,
then also from senders whose reply contains it.
∀x. In(x, MyInbox) ⇒ In(senderAddress(x), MySafeSenderList) ∨ (∃y. In(y,
subject(this) ) ∧ In(y,x) ∧ isCodeLike(y, -LICHT01X) ).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt-project.org/pipermail/qt-interest-old/attachments/20100502/5d9d202f/attachment.html