[Geany-Devel] Segmentation fault when auto-close plug-in is enable [patch]

Lex Trotman elextr at xxxxx
Thu Oct 24 05:58:24 UTC 2013


[...]

> But it seems a pity to have to duplicate the glib interface for each
>> structure that offers the facility, can we just return the GData and let
>> the plugins use the normal g_datalist functions?
>>
>>  [...]
>

To summarise the answer to the question Matthew gave on IRC, no, we don't
have to duplicate the glib interface but it makes it easier to clean up
after plugins if we do.  And its unlikely that many other structs will need
it.

Ok, if thats the case then its reasonable to duplicate the (fairly small)
g_datalist interface for the few structs that need the functionality.

[...]

> We could just use the usual idiom (in G*) and use objects that have
> destruction signals and reference counting and such stuff that is useful
> for this type of scenario. IMO it'd be more useful to just treat
> GeanyDocuments like other stuff, and maybe having an _is_open() or
> _is_closed() function or something to see if the document you have a
> reference on is still open (if you didn't want to connect to its open/close
> signals it could emit).


No problem to replace is_valid with an is_open function that can hide the
implementation.  But whichever implementation is used, it is going to have
to be able to identify if a pointer is no longer to an open document.  The
current implementation sort of does that by keeping the document objects
around so the test of the boolean is_valid is always legal.  Comparing the
pointer against the list of open documents is a (slower) alternative.  It
could also be implemented in some other way.

Cheers
Lex


>
> Cheers,
> Matthew Brush
>
> ______________________________**_________________
> Devel mailing list
> Devel at lists.geany.org
> https://lists.geany.org/cgi-**bin/mailman/listinfo/devel<https://lists.geany.org/cgi-bin/mailman/listinfo/devel>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geany.org/pipermail/devel/attachments/20131024/2855639d/attachment.html>


More information about the Devel mailing list