Re: dangling pointer crash in write_to_festival

Kalle Olavi Niemitalo <[email protected]>
Newsgroups gmane.comp.web.links
Message-ID <[email protected]>
Witold Filipczyk <[email protected]> writes:

> I reset festival.doc_view in really_close_tab. Is it acceptable?

I think that is too far from the code that frees the struct
document_view.  Even if really_close_tab currently were the only
way to free a struct document_view, that could change in the
future, and the person changing it would probably not remember to
add a call to stop_festival.

In fact, really_close_tab is already not the only way: if I
navigate away from a frameset page, then a struct document_view
that festival.c is using can be freed, even though
really_close_tab is not called.

It seems many places that free struct document_view call
detach_formatted first, so you could perhaps call stop_festival
From there instead.  However, if we're going to assume that
detach_formatted is always called before struct document_view is
freed, then this should first be carefully checked, and then
documented in a comment near the definition of struct
document_view.

> When a link is followed and the previous document was read out,
> the new document is read out from the line number of the
> previous document.  How to handle this?

detach_formatted seems to be called in that situation too, so if
it's OK to stop the speech, that should fix it.

By the way, the "default" in "Default speech system" is not
right, because ELinks does not even try speech systems other than
the one selected here.

_______________________________________________
elinks-dev mailing list
[email protected]
http://linuxfromscratch.org/mailman/listinfo/elinks-dev
signature.asc (application/pgp-signature, 188 B)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFF7pSsHm9IGt60eMgRAgKBAJ9sS0s3/DpqSTy3ZUO3lxm+aJShXQCglXRD
nSpqBpi5nPUFTeeDf6DJXuc=
=xScr
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.